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
> How would one go about reviewing a piece of code like this?
That's a wrong question. The right question is "why would one go about rewriting a piece of code in X". Once and if you find a good answer to that question, you will see the answer to your's.
These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done.
In practice, this is never true for any codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.
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.
> not mostly the test, but the real world production scars
Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.
SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some guarantee of equivalent diligence.)
Sure, but behaviors that never have a bug or regression don't get a test. Software of this kind of complexity has all kinds of behavior that has never been broken, and doesn't have a specific test written for it.
Getting an extensive test suite passing is certainly orders of magnitude better than having no test suite at all, but it still doesn't tell you as much as you need to know. I would absolutely never trust an LLM Postgres rewrite (in any language) in production based on "only" Postgres's test suite passing.
I've also seen situations where a customer reports a bug, the fix breaks some regression, and the updated behavior to work around the fix breaking the regressions turns into an undocumented feature.
Or even a human rewrite merely because some language is the current fad. A rewrite in a different language should be done for very good reasons, to solve problems that are bigger than the costs of all the bugs that will be introduced.
This feels like the image of the plane that returns from battle with bullet holes, and the engineer being asked to path up where the holes to make it stronger. Only to be told to patch where there weren't holes as those planes didn't make it home.
While not an exact fit of an analogy, those tests patch what was a problem with Postgres in the wild. What it doesn't cover are the things that worked in Postgres without tests, but may fail in port and go undetected.
The maintainers that wrote those tests will have experience you won't get out of a rewrite.
I think this is also where the real work is. A rewrite is one thing, that you can show off with a flashy blogpost. The maintenance, for years to come, won't be of that nature yet it still requires as much work.
> Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.
If you can be 100% guaranteed that there indeed is a test for every occurred bug. Sometimes maintainers are not so strict about it.
And some programmers are so good that some issues are self-explanatory and they write good code to note a thing but don't write a test, because implementing the test is more expensive.
So you get other bugs when rewriting in another language without existing tests, got it. This is why I hate all the announcements of "it is rewritten in rust so it is obviously better than the original since it passes all the tests". Edit: and it's an LLM rewrite. Add that to the pile of over hyped messaging.
Unfortunately, too many people are getting captured by marketing and are divorcing themselves from reality. Usually, a rewrite can be an improvement, even if in the same or any other language.
There are also levels, in terms of quality and human code review, when dealing with rewrites. New bugs can be introduced or there can be style issues, that can take time to fully reveal themselves, and particularly if the person or people involved are not familiar with the other language.
very naive. the runtime behavior of a rewrite should be significantly different in all kinds of unpredictable ways nobody see coming or might expect. It is a combination of language semantics, compiler behavior, operating system behavior, file system behavior, driver behavior, ..
As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.
The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.
And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.
Now the new, test-based implementation, has to prove it can handle remaining 99%.
And also the amount of people running it in thousands of scenarios. Not sure if these areas can be even tested for, but I guess time will tell (can observe Bun if it breaks somewhere as that’s afaik the first big AI rewrite which got into prod for masses).
A lot of the signal (github, forums, mailing lists, discord, etc.) can be turned into signal. Right now it's easy enough to collect. In future it will be easy enough to cluster and generate preferences, experience, etc.
Every bug report, code change as a result, PR / commit message, PR comment that steers preferences, etc. is solid signal to generate future tests.
I agree. I also agree with the sibling reply that -
> every time you have a bug or a regression, you write a test that confirms correct behaviour.
What I fail to see in these rewrites however is - what about new bugs introduced by virtue of this rewrite? I mean it'll have to go through its own challenges in real-world scenarios, right?
The test suite is the result of these years of years of running in production. Every time you fix a bug, you add a non-regression test to ensure you don’t break it again.
In a project like PostgreSQL, those scars are reflected in unit tests demonstrating that they’re fixed. It’d be hard to pass its test suite and not be as robust as the original.
> It’d be hard to pass its test suite and not be as robust as the original.
This is not true, even in principle, even for Postgres itself. You'd be right to say that it'd be hard to pass the test suite and not be robust at all to some extent. But even in Postgres, I bet that you can quite easily introduce a change that will pass the whole test suite but reduce robustness compared to the latest release (for a somewhat silly example, add a call to `exit()` on a timer that's longer than the longest duration test in the suite - that will significantly reduce robustness while still passing the entire test suite).
Sure but these scars/tests are from the original implementation. Just because it doesn't have issues there doesn't mean it didn't bring its own set of issues
This is all well and good in theory, but the number of times I've seen tests that don't actually test what they say they're testing is hard to count. Yes even when you encourage the developers to ensure the test fails first and do TDD. Tests help you ship with confidence but there's usually at least a few that are just passing by pure luck.
So no, I wouldn't judge a rewrite as being equal just because it passes the tests. That said, I don't think that means you shouldn't do it. You just have to be pragmatic about it.
Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.
I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.
What is this even for logic?
I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.
And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.
That's precisely what a regression test suite is for. There is a bug, you fix the bug, you add a regression test. So if the test suite is well maintained these real world production scars are reflected in the tests.
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.
> significant part of the rust community consists of software talibans
I seriously don't get it though. Rust is a nice language, but so is X. However we don't see X people brigading existing projects with constant bombardment with "rewritten in X". What is that about Rust that prompts this behavior?
Well, this approach is more similar to imposing a dogma thank engineering.
Is managing memory safely important? YES
Is managing memory safely the solution to most of the problems? Absolutely not.
Advocating the language ignoring everything else (having as first and only argument that the code was rewritten in rust fully qualify for this case) is dogma and not engineering.
> Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.
> the biggest blocker on moving to a new programming language, is the cost of re-writing everything
In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?
I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs.
You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.
I have no issues recognizing that I had memory-related problems in production (I program embedded systems in C).
But most of my issues were related to concurrency and data sanification, especially when the other end of communication fails with unexpected behavior. These bugs are nastier than memory.
So, I have pointers, and I am not afraid to use them.
For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.
So how much AI usage does it make it an “AI rewrite”?
Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.
Who wants to contribute to an unmaintainable code base?
Well, it’s up to the user or post-trainer of the LLM what they believe to be above average. Then they can design around that.
In the case of real world LLMs and post-training, what is above average is defined roughly as: labeled good by expert humans, and scoring high on RL environments related to coding like debugging, passing tests, or running efficiently and verifiably correctly.
It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.
I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!
Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?
AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previously great devs are throwing in PRs that touch hundreds of files at once with one commit.
A lot of people I previously considered great developers have become people I would not recommend for a job in the past 2-3 years.
> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary.
Sure, but this is just begging the question. If nobody could tell, the term 'slop' wouldn't have become so popular.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Aren't you making a strawman argument ? AFAIK this project is not made by an official PostgreSQL core developer, so the entire premise of your argument is invalid.
But that's the thing, without the decades of work, it wouldn't BE trivial.
Everyone is standing on the shoulders of those which came before. If LLMs allow us to combine the incredible decades of effort and knowledge and experiences that's gone into building something as great as Postgres, and take that and combine the experience and philosophy that has led to the creation of a language that potentially provides tangible benefits, and for far less human time and effort that it would have otherwise taken...surely something that should be celebrated as absolutely incredible?
That's how Ai generated code is. I am almost convinced that Models are intentionally taught to write obtuse code because AI companies don't want us to write code at all
I don't really understand how "written by AI" and "for learning purposes" can ever be compatible. What exactly does one learn from typing "Rewrite this in Rust, make no mistakes" into a terminal?
You are now at 0.1%... now submit upstream in sensible chunks (function or maybe file/module), waiting for people to review (a few per week, maybe) and approve/merge.
Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.
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.
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?
I also suspect this will die very shortly, which is a real shame, not because it will be beneficial but because of the time and tokens needlessly spent on something that will be thrown out.
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.
> 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:
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...
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.
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.
When the software consists entirely of ~$1000 worth of Claude credits and ~40 hours of developer time prompting and curating it, literally what does it matter what license the resulting 100k LoC artifact is provided under?
Copyleft and the whole software licensing ecosystem only matter when producing that software actually requires serious human effort and dedication.
For my machine translation of SQLite to Go I added this to the README as to licencing:
Most of the code here is machine translated using wasm2go. As such, the original authors retain copyright and the original licenses remain in effect. Everything else is licensed under MIT-0.
The translator (wasm2go) has a licence chosen by, and a copyright notice from, me. Makes no sense for the translated code.
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.
How do you know it's not SQL-lite with the single L serving a double role?
Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.
AFAIK there is no official word on how the name is intended to be read or said.
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.
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.
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.
I make no claim as to whether the change makes sense given that I didn't look at the callers of this function, but Result<bool> is an entirely reasonable pattern in Rust. If you want the callers to be able to distinguish between "has the subclass", "doesn't have the subclass", and "something went wrong" this is idiomatic Rust.
It is a feature in Rust, not a bug :-) (I know you didn't say it is a bug.)
The error-tagged union is PgResult<bool> - which means it contains bool as the result if things go well. (The other part in the union is of course the error.)
In the original function also, it is returning a boolean: "bool has_subclass".
So anyway you have to check for the boolean as part of the logic. That is what it is doing.
Yes, but the original boolean seems to have been used for error handling, and the tagged union is also used for error handling. Why have both simultaneously in the same function instead of just one of the two?
Edit: Looking at the code again, perhaps I was mistaken, since the boolean might not have been for error handling, just the result of the function, and C's limitations regarding error handling led it to using something like elog(), apparently a macro defined in https://github.com/postgres/postgres/blob/master/src/include... .
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.
From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function?
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-...
> How would one go about reviewing a piece of code like this?
That's a wrong question. The right question is "why would one go about rewriting a piece of code in X". Once and if you find a good answer to that question, you will see the answer to your's.
The github cli has a command to query commits with a sorting asc/desc flag
https://cli.github.com/manual/gh_search_commits
here's the docs with more syntax using the "before x date"
https://docs.github.com/en/search-github/searching-on-github...
there's also an advanced search page, but it does not support commits when filtering with dates
https://github.com/search/advanced
or you can bisect the date in the search widget, this is the first day with a commit
https://github.com/malisper/pgrust/commits/main/?since=2026-...
first commit:
https://github.com/malisper/pgrust/commit/22113dc36b02973060...
Vibe code was never meant to be reviewed.
These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done.
In practice, this is never true for any codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.
And run them in test setups to try to find bugs.
If you find some, fix them.
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.
> not mostly the test, but the real world production scars
Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.
SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some guarantee of equivalent diligence.)
And yes, years and years of running.
Sure, but behaviors that never have a bug or regression don't get a test. Software of this kind of complexity has all kinds of behavior that has never been broken, and doesn't have a specific test written for it.
Getting an extensive test suite passing is certainly orders of magnitude better than having no test suite at all, but it still doesn't tell you as much as you need to know. I would absolutely never trust an LLM Postgres rewrite (in any language) in production based on "only" Postgres's test suite passing.
> Software of this kind of complexity has all kinds of behavior that has never been broken
This space of things is astronomically larger than the space of things expressly covered by any test suite.
"Program testing can be used to show the presence of bugs, but never to show their absence." -Edsger W. Dijkstra
I've also seen situations where a customer reports a bug, the fix breaks some regression, and the updated behavior to work around the fix breaking the regressions turns into an undocumented feature.
Or even a human rewrite merely because some language is the current fad. A rewrite in a different language should be done for very good reasons, to solve problems that are bigger than the costs of all the bugs that will be introduced.
Agreed.And a rewrite in another language creates a high probability of a change in behaviour
This feels like the image of the plane that returns from battle with bullet holes, and the engineer being asked to path up where the holes to make it stronger. Only to be told to patch where there weren't holes as those planes didn't make it home.
While not an exact fit of an analogy, those tests patch what was a problem with Postgres in the wild. What it doesn't cover are the things that worked in Postgres without tests, but may fail in port and go undetected.
The maintainers that wrote those tests will have experience you won't get out of a rewrite.
I think this is also where the real work is. A rewrite is one thing, that you can show off with a flashy blogpost. The maintenance, for years to come, won't be of that nature yet it still requires as much work.
> Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.
If you can be 100% guaranteed that there indeed is a test for every occurred bug. Sometimes maintainers are not so strict about it.
And some programmers are so good that some issues are self-explanatory and they write good code to note a thing but don't write a test, because implementing the test is more expensive.
One issue is those are the bugs you get when you write it in C++.
They aren't the bugs you get when you write it in Rust.
The kind of bugs you get are usually a function of the problem, language, implementation approach.
So you get other bugs when rewriting in another language without existing tests, got it. This is why I hate all the announcements of "it is rewritten in rust so it is obviously better than the original since it passes all the tests". Edit: and it's an LLM rewrite. Add that to the pile of over hyped messaging.
Unfortunately, too many people are getting captured by marketing and are divorcing themselves from reality. Usually, a rewrite can be an improvement, even if in the same or any other language.
There are also levels, in terms of quality and human code review, when dealing with rewrites. New bugs can be introduced or there can be style issues, that can take time to fully reveal themselves, and particularly if the person or people involved are not familiar with the other language.
a code written to pass a test can surface unintended new bugs.
very naive. the runtime behavior of a rewrite should be significantly different in all kinds of unpredictable ways nobody see coming or might expect. It is a combination of language semantics, compiler behavior, operating system behavior, file system behavior, driver behavior, ..
As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.
The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.
And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.
Now the new, test-based implementation, has to prove it can handle remaining 99%.
And also the amount of people running it in thousands of scenarios. Not sure if these areas can be even tested for, but I guess time will tell (can observe Bun if it breaks somewhere as that’s afaik the first big AI rewrite which got into prod for masses).
A lot of the signal (github, forums, mailing lists, discord, etc.) can be turned into signal. Right now it's easy enough to collect. In future it will be easy enough to cluster and generate preferences, experience, etc.
Every bug report, code change as a result, PR / commit message, PR comment that steers preferences, etc. is solid signal to generate future tests.
I agree. I also agree with the sibling reply that -
> every time you have a bug or a regression, you write a test that confirms correct behaviour.
What I fail to see in these rewrites however is - what about new bugs introduced by virtue of this rewrite? I mean it'll have to go through its own challenges in real-world scenarios, right?
The test suite is the result of these years of years of running in production. Every time you fix a bug, you add a non-regression test to ensure you don’t break it again.
Completely agree with this.
The biggest lie of software engineering is that everything can be testable with tests. That a 100% test coverage is an indicator of quality software.
In a project like PostgreSQL, those scars are reflected in unit tests demonstrating that they’re fixed. It’d be hard to pass its test suite and not be as robust as the original.
> It’d be hard to pass its test suite and not be as robust as the original.
This is not true, even in principle, even for Postgres itself. You'd be right to say that it'd be hard to pass the test suite and not be robust at all to some extent. But even in Postgres, I bet that you can quite easily introduce a change that will pass the whole test suite but reduce robustness compared to the latest release (for a somewhat silly example, add a call to `exit()` on a timer that's longer than the longest duration test in the suite - that will significantly reduce robustness while still passing the entire test suite).
Sure but these scars/tests are from the original implementation. Just because it doesn't have issues there doesn't mean it didn't bring its own set of issues
This is all well and good in theory, but the number of times I've seen tests that don't actually test what they say they're testing is hard to count. Yes even when you encourage the developers to ensure the test fails first and do TDD. Tests help you ship with confidence but there's usually at least a few that are just passing by pure luck.
So no, I wouldn't judge a rewrite as being equal just because it passes the tests. That said, I don't think that means you shouldn't do it. You just have to be pragmatic about it.
Passing a regression test suite only proves that those particular regressions aren't present. It proves nothing about robustness beyond that.
You immply that a testcase exists for every weird edge case. Especially filesystem and concurrency is things you can barely build test cases for.
Even a 100% test coversge is far away from verifying all behaviour.
They ought to, but are they? In https://wiki.postgresql.org/wiki/Developer_FAQ I don't see a requirement to provide a regression test for a bug fix.
It would be reasonably easy to audit and automate this...
Edsger W. Dijkstra:
"Program testing can be used to show the presence of bugs, but never to show their absence!"
I hope you are not true at all.
Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.
I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.
What is this even for logic?
I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.
And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.
That's precisely what a regression test suite is for. There is a bug, you fix the bug, you add a regression test. So if the test suite is well maintained these real world production scars are reflected in the tests.
Wait - does the AI rewrite the tests too? If so, lol.
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.
> significant part of the rust community consists of software talibans
I seriously don't get it though. Rust is a nice language, but so is X. However we don't see X people brigading existing projects with constant bombardment with "rewritten in X". What is that about Rust that prompts this behavior?
> software talibans
I will note that, very funny
Well, this approach is more similar to imposing a dogma thank engineering.
Is managing memory safely important? YES
Is managing memory safely the solution to most of the problems? Absolutely not.
Advocating the language ignoring everything else (having as first and only argument that the code was rewritten in rust fully qualify for this case) is dogma and not engineering.
Yeah I'm using that one.
We have a problem with software religious fundamentalists in our organisation and it's an apt description.
what does it mean ?
Pushy fundamentalists, I suppose.
Yes
Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything.
Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
These LLM conversions really seem to make modernization of large parts software layers possible!
> Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.
> the biggest blocker on moving to a new programming language, is the cost of re-writing everything
In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?
I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs.
You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.
The cost of surface level rewrites has crashed. Which will probably cover 80% of cases. Caveat emptor on which side your project falls.
I have no issues recognizing that I had memory-related problems in production (I program embedded systems in C).
But most of my issues were related to concurrency and data sanification, especially when the other end of communication fails with unexpected behavior. These bugs are nastier than memory.
So, I have pointers, and I am not afraid to use them.
I feel like we need to heavily differentiate between a rewrite and an AI rewrite.
For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.
So how much AI usage does it make it an “AI rewrite”?
Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.
Who wants to contribute to an unmaintainable code base?
When the majority of the code is written by AI, it is more than 50%.
I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.
AI is an average coder.
It was trained on all code the code that could be found.
Not just code written by genius programmers like Carmack and Bellard.
Given that it's average, I'd prefer a human coder above average :)
LLMs learn a distribution during pre-training, not only an average.
Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.
> Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.
How do you derive that something is "below average" or "average" or "above average"?
Well, it’s up to the user or post-trainer of the LLM what they believe to be above average. Then they can design around that.
In the case of real world LLMs and post-training, what is above average is defined roughly as: labeled good by expert humans, and scoring high on RL environments related to coding like debugging, passing tests, or running efficiently and verifiably correctly.
Which you will necessarily have if they’ve completed a Rust rewrite.
You haven't been using AI extensively I presume...
I've been programming a long time and considered myself among the top in my domain and AI agents using like GPT 5.5 etc. are much better than me.
> and considered myself among the top in my domain
Is the domain bullshiting?
> You haven't been using AI extensively I presume...
Ex falso quodlibet
> I've been programming a long time and considered myself among the top in my domain
I am not trying to attack you, but you considered yourself that... I don't know whether you actually were and frankly I don't care.
Or, you know, you can use Postgres. It's right there for you.
rewrites feel like an area where LLMs are better suited than humans imo
It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)
It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.
You underestimate what people are willing to do just for fun.
Yeah like what do they think the people porting doom to everything possible are thinking?
I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!
It's not that... It's a rewrite by project maintainers vs a fork.
It’s just a build step now.
Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?
AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.
Didn't the initial rewrite of Bun into Rust have an ocean of "unsafe" in it, and wasn't it entirely dysfunctional?
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previously great devs are throwing in PRs that touch hundreds of files at once with one commit.
A lot of people I previously considered great developers have become people I would not recommend for a job in the past 2-3 years.
> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary.
Sure, but this is just begging the question. If nobody could tell, the term 'slop' wouldn't have become so popular.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Aren't you making a strawman argument ? AFAIK this project is not made by an official PostgreSQL core developer, so the entire premise of your argument is invalid.
Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?
Because it’s uncomfortable to see decades of work copied so trivially.
But that's the thing, without the decades of work, it wouldn't BE trivial.
Everyone is standing on the shoulders of those which came before. If LLMs allow us to combine the incredible decades of effort and knowledge and experiences that's gone into building something as great as Postgres, and take that and combine the experience and philosophy that has led to the creation of a language that potentially provides tangible benefits, and for far less human time and effort that it would have otherwise taken...surely something that should be celebrated as absolutely incredible?
I can trivially copy any code even without an LLM though with a simple tool called rsync!
I am concerned about the quality. Even a cursory skim of the code makes the code appear asinine. Unless the genius aspects of the code elude me.
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
Yeah same. The structure makes no real sense and when digging into the code it reads like I'm the first human to look at it.
That's how Ai generated code is. I am almost convinced that Models are intentionally taught to write obtuse code because AI companies don't want us to write code at all
I don't really understand how "written by AI" and "for learning purposes" can ever be compatible. What exactly does one learn from typing "Rewrite this in Rust, make no mistakes" into a terminal?
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 think a business case for a "look I let an LLM rewrite a large codebase" does not exist.
You are now at 0.1%... now submit upstream in sensible chunks (function or maybe file/module), waiting for people to review (a few per week, maybe) and approve/merge.
Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.
Well, I will give 7/10 as an FYP
> <something> rewrite to rust using AI sound like meme now.
https://news.ycombinator.com/item?id=48474313
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.
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?
I also suspect this will die very shortly, which is a real shame, not because it will be beneficial but because of the time and tokens needlessly spent on something that will be thrown out.
Neat as a pet project, but anyone thinking of using this is production is insane.
Rewriten in Rust is becoming a meme now.
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.
> 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:
why does a single 2000-line file have over 100 unsafe blocks?why is the parser unsafe at all?!?
0: https://en.wikipedia.org/wiki/PostgreSQL#Release_history
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...
You are exactly right. There is no freaking way there was no unsafe behavior in a code case of the size of Postgres.
In fact from a porting effort this is the first blog post I would expect. Not that the hey we successfully did it.
I wonder how long this will be maintained for...
As long as tokens are cheap
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.
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.
When the software consists entirely of ~$1000 worth of Claude credits and ~40 hours of developer time prompting and curating it, literally what does it matter what license the resulting 100k LoC artifact is provided under?
Copyleft and the whole software licensing ecosystem only matter when producing that software actually requires serious human effort and dedication.
Also can the code even be copyrighted?
For my machine translation of SQLite to Go I added this to the README as to licencing:
Most of the code here is machine translated using wasm2go. As such, the original authors retain copyright and the original licenses remain in effect. Everything else is licensed under MIT-0.
The translator (wasm2go) has a licence chosen by, and a copyright notice from, me. Makes no sense for the translated code.
Does it support the extension ecosystem? Or would extensions need to be rewritten as well?
They would need rewriting (a few are included)
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.
How do you know it's not SQL-lite with the single L serving a double role?
Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.
AFAIK there is no official word on how the name is intended to be read or said.
Now which one is safer? A new Postgres written in Rust, or the original real world tested Postgres?
Also, are they calling it Postgrust?
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.
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.
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.
I make no claim as to whether the change makes sense given that I didn't look at the callers of this function, but Result<bool> is an entirely reasonable pattern in Rust. If you want the callers to be able to distinguish between "has the subclass", "doesn't have the subclass", and "something went wrong" this is idiomatic Rust.
It is a feature in Rust, not a bug :-) (I know you didn't say it is a bug.)
The error-tagged union is PgResult<bool> - which means it contains bool as the result if things go well. (The other part in the union is of course the error.)
In the original function also, it is returning a boolean: "bool has_subclass".
So anyway you have to check for the boolean as part of the logic. That is what it is doing.
Yes, but the original boolean seems to have been used for error handling, and the tagged union is also used for error handling. Why have both simultaneously in the same function instead of just one of the two?
Edit: Looking at the code again, perhaps I was mistaken, since the boolean might not have been for error handling, just the result of the function, and C's limitations regarding error handling led it to using something like elog(), apparently a macro defined in https://github.com/postgres/postgres/blob/master/src/include... .
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.
Is this another llm-driven rewrite?
I wonder how many "unsafe" blocks are in there...
From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function?
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
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.