It saddens me to see that we have generated so much ill will from you. It sounds like you were affected by our layoffs last year. You have every right to be upset. If you ever want to chat about this 1:1, you know how to reach me. I’d be happy to make the time.
To anyone else reading this: Some of what this person has shared is true, but some of it is not true.
I debated whether or not to reply. But one of my personal leadership values is “transparency”, so I thought I’d take the time to respond.
Yes, we conducted two rounds of layoffs in 2023. Like many tech companies, we hired a lot in 2021 and early 2022. Then, as the tech market began to correct mid 2022, we were forced to make tough decisions, including layoffs.
I take responsibility for the over-hiring and the layoffs. It brought me no joy to do them. But I feel a moral obligation to our customers to stay on the path of financial sustainability. I also feel a fiduciary obligation to our investors, some of whom are individuals, some of whom are large funds, who have all trusted us with their money. I feel a similar responsibility to current and former Timescalers who own equity in Timescale.
Sometimes, that means making tough decisions like this. But again, it was my call (not anyone else), and I accept full responsibility.
Yes, we did not publicize this news. Frankly, we thought we were too small for others to care. Maybe we got that wrong. But that decision came from a place of humility.
This is not true: “Just an email informing you that you no longer work for them.” Every affected person – except for a handful who were not working that day – was told the news individually, on a live Zoom call, that included at least one of our executives or a member of our People team. For the few teammates who were not working that day, we made many attempts to connect with them personally. I know the team tried their best to approach these hard conversations with care and empathy.
I was glad to see that a number of the affected individuals quickly found new roles at other companies in the PostgreSQL ecosystem, including at Supabase, Neon, and Tembo. These are good, smart people. The PostgreSQL ecosystem is better off with these people continuing to work to improve PostgreSQL.
The comments questioning our belief in open source are also not true. We still believe in open source. The core of TimescaleDB is still open source. Some of the advanced features are under a free, source-available license. Our latest release – TimescaleDB 2.15 – was just two weeks ago. Unlike most (all?) of our competitors, we have never re-licensed our open source software. This is something that is true for us but not for many others, like MongoDB, Elastic, Redis, Hashicorp, Confluent, etc.
Yes, we are building a self-sustaining open source business. Yes, it is hard and sometimes we get things wrong. But we have never stopped investing in our community. Today the TimescaleDB community (open source and free) is 20x larger than our customer base. And this community has more than doubled in the past 1+ year. We are also planning significant open source contributions for the next few months.
To the author of this post: I hope this response provides some clarification. And again, I’m available to chat one-on-one if you’d like.
To our open source and free community users, and to our customers: thank you for trusting us with your workloads. We are committed to serving you.
Finally, to the Timescale team, both current and former: thank you for all your hard work making developers successful. We are here to serve developers so that they can build the future. The road won’t always be easy or smooth. But we are committed, and we will get there.
Taking responsibility for laying off a bunch of people is thin gruel. What does that mean? Nothing. They showed you loyalty, you didn't return it. The over hiring is a symptom of bad management, so taking responsibility would be to demote yourself and take a pay cut. All the executive staff should have taken one and kept more people on. It is irresponsible and cruel to overhire and then dump people. I could say more, but I am sure this is falling on deaf ears.
Over-hiring is a calculus that shifts depending on macro market conditions. To pretend otherwise just isn't an honest assessment of what it means to be a business leader. In the zero interest rate era, it was irresponsible for business executives to not invest to ensure they had a competitive foundation or else be left-behind by those doing so... The rise of interest rates changed the market's appetite to invest in non-profitable growth companies, which in turn had a series of follow-on effects that required software executives to reverse course so as to optimize for their long term viability in the new climate.
James did put a lot of thought into this post. I saw multiple iterations of it before it was published. I think calling it a shitpost is being unkind to him.
I think we just find that some developers don't like reading long posts, so he kept this one short :-)
But if you want something with more length/depth, here is another one we recently published:
Thanks! Happy to put you in touch with someone to help you migrate. Or at least, to help you calculate how much cost you could save :-) ajay (at) timescale (dot) com
As with anything, it depends on what you want to do.
If you have an OLAP heavy workload with long scans, etc (which is the type of queries prominent on the ClickHouse page - e.g., Q0 is "SELECT COUNT(*) FROM hits;"), then I would highly recommend systems other than Timescale. (Although we are also working on this ;-) )
But if you have time-series workload, or even, if you love Postgres and are building a time-series and/or analytical application, then I would recommend TimescaleDB.
ClickHouse is great. I just believe in using the right tool for the right job. :-) There are many areas where column store engines beat TimescaleDB. But nothing comes for free - everything has a tradeoff.
Just to clarify: Nothing on Timescale is closed-source. It is all source available, all on Github. Some of it is Apache2 licensed, some of it is Timescale Licensed. And it is all free.
Since the Timescale License is not an open source license, it is a closed source license. You are right, it is source available, but source available is also closed source. It is closed because it is not open. And it might be free as in beer, but it is not free as in freedom.
My recollection is that the TS license simply has protection against using the TS code to compete with TS, ala Amazon RDS.
While some people on HN feel that this is an impurity they can’t live with, I personally think it’s a small price to pay to enable development of TS to continue. In my opinion, claiming that it’s closed source is somewhat dogmatic. Many open source licenses have some kind of restrictions on use; the GPL comes to mind.
I have always been more on the pragmatic side of the FOSS movement (open source versus the philosophical/moral stance of the FSF, but still have tremendous respect for the FSF). For pragmatic reasons I reject the Timescale License. It doesn't just prevent Amazon (that alone would be misguided enough, though) but also prevent anyone other than Timescale from hosting the software for me. That means even if Timescales current offerings lined up perfectly with my business, I would be locked into whatever decisions they make in the future which may not align. The chances for a successful community fork are greatly reduced under the restrictions of the Timescale license. It makes it impossible for the community to make contributions on equal footing to Timescale, thus anyone making contributions are just doing free work for a corporation, rather than contributing to a product the community benefits from just as much as the corporation.
I prefer the Apache or Mozilla Public Licenses myself. But I accept the AGPL and the GPL family of licenses will consider useing software licensed under them in limited ways (it isn't clear how the AGPL interacts with infrastructure software).
"Open source" and "closed source" are not the only options. There are plenty of products out there where you're technically allowed to look at the source code, but very restricted in how you can legally use it. The "open" in "open source" is generally understood to mean that users have permission to use, modify and redistribute the software. (Without that permission, calling it "freeware", "shared source" or "source available" would be more accurate.)
In the case of the non-Apache-licensed version of TimescaleDB, you're allowed to use the software without payment, and you can distribute unmodified copies. But you're essentially forbidden from letting users define their own schemas, or from modifying it or reusing components unless your modified version imposes that same restriction. (The exception is if you agree to transfer ownership of your changes back to Timescale.)
Nobody's saying that Timescale can't build a non-open-source database, only that they should be clear about which parts are actually open. In my opinion, describing it on the homepage as an "open-source relational database" and then promoting it by benchmarking the proprietary version is at least a little bit misleading.
