Postgres was rewritten in Rust… and somehow passed every test

[00:00:00]Someone rebuilt Postgres in Rust, and somehow the release version now passes all 46,000 Postgres regression queries.

[00:00:08]It works with normal PSQL. It can even boot an existing Postgres 18.3 data directory. That sounds like a production-ready replacement. It isn't.

[00:00:17]But, the most exciting version of this project has yet to even be released. So, what exactly are we even looking at here? Is this the future of Postgres or just an AI experiment?

[00:00:32]Now, to understand why this matters, you need to understand the problem. Postgres is one of the best databases ever built.

[00:00:39]Let's face it. But, it also carries nearly four decades of architecture and roughly a million lines of C. Every client connection gets its own back-end process. That isolation is useful, but it also means more memory overhead, more pressure to use connection pooling, and more difficulty sharing state across parallel work. PGRust takes a different path. Keep the Postgres behavior, keep the client experience, keep the disk formats, but replace the engine underneath with Rust. This is not a Postgres extension. It's not a feature added on top. This is completely separate, an implementation trying to behave just like Postgres. We're seeing a lot of Rust rewrites now, just like the one we covered the other day on Bun rewriting its entire codebase with Rust.

[00:01:25]I'll put it somewhere right here. And now, all this sounds good, but does it actually feel like real Postgres? Let's test it properly. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We have videos coming out all the time. Now, I'm starting with the official Docker image, then connecting with a completely normal PSQL client. Nothing custom. Now, I'm in.

[00:01:46]First, let's check the version. As you can see, it reports itself as PGRust with the latest version. Now, I can create a table, insert some data, and look at a query plan.

[00:01:59]I'm just going to run this right here in my terminal. From the outside, this is completely indistinguishable from Postgres. Same client, same SQL, same output. You can even see the query planner chose an index scan and gave us real execution stats. And to make this a little more interesting, let's insert 100,000 rows and run another query.

[00:02:20]This is just a generated 100k rows of data. We're going to drop it in here.

[00:02:25]Now, what is the point of all this?

[00:02:26]Okay, well, good question. Well, in this current early version release, we're not going to see dramatic speed improvements over regular Postgres. The bigger performance claims come from an unreleased development version that switches to a thread per connection model. This all does prove though that this isn't just a partial implementation. It has passed the full official Postgres regression test suite, over 46,000 queries. It speaks the real wire protocol, and it has a working query plan and storage engine. This is a real database server. It's just written in Rust. So, with this progressing, we could see some serious performance enhancements on the speed side of things. So, now the question is, why not just create another Postgres extension?

[00:03:12]Because extensions sit on top of the original Postgres core. A fork can change that core, but then it inherits the same architecture and the permanent job of keeping up with upstream Postgres. You have databases like CockroachDB and Yugabyte, but they are independent distributed databases. Exact drop-in compatibility is not their main goal. PG Rust is trying something else.

[00:03:37]It uses actual Postgres behavior as the specification. The current release targets Postgres 18.3. It passes the default regression suite and isolation tests. And it is just compatible enough to boot from an existing Postgres 18.3 data directory. The bigger experiment here is happening in a separate unpublished version. And that version reportedly replaces Postgres process per connection model with a thread per connection model. With the normal Postgres model, each connection gets its own process. With the new model, each connection gets a thread inside the same process. That can lower per connection overhead and make it easier for different parts of the database to actually share information. But with all this, there is going to be a trade-off, right? Separate processes also create useful walls between connections. If one process fails, that separation can help contain the damage. With threads, one unsafe extension or memory bug could affect more of the server. So, thread per connection is not automatically better. It just opens new doors, but it may also remove some safety rails. Then there is the second major part of the story, AI. Michael Malis and Jason Seebol used coding agents heavily to speed up the rewrite. The published version intentionally follows the original Postgres structure in many places. The unpublished version is where they are trying larger architectural changes. So, the real experiment is not simply can Rust make Postgres faster?

[00:05:09]It's more like can AI make a rewrite this large affordable enough that developers can actually rethink architecture underneath things because AI was heavily used here. Now, does this change things? Well, it might. It's also where we need to slow down a little bit.

[00:05:25]The released version is not heavily optimized. The major performance claims come from the unpublished thread per connection version, which right now we can't quite test. The devs claim roughly 50% better performance on transactional workloads. They also claim around 300 times Postgres' performance on analytical workloads. Those numbers are huge, but the code behind those results is not currently available for any type of inspection or benchmarking. So, hence this, there is still a lot of speculation. It seems there is a good 50/50 split here, at least reading online with questions that look kind of like these. These are just the issues here on GitHub. Then you even get one issue like this one, right? Which is a completely reasonable question. As you read through this issue, the devs seem adamant about actually making this work.

[00:06:15]So, we don't have real stats just yet.

[00:06:17]That does not automatically mean the numbers are false, though. It just means we should treat them as promising claims, not settled facts. And honestly, the exact multiplier may not be the most important part. We don't need to change the entire Postgres project before learning whether an idea actually works or not. That freedom may be more valuable than any single benchmark we can get. Now, the reaction from devs with all these Rust rewrites, even on this pg Rust, has been massive. The main Hacker News discussion passed hundreds of points and comments, but again, the response is split. Both sides are making good points. First, passing every regression query is a serious achievement. A lot of projects claim to be Postgres compatible. That phrase can mean almost anything. pg Rust has a measurable target. The real Postgres tests are the judge of this. And the speed of this rewrite suggests that coding agents may completely change cost of large infrastructure experiments.

[00:07:13]Ideas that once looked too expensive to attempt are now seemingly becoming more possible. Now, for the other side of things, passing regression tests is not the same as earning production trust.

[00:07:24]Those tests don't replace years of crash recovery and replication testing, or databases that run for months without stopping. A project can pass every known test and still fail in a situation nobody even thought to test. Generating hundreds of thousands of lines of code is one challenge. Extension compatibility is another major gap. Now, should you replace your production Postgres cluster with PG Rust? No, absolutely not. The project itself is not production ready. It's stated. It's not fully optimized. And major compatibility areas, including the extension ecosystem, they're still unfinished. But should you try it? Sure.

[00:08:03]If you work with databases, Rust query execution, compatibility testing, or AI development, why not give it a try? Run the Docker image, test your client library against it, read the source, and see what happens. So, drop your verdict in the comments. Where is this project going? Are we going to start rewriting more in Rust? We're going to find out.

[00:08:23]If you enjoy coding tips and tricks like this, be sure to subscribe to the Better Stack channel. We'll see you in another video.