akulkarni

Thanks for the kind words.

And yes, Andrew Kane (et al) are the people to thank for pgvector.

We (Tiger Data) developed pgvectorscale and pg_textsearch (and timescaledb, and some others)

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!

PostgreSQL with TimescaleDB did the job. Why overcomplicate things?

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.