akulkarni

I'm just sharing my thoughts as a long-time reader. Again, it's your show. You don't have to defend your actions. Thanks for all that you do.

Thanks Tom, I appreciate the openness. You are seemingly overriding the wishes of the community, but it your community and you have the right to do so. I still think it's a shame, but that's my problem.

There are also 200+ comments on here and a good discussion IMO which is now unfortunately buried.

Feels like a net negative for the HN community.

You buried a popular post because of the public accusation or just your "hunch"?

Why not let your audience decide what it wants to read?

I say this as a long time HN reader, who feels like the community has become grumpier over the years. Which I feel like is a shame. But maybe that's just me.

I don't understand your example: pgvectorscale was built and is maintained by Tiger Data

It is up to RDS. But there should be nothing stopping them. AFAIK they respond to customer interest.

pgvectorscale is 100% open source

please ask your RDS rep to support it

we (tiger data) are also happy to help push that along if we can help

<3

Yeah, I know what you mean. I used to roll my eyes every time someone said “agentic,” too. But after using Claude Code myself, and seeing how our best engineers build with it, I changed my mind. Agents aren’t hype, they’re genuinely useful, make us more productive, and honestly, fun to work with. I’ve learned to approach this with curiosity rather than skepticism.

Thanks! We agree :-)

We just launched a bunch around “Postgres for Agents” [0]:

forkable databases, an MCP server for Postgres (with semantic + full-text search over the PG docs), a new BM25 text search extension (pg_textsearch), pgvectorscale updates, and a free tier.

[0] https://www.tigerdata.com/blog/postgres-for-agents

Thanks for the kind words about TimescaleDB :-)

We think we're still building great things, and our customers seem to agree.

Usage is at an all-time high, revenue is at an all-time high, and we’re having more fun than ever.

Hopefully we’ll win you back soon.

Appreciate the feedback! Will chat with the team.

This was a surprisingly fun and captivating read.

That's interesting. Personally I did not find it vague and ambiguous.

ClickHouse was fast but required a lot of extra pieces for it to work:

    Writing data to Clickhouse

    Your service must generate logs in a clear format, using Cap'n Proto or Protocol Buffers. Logs should be written to a socket for logfwdr to transport to PDX, then to a Kafka topic. Use a Concept:Inserter to read from Kafka, batching data to achieve a write rate of less than one batch per second.

    Oh. That’s a lot. Including ClickHouse and the WARP client, we’re looking at five boxes to be added to the system diagram. 

    So it became clear that ClickHouse is a sports car and to get value out of it we had to bring it to a race track, shift into high gear, and drive it at top speed. But we didn’t need a race car — we needed a daily driver for short trips to a grocery store. For our initial launch, we didn’t need millions of inserts per second. We needed something easy to set up, reliable, familiar, and good enough to get us to market. A colleague suggested we just use PostgreSQL, quoting “it can be cranked up” to handle the load we were expecting. So, we took the leap!

I agree with the overall sentiment of this post.

I’ve learned (sometimes the hard way!) that every design choice comes with real trade-offs. There’s no magic database architecture that optimizes every dimension (e.g., scalability, performance, ease-of-use) simultaneously.

Social media often pushes us into oversimplified "winner vs. loser" narratives, but this hides the actual complexity of building great infrastructure.

Recognizing and respecting these differences makes us smarter engineers, better community members, and frankly, just more enjoyable people to chat with.

PS Thank you for helping me add a new book to my list :-)

That's fair. We referenced that quote because it captured a lot of the skepticism in the early days (and because that comment is public). No hard feelings though!

That was one of our requirements when we started discussing a name change. :-)

I'm sorry to hear about your experience. Would love to hear more if you are open to it: ajay [at] tigerdata [dot] com.

It depends on which benchmarks you use.

"ClickBench evaluates databases using a single table of clickstream data, representative of workloads like web analytics, BI, and log aggregation. It also favors full-table large scans and large-scale aggregations on denormalized data.

Real-time analytics inside applications is different and needs a new benchmark." [0]

This is why we published RTABench. [1]

We believe that it is more representative of real-time analytical workloads.

[0] https://www.tigerdata.com/blog/benchmarking-databases-for-re...

[1] https://rtabench.com/

Thank you for recognizing that in us.

Exactly!

"The future is already here, it's just not very evenly distributed" - William Gibson

No joke: We've had Influx customers come to us and say that migrating from Influx 1.x to Timescale was easier than migrating from 1.x to 2.x

We chose the Tiger back in April 2017.

Also TigerBeetle is an insect, not a fast cat.

YMMV but our largest internal dogfooded Timescale instance is 100s of terabytes

https://www.timescale.com/blog/how-we-scaled-postgresql-to-3...

(Post is a year old, IIRC the database is over one petabyte now)

Exactly. You can have the best of both worlds with Timescale.

That's interesting. Our first extension (TimescaleDB) is great for time-series and real-time analytics.

And yes you are correct, pgvectorscale scales pgvector for embeddings, and pgai includes dev experience niceties for AI (eg automatic embedding management).

Would love to hear any suggestions on how we could make this less confusing. :-)

You can request it for RDS

Agreed :-)

pgvectorscale only makes pgvector better. The primary developer-facing improvement is the introduction of the StreamingDiskANN index type.

So we would recommend using both from the start. There is no cost (technical or financial) for doing so.

There is discussion about getting this added to AWS RDS (as well as other PostgreSQL providers), but too early to share anything.

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.