HNHacker News
TopNewBestAskShowJobs

akulkarni

1,573 karma · joined October 16, 2010

http://www.tigerdata.com/

ajay (at) tigerdata (dot) com

submissionscomments
akulkarni··on pg_timeseries: Open-source time-series extension for PostgreSQL
Ajay, Timescale CEO and co-founder, here.

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.

akulkarni··on Using Postgres for Everything
You don't need to imagine ;-)

https://x.com/avthars/status/1788195573989806448

akulkarni··on Using Postgres for Everything
(Timescale co-founder)

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:

https://www.timescale.com/blog/postgres-for-everything/

akulkarni··on Using Postgres for Everything
(Timescale co-founder)

We actually have 100s of customers who use Timescale for their production time-series _and_ OLTP workloads :-)

akulkarni··on Bottomless, consumption-based storage for PostgreSQL built on Amazon S3
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
akulkarni··on Bottomless, consumption-based storage for PostgreSQL built on Amazon S3
(Timescale co-founder)

Let us know how we can help :-)

Also just curious: What's your application?

akulkarni··on TimescaleDB 2.7 vs. PostgreSQL 14
(Timescale co-founder)

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.

akulkarni··on TimescaleDB 2.7 vs. PostgreSQL 14
(Timescale co-founder)

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.

akulkarni··on TimescaleDB 2.7 vs. PostgreSQL 14
(Timescale co-founder)

Yes, 100%. We deliberately choose the "+" symbol instead of "vs." for this blog title. We love PostgreSQL. :-)

akulkarni··on TimescaleDB 2.7 vs. PostgreSQL 14
(Timescale co-founder)

That's a fair question.

We find that most developers storing time-series data on Postgres are doing so without pg_partman. So we first wanted to provide a benchmark that would be useful to most developers.

This benchmark was also the result of months of dedicated work. So the team did spend a lot of time on this. Unfortunately, they ran out of time to cover pg_partman. But that comparison is on our list of things to do soon.

Thanks!

akulkarni··on TimescaleDB 2.7 vs. PostgreSQL 14
[Timescale co-founder]

We have published many, many benchmarks versus other database systems. IIRC all of them also made the front page of HackerNews.

Here are some of them, for your reading pleasure :-)

TimescaleDB vs. InfluxDB: https://www.timescale.com/blog/timescaledb-vs-influxdb-for-t...

TimescaleDB vs. ClickHouse: https://www.timescale.com/blog/what-is-clickhouse-how-does-i...

TimescaleDB vs. Timestream: https://www.timescale.com/blog/timescaledb-vs-amazon-timestr...

akulkarni··on Neon – Serverless Postgres
"One of these things is not like the other"

TimescaleDB, because it is packaged as a PostgreSQL extension (and not a fork, unlike the others), stays compatible with mainline PostgreSQL, especially as PostgreSQL improves. This is one of the key advantages of our approach.

(Timescale co-founder)

akulkarni··on Analysing Data in Web3 with SQL

    clickhouse is more generally olap and not suitable for oltp, you could call it an olap+timeseries solution similarly to how you position timescale as oltp+timeseries
You are correct, TimescaleDB is time-series + OLTP. But I would argue that ClickHouse is just OLAP, but is better at time-series than other OLAP. But maybe now I am splitting hairs (and my apologies if I am).

   how much of timescale's performance would you say is inherited from PostgreSQL?
The performance areas where TimescaleDB shines is mostly stuff we have built. But the reliability, tooling, and ecosystem are mostly inherited from Postgres (which I think is a very good thing)
akulkarni··on Analysing Data in Web3 with SQL
Time-series queries are faster on TimescaleDB (built on PostgreSQL) than ClickHouse.

https://www.timescale.com/blog/what-is-clickhouse-how-does-i...

Disclaimer: Timescale co-founder

akulkarni··on Analysing Data in Web3 with SQL

  Results of query benchmarking between TimescaleDB [built on PostgreSQL] and ClickHouse. TimescaleDB outperforms in almost every query category
I don’t think that post says what you think it says ;-)

(Disclaimer, Timescale co-founder)

akulkarni··on OpenTelemetry Traces and PostgreSQL
(Timescale co-founder)

The Promscale team is at KubeCon right now, so I'll jump in to answer this question.

Yes, you can actually cross-analyze traces with prometheus metrics in Promscale. That in fact is one of the key reasons we built Promscale, and is something we can do because it is built on top of TimescaleDB.

    If it's possible that'd be a game changer.
