A corollary of that is that, at least for the most part, as far as I can tell, this situation is not due to “vibe coding”. This code was written well before that was a possibility.

It's not AI that's at fault here. Put down your pitchforks. It actually helped discover the bugs.

Short answer, maybe. Until you specify your needs or use case it is very difficult to say.

In general, most if not all, benchmarks I have seen comparing Postgres to RAM key value stores has always had postgres coming significantly slower. If speed is the most important factor then likely no, you still need a key value store.

Also, you wrote "small scale", but even that can be ambiguous. Is it small scale because it is small, but you still need fast lookups? or is it "small scale" because it is a small setup and speed is not an issue?

It ultimately comes down to your needs and your appetite for having a second technology if you already have postgres. Sometimes, even if a second technology is better at something, the overhead of having the second technology may not be worth it.

Would this be a replacement for Valkey in small scale?

Saving it for a read later on!

Shame crunchy got bought by an AI company, they’ve gave up much of their former open source stewardship, Chris is a good dude though, and so are a lot of the folks still there.

GIN indexes, reltuples or btree_gist have update steps

Amen

As soon as I saw the title, I knew it was going to be "at the start of the transaction".
Nice breakdown of it causing a bug, and how that bug slipped through layers of testing.

10 days? This is a hotfix in the Postgresql world?

Wow... 2005 called, they want their release schedule back

I don't feel like leaving the records in-table is that terrible. Maybe even partition on the deleted-at column to keep the performance impact minimal. The benefit of simplicity massively outweighs the rest for me

Looking forward to the sql, "immoral PostgreSQL Optimizations"

At work we were celebrating. Fun times.

Interesting move going to a new wire protocol. A lot of “postgres” DBs like Cockroach just do the protocol and handle storage differently.

AsyncIO, OAuth2 support, and a new wire protocol (for the first time since 2003)!

laughs in ClickHouse

The full text search works quite well. Also, if you just HAVE to store a bunch of data in JSON, it will do that too as well as index and query it. No need for MongoDB (which is the wrong tool for the job 99% of the time anyways).

TLDR

Redis for caching, RabbitMQ for queues, Elasticsearch for search, and MongoDB for... reasons?

Postgres might be too good for its own good. It's so capable that it makes most other databases seem unnecessary for 90% of applications.

Thanks for sharing. The built-in text search sounds helpful for the project I'm working on.