Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

If the underlying code ends up being a completely unreadable blob that no human will ever read why not directly do a port to assembly instead of rust?

it's a neat experiment, obviously inspired by the bun guy.

but given the author/maintainer is essentially unknown, I highly doubt this will reach it's target audience. But one thing I do agree with is that postgres is long overdue for a re-write into a memory safe language.

also any real swe with more than a few years of experience knows "100% of regression suite passing" doesn't mean anything other than a neat checkmark for C-level executives.

>use Rust plus AI-assisted programming

>pgrust is licensed under AGPL-3.0

pgrust isn't licensed at all. AI generated code isn't copyrightable. Thanks for spending the tokens I guess.

Super impressive! Remember talking with Michael about his experience with Citus at Heap and reading his blog posts on Postgres

Super cool to see him working on this now, almost 10 years later

Woah! AGPL? That's interesting. I think Postgres has shown an open source SQL server didn't need a copy-left license to develop sustainably, so I'm not entirely aure about that, but I do like the license in general.

It's silly, nearby all Rust projects are rewrites of existing projects and now as you don't need to learn Rust to do rewrites, people just let the AI rewrite projects in Rust.

It's so great. One thing that I'd like to be changed in PostgreSQL, which may be done in this rewrite, is resigning from the "one connection = one process" design choice and instead handle the connections using threads/tasks within the main process.

`seams` is the new emdash

Great! Now ask it to rewrite it in CSS!

That's actually interesting - gives C developers motivation to improve postgresql. after all people could say "look, Rust makes this easier".

What is the future of this? Code is not the same as a viable open-source project with a community, contributors, advocates, users and funding, even if it's perfect code.

Even though I'm sure it won't be easy to convince the Postgres project to switch to Rust, I do think that trying would be time better spent.

Does it support the extension ecosystem? Or would extensions need to be rewritten as well?

What a peculiar kind of rewrite.

Rust:

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

Original:

https://github.com/postgres/postgres/blob/df293aed46e3133df3...

Usage:

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

The return type in the rewrite is both some sort of Error tagged union that supports the Try machinery in Rust; but, it also contains a boolean that apparently must be checked; or something. It seems labyrinthical and possibly broken and terrible.

Till its used in prod for few years and polished, I wont touch that.

Too many things tests wont catch.

First bun, now it's PG's turn again, although this isn't official.

I have a feeling that AI is rewriting everything!

Is this another llm-driven rewrite?

I wonder how many "unsafe" blocks are in there...

Now which one is safer? A new Postgres written in Rust, or the original real world tested Postgres?

Rust is a stripper

but did they change the process-per-connection model? if not, wtf??

Rewrites in Rust are kinda impressive. This language with its move semantics and close ownership tracking is very different from every other language. To create a rewrite in it, you have to rearchitect the code. There is not as much freedom there when it comes to where to keep what and where you can pass what as it is in other languages.

I don’t understand these rewrites, honestly, what is the point? Who have had any C++ related issues while working with Postgres?

Now do Freetype and libtiff/libpng/etc.

I have privately wondered for years, pre-AI, why Apple hadn’t paid some engineers to go off and write some comprehensive test suites and then port these to Swift. It would shut down entire swaths of memory safety bugs they have been coping with for literally decades. SO MANY of the zeroclick iOS exploits can be traced to a few fragile and vulnerable foss libraries, xkcd 2347 style.

[flagged]

[flagged]

[dead]

[dead]

The great Jarred Sumner pulled it off with bun, whether it can be pulled of with Postgres is an open question..

DST systems such as Antithesis can definitely help.

We had one for SQLite (which is SQL-ite btw, not SQ-Lite which doesn't make any sense) via Turso, no wonder we see the same for Postgres. Personally I do want to see libraries be in as much memory safe languages as possible.