alt Hacker NewsPostgres rewritten in Rust, now passing 100% of the Postgres regression tests
Comments
Don’t understand these rewrites.
- typically they are behind a single person. That’s usually bad because of spf
- typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term
- anyone that wants to contribute to the project needs to pay. Needs to pay tokens because it’s increasingly difficult to maintain these projects without AI
So, who wants to put something like this in production? Doesn’t make much sense
I think the best way to test this would be to put PgBouncer or a similar proxy in front of a busy production database, and mirror queries to both traditional Postgres and the Rust one at the same time. Then you can compare output and performance under real load. After running it for a while, you could diff the tables one to one against the normal Postgres instance.
How would one go about reviewing a piece of code like this?
One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you much anyway.
ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious
[1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...
2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.
This is impressive - but is a license change, from the PostgresQL license [0] to AGPL [1].
I like the AGPL and think it's the best truly free open source license, but I worry if this is compatible. Ie, if this is rewritten from the original source, should the original apply? (Yes.) There has been a trend to rewrite open source software with a more restrictive license (like coretools in Rust). This looks considerably more ethical by choosing the AGPL - I just wonder, safer with no change at all?
[0] https://www.postgresql.org/about/licence/
[1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file
If you can do a Rust rewrite with AI, I can create one as well. What makes yours better than mine? Your decade long expertise in database or Rust language? Your reputation? Your proven track record to manage large, complex projects? Your time committed to the project? I don't see any of that.
I don't know why anyone would choose this over the actively (community) maintained proper Postgres project.
I feel like we need to heavily differentiate between a rewrite and an AI rewrite.
Porting perfectly working C code that has been in production for decades (and has a great track record wrt to security fixes) to rust is more or less an obfuscation challenge.
Given that you reuse Postgres' tests and LLM have been clearly trained on Postgres' three decades of contributions, this may constitute a license violation. Unless you include the original license of course. From a human level I also understand how you ended up with a less permissive license.
I start to see a lot of these re-writes that depend on tests to state that its working. But the things that make software like Postgres and SQLite reliable are not mostly the test, but the real world production scars. That's where the reliability comes from, years and years of running in production.
Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?
Regression tests start to play a different role with LLMs.
On one hand, they give an LLM a short feedback loop to correct itself, and iterate fast when writing code. A human also uses it as a feedback loop, but we don't iterate as fast and don't handle big walls of conditions, so its effect is not as big.
On the other hand, LLM's ability to handle a big wall of if-conditions can backfire if it starts taking shortcuts and taking the tests-as-a-spec too literally, overfitting the solution, overly focusing on the given datapoints (conditions checked by tests) and missing the overall behavior shape that the tests intend to pin down. For humans, this is less of a concern because we are bad at big walls of if-conditions, and we'd rather try to see the original shape that the tests are pinning down than monkey-patch the solution to fit the individual points.
It's interesting to see how one balanced these two. In this case particularly. Maybe you could play around with separating the data you give an LLM into "training set" and "validation set", training set can be seen fully, but validation set is hidden and is only queried when the solution is deemed ready. Say, training set = original source code + half of the tests; LLM uses that for quick feedback loop. And validation set = the remaining half of the tests; test code is not shown to the LLM and run only when the LLM says it's done to catch potential overfitting of the resulting solution over training set.
To me, the credibility of a solution like that would depend on what methodology the authors used. If they just let the LLM see all tests, I'd be skeptical (albeit unable to point out specific bugs due to the volume of work and LLM's ability to make bad things look trustworthy). The good thing is, real-life use will add new, unseen before datapoints for testing — so validation set will build up with time. Really curious to see how it will work.
Rust and its ecosystem needs to become more original. There are so many new problems that needs software solutions. Existing solutions that already work don't have to be rewritten in Rust.
Congrats for launching this project. I think it's awesome. I did two similar projects, just to learn how to work with LLMs and it felt good--reminded me times debugging code with GDB and going through stuff in semi-manual mode.
I'm building data + AI platform. It got complex, and I'm using AI-assisted coding to move fast. One thing that helps me was property based testing. I have a traffic generator that simulates 10 users working on my platform. I run it 24/7 and if it shows that the software survives the test (I called it "fate" after ffmpeg's CI), it's good enough to roll out. If you wrote something like that, core PostgreSQL folks would like it too, unless there's something equivalent like this. It'd be: create random tables, fill with random data, then issue randomly constructed query.
I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?
I suspect the future of open source will be to never publish your tests. Or someone will just pump them into an LLM like this.
Why should a developer use this for anything beyond a pet project? Just because it is written in Rust?
All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.
Jepsen or GTFO.
These days there's little chance for a new DB to build its community using network effect. If you want this to catch on, switch to manually grinding community building ASAP gold plating the experience for a specific niche (AI can guide your priorities but will hinder your comms). Otherwise, have fun building!
I don’t trust AI rewrites, definitely not in 2026 — possibly never.
Neat as a pet project, but anyone thinking of using this is production is insane.
Rewriten in Rust is becoming a meme now.
You got me with the rewrite, you lost me with AI.
Is the 300x performance boost attributable to the threading model vs process model?
Was the code for the threading model written by hand or was it translated from the WIP threading model the human PG team is busy with as part of the 2028 roadmap?
Setting aside the “why” that everyone is so focused on, I want to know, how? I can’t get Claude to do anything even a fraction of this complexity. How are people setting up their agents, Claude.md, etc to do such big projects? There are a lot of lessons to be learned.
Let's hope it did not special case (overfit) for the specific tests. One of the failiure modes that in my experience takes the most effort to mitigate for.
> <something> rewrite to rust using AI sound like meme now.
X written in Rust seems like the new Hello World for LLM coding agents now.
I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right now!"
I really don't understand why this is needed outside of an opportunity to show how impressive LLMs can be when working within large codebases, but even then people in the comments are finding bizarre implementation choices that a human developer wouldn't make. I'll stick with Postgres and its - gasp - C implementation for now, thanks.
This is a stunt for freshpaint.io that sells AI. No one will use this plagiarized monstrosity.
The code is so weird, people will have a hard time reading it when they need to check for correctness.
There are much better ways to write it in Rust: https://github.com/malisper/pgrust/blob/14ffab7d31a31e5ab667...
Quite a lot of projects are trying this "rewrite to a new language using LLM", both internally, or externally (like is here). For me, they confirm some (slightly controversial) takes.
1. human code reviews are dead. We don't yet know what's next. Two reasons they are dead: too much code to review, and code reviewing sucks (who wants to spend their days reviewing code?) 2. Not knowing how to review LLM code is a big barrier to adoption, but bigger regression test suites (testability/evals) is almost certainly the direction. 3. There are a lot of projects that haven't moved to more modern infra because it was too hard. Now it's much easier. Sure stuff will go wrong. Sure it all has to be tested. What's new here? 4. Programming languages for LLMs are coming. 5. Projects that don't allow AI coding will be forced to come around or fade.
Separately, bit off topic:
New projects will often have LLMs built in, so non-determinism will be inherent in the project. No amount of code review will be able to eliminate that.
I just want to quibble that the 100% Postgres regression tests do not test the threaded aspect of this project, and that is a pretty fundamental architecture change.
I think we will actually see some successful projects coming out of this. There are definitely people who want x old project in this new/better programming language and who are willing to put effort into maintaining it not just doing one off port.
I started my programming career by porting code from one model of TI calculator to another. It was code I could not have written from scratch myself at the time. I learned a lot about the two different versions of TI Basic that the calculators used, but I didn't learn how the program really worked. I can't even remember now if it was Tetris or the tank game that I ported. Maybe it was both? That was a boring English class...
I totally understand why porting code is fun. It's kind of like when I checked out drawing books from the library as a kid and just traced the pictures because my own attempts at drawing were so bad. It gives you a feeling of accomplishment, even though you didn't actually do anything that difficult. And you do learn some things along the way.
Doing the same with an LLM probably gives you that similar feeling of accomplishment, even though you didn't actually do that much (sorry, hate to say it that way). I wonder if you learn even less in the process. Maybe you just learn different things.
Now that I think about it, even writing some code from scratch with an LLM is not much different than doing a porting project. Someone else did the hard work of creating the original programs that the LLM was trained on, and now you (the LLM really) are just porting/restating what someone else did. I hadn't thought of that before
How is the performance compared to regular PostgreSQL?
I know it says it is not performance optimized yet, but if this succeeds, will it only bring more "memory safety" or is there a serious performance gain as well?
The WebAssembly demo that runs in your browser is a really neat touch: https://pgrust.com
codebase full of code that wouldn't fly in production.
I ain't no Rustacean - but 'unsafe' calls all over.
I think the cool thing about these projects is that even if test parity reaches 100%, some bugs are going to surface on the new project that don't exist on the original project.
This is usually a good example of a test case that the upstream project is not covering and can be contributed back.
Parity should be bidirectional, so definitely it is possible for both parties to benefit from it.
finally, a database that will refuse to compile your schema migration because you used an unsafe join. progress.
It is very bad metric to measure a rewrite using the original tests. It is like to say you clone a cat by mimic 600 cat images.
Database & AGPL bad combination
> rewrite of already popular technology in a different language > look at commit history > "Claude xxx committed yyy ago"
I'm sorry, but what is this need to just vibe code a port of an existing technology to a different language/framework/etc.? If it's just a personal challenge then sure I guess, but this surely can't be used as a real product?
It’s interesting to see how llms have turned the concept of rewrite it in rust, from an impossibility for some projects (code is too large and complicated, it will take too much time) to a real possibility for even large projects.
Where will this leave the c based driver which I believe is the basis for many others?
What would be interesting is if they found a memory unsafe bug. Postgres is a perfect case study of 30 years of C with a bit of CPP; if rewriting in a safer language didn't find anything...
> The goal is to make Postgres easier to change from the inside
uh-huh, sure.
you want to show off "look what the LLM can do / look what I burned a bunch of tokens on"?
you want to brag about how your LLM-generated slop is somehow more maintainable than the original because blah blah blah Rust?
here [0] is the version history of Postgres. pick a version from the past. let's say 14.x because it's the most current that's still under active support.
have your LLM implement version parity with 14.x. show off how it passes all the tests blah blah blah.
then have it upgrade your codebase to parity with 15.x, implementing whatever new features and bugfixes that includes.
and have it generate an automated test that demonstrates upgrading an actual database from LLM-14.x to LLM-15.x and verifying there's no data loss or corruption. maybe even multiple such tests, if you're feeling fancy.
then lather, rinse and repeat with 16, 17, and 18.
and show off the diffs of each version. does the LLM rewrite a huge pile of already-working code in the process of each version upgrade? does it introduce new latent bugs in the process - the kind of things the existing test suite didn't think to explicitly test for?
"I took a static snapshot of code and converted it to another static snapshot of code" is meaningless. all you're doing is bragging about having more money than good sense.
the stability and trustworthiness of software like Postgres does not come from a one-time snapshot showing tests passing. it comes from the engineering process that produces the software and its test suite.
oh, and for shits and giggles, because this same test was so illuminating with the Bun "rewrite" into Rust, here is the file with the most unsafe blocks in the codebase:
> rg -c unsafe crates/backend/parser/gram_core/src/convert_ddl.rs
128
> wc -l crates/backend/parser/gram_core/src/convert_ddl.rs
2055 crates/backend/parser/gram_core/src/convert_ddl.rs
why is the parser unsafe at all?!?
Rust feels like the just right language to produce all those slops of AI and the language itself. Great to promote yourself as a productive engineer, but at the end of the day you’re just reinforcing the statement that AI and the language itself are great, not you.
I love llm coding. I don't know what I am looking at here
https://github.com/malisper/pgrust/blob/main/Cargo.lock
What is happening.
No PRs? No Make files? I understand running tests and debugging is the workflow, but where do you log things? How do you orchestrate builds? Etc.
Did similar with S3 and that too (eventually) did well against tests (the ceph s3 ones).
...but haven't dared use it for anything meaningful yet. Still feels like there is a real world gap in confidence when it comes to vibecoded rewrites.
Been wondering whether the answer is to insert a proxy...something that effectively splits traffic to a known S3 and the rewrite and compares outcomes over time. Do that for a couple different workloads for a month or so and if it's all identical then it's probably fine...
Hey author here. Wasn't expecting to see this up.
To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture.
I'm now working on a new, not yet published version of pgrust that incorporates a lot of techniques. Currently the new version:
If you have any questions, I'm happy to answer them.