News for hackers. Stuff that matters.
Re:pg_durable: Microsoft open sources in-database durable ex... by steno132 on Friday June 05, 2026 @04:28PM (#48417768)
I would argue that for all but the largest tech companies you only need a single data system which is Postgres. Message brokers, analytical databases all can be built on Postgres. Unfortunately, Postgres as it's built now lacks any semblence of extensibility which makes this impossible in practice.

I would propose a rewrite of Postgres in another language like Rust, introducing a pluggable application layer on top. While ambitious in scope I think it would be helpful and even necessary.

Re:pg_durable: Microsoft open sources in-database durable ex... by redmonduser on Friday June 05, 2026 @04:55PM (#48418148)
There are 100+ popular extensions around Postgres. They have dependencies on the internal data structures of Postgres. If someone spends the time to rewrite Postgres on Rust and it doesn't support these extensions off the bat, then its DOA.
Re:pg_durable: Microsoft open sources in-database durable ex... by steno132 on Friday June 05, 2026 @04:59PM (#48418197)
What I'm saying is that Postgres was built for a long gone age. We need a extensible database written in Rust which can serve as a foundation for any data system. We don't need a relic of the 1980s serving our most critical workloads.
Re:pg_durable: Microsoft open sources in-database durable ex... by belinder on Friday June 05, 2026 @05:07PM (#48418305)
Why does it matter it's from the 80s? You're suggesting people back then were incapable of making good decisions, and people now will make better ones?
Re:pg_durable: Microsoft open sources in-database durable ex... by dalberto on Friday June 05, 2026 @04:48PM (#48418056)
> Postgres as it's built now lacks any semblence of extensibility

PostGIS. pgvector. TimescaleDB. Citus. pg_cron. pgmq. Apache AGE. ParadeDB. hstore. plv8. postgres_fdw. pg_partman. pg_stat_statements...

The extension API is the thing making your thesis possible. Rewriting it away would mean deleting the exact feature you're asking for.

Re:pg_durable: Microsoft open sources in-database durable ex... by linuxhiker on Friday June 05, 2026 @04:52PM (#48418115)
I am afraid you don't understand Postgres very well.
Re:pg_durable: Microsoft open sources in-database durable ex... by dsr_ on Friday June 05, 2026 @05:13PM (#48418396)
What's to understand? They think they can vibecode PG19.

I won't be running that, though.

Re:pg_durable: Microsoft open sources in-database durable ex... by reactordev on Friday June 05, 2026 @04:35PM (#48417865)
you might be happy to note there is such a thing.

pgrust.

Re:pg_durable: Microsoft open sources in-database durable ex... by steno132 on Friday June 05, 2026 @05:01PM (#48418221)
This is a great initiative. Postgres was written in the 1980s and we can't afford to have our most utilized workloads running on a software written before most of us even existed. LLMs make it possible to rewrite Postgres and we should take that chance.
Re:pg_durable: Microsoft open sources in-database durable ex... by reactordev on Friday June 05, 2026 @05:04PM (#48418263)
Not broke don’t fix? Or write your own? Not everything needs a rewrite to rust.
Re:pg_durable: Microsoft open sources in-database durable ex... by sgarland on Friday June 05, 2026 @05:51PM (#48418828)
It’s always been possible to rewrite it; LLMs just made it possible for people who don’t understand it to do so. I personally don’t see that as a benefit, but you do you.

As to the age statement, why on earth does that matter? HAProxy launched in 2001, and despite it being 25 years old, you’ll struggle to find anything faster or more stable in its field. Then there’s, you know, Linux - 1991. I suppose you want to see it rewritten?

Re:pg_durable: Microsoft open sources in-database durable ex... by sbuttgereit on Friday June 05, 2026 @09:56PM (#48420626)
> Postgres was written in the 1980s

This is a pretty poor take. Sure the software that we call "PostgreSQL" started to be developed in the 80's... but they didn't stop there. PostgreSQL has been in continuous development, including improvements, changes, and additions, and by some very smart people at that. It's not static and as long as I've been a professional user of the database, decades, it has continually evolved and in some cases even led the way. If we were to survey the software, wouldn't you at least be interested to know how much of code base actually dates back to those long ago decades and how much is more modern before making such statement?

It would be a mistake to take what PostgreSQL actually offers: an excellent database that has be continuously developed and updated over many years (i.e. "maturity"), for some arbitrary idea and evidently baseless idea that somehow "new" must be better.

If new is better, say why; and do so with more actually true statements than it's not extensible. Want it in rust? Well, OK, sure you can give hand-wavy reasons about security and such for why that might be beneficial; but if you want to be convincing you need to be much more specific about the problem in PostgreSQL and the specific way in which your recommendation actually and convincingly moves the needle. If you can't do that, you're simply giving us an emotional outpouring rather than a rational one.