(I'm working with malisper on this), we are now focusing on improving many things about postgres! Some we have written about before [0], and we have much more in mind too. Malis wrote another comment about analytical workloads being 300x faster now than postgres for a version we're working on right now

Aiming for postgres compatible database with a 2026 architecture

[0] https://malisper.me/the-four-horsemen-behind-thousands-of-po...

I think a business case for a "look I let an LLM rewrite a large codebase" does not exist.

There is big appetite for PostgreSQL in business cases. But there's also a lot of problems in PG and people want to solve them. But there's ~10 people in the core of PostgreSQL who contribute to it and know how to change the core. If you have a business use case that would require changing the core, doing it in safer, less error prone technology would be way better. That's why you have other products that had to be created that talk PG protocol, but aren't using official build.

Why not? The author have their own reasons to do it. Did they ask you to use it instead of the official build? It's a github repo.

Why does there need to be a business case? They aren't selling it.

Software raidership?

It's pure virtue signaling.

Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.

[dead]