Live data from Hacker News

pg_durable: Microsoft open sources in-database durable execution

github.com

51–60 of 119 posts

Re: pg_durable: Microsoft open sources in-database durable execution

#51
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 execution

#52

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. W…

you might be happy to note there is such a thing.

pgrust.

Re: pg_durable: Microsoft open sources in-database durable execution

#53

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. W…

> 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 execution

#55

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. W…

I am afraid you don't understand Postgres very well.

Re: pg_durable: Microsoft open sources in-database durable execution

#56

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. W…

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 execution

#57

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. W…

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.

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 execution

#58

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. W…

you might be happy to note there is such a thing. pgrust.

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 execution

#59

Earlier quoted context omitted.

you might be happy to note there is such a thing. pgrust.

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.

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 execution

#60

Earlier quoted context omitted.

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.

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.

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?
Post reply on HN