I hope it is! And if not, we're always open to product feedback.
akulkarni··on Timescale raises $110M Series C
Thank you! I shared it with the team
akulkarni··on Timescale raises $110M Series C
Thank you for the wonderful guest post (and the kind words!)
akulkarni··on Timescale raises $110M Series C
Hi there, not sure how you did your price comparison, but typically with native compression, performance improvements, continuous aggregates, etc, you can go much further with the same resources on Timescale Cloud than Cloud SQL (or any other generic PostgreSQL provider). Did your math take those performance improvements into account?
akulkarni··on Timescale raises $110M Series C
Thanks for letting me know. Have you filed a Github issue? If so, could you point me to it? Thanks!

https://github.com/timescale/timescaledb

akulkarni··on Timescale raises $110M Series C
+1

We agree that the world needs more PostgreSQL and TimescaleDB educational content, and welcome any help!

akulkarni··on Timescale raises $110M Series C
Nope :-) That's another product :-D
akulkarni··on Timescale raises $110M Series C
Thank you :-)

There's a lot of lessons I've learned along the way

These are probably two of the top ones:

1. Solve a big problem that people have (even better if you personally have it)

2. Who you work with matters more than what you work on :-)

akulkarni··on Timescale raises $110M Series C
Hi there, sorry you had a negative experience with Timescale Cloud.

It's true that on Azure we require both the resource group name and also the Virtual Network name to be in lowercase.

But Microsoft names are case-agnostic, so this should be okay.

We've had other customers with this issue before and converting the resource group name to be lowercase worked for them.

Also, sometimes technical restrictions exist for internal reasons that are not obvious / hard to share externally. :-)

That said, I shared your message internally and someone is looking into this. Stay tuned. More soon.

akulkarni··on Timescale raises $110M Series C
In our benchmarks (which you and others are welcome to replicate), Timescale vastly outperformed AWS Timestream:

https://www.timescale.com/blog/timescaledb-vs-amazon-timestr...

akulkarni··on Timescale raises $110M Series C
(Timescale co-founder / CEO)

I just want to say that we wouldn't be here without the support, feedback -- and yes, even the honest critiques -- from the HN community. So thank you everyone.

As we like to say, we've come a long way in the past 5 years, but we're just getting started :-)

And we're hiring globally for our remote-first team!

https://www.timescale.com/careers

akulkarni··on Ask HN: Feeling Depressed and Choked. How to handle it?
First of all: Life is worth living. Your son needs you, your family needs you, your friends need you. Even if this is a minor thought in the back of your head, please talk to someone about it.

Second, being a new dad is hard! I’ve been there. Trust me: it’s gets better. This too shall pass.

And if you one day want to start a company, the opportunity will come up. Have faith.

Finally, as one of my good friends likes to say, “When you’re going through hell… keep going.” Sometimes the key is not to overthink things but just to take it one day at a time.

Good luck!

akulkarni··on Amazon.com Homepage (1999)
This made me chuckle. Man, what a time capsule:

  Ready to challenge reality? Take a mind-bending ride through an alternate universe with The Matrix. And on DVD, this year's coolest thriller looks even gnarlier. Get ready to follow the white rabbit.
akulkarni··on Pg_GraphQL: A GraphQL Extension for PostgreSQL
As co-founder of another database company in the PostgreSQL ecosystem, I have to say that I'm really impressed with the quality and velocity of launches from the Supabase team. Nothing else to add, except please keep up the great work!
akulkarni··on TimescaleDB vs ClickHouse
If you would like to discuss facts: We have witnessed 100,000s+ of different time-series workloads over the past 4.5 years, and the patterns they share may surprise you. There is much more similarity than you may think - similarities that have been captured in the TSBS (and described by other TimescaleDB users in this discussion thread).

So while we can debate on an academic level what a "time-series" workload is, if we were to look at the facts we will find that the answer is far more specified that you may think.

Also, Peter, I wonder if you should be more forthcoming with your ClickHouse affiliation.

Everyone reading this thread is aware of my bias because I clearly state my TimescaleDB affiliation. But I didn't realize until very recently (when someone pointed this out to me) that you are affiliated with ClickHouse - eg perhaps as an investor or even founder in Altinity?

It is best practice on Hacker News to be forthcoming with affiliations so that readers can make their own decisions on how to correct for any natural biases made by commenters.

← PreviousPage 2 of 10Next →