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.
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.
AI is a great use for this kind of boring, rote translation where precision is important. Humans are quite bad at it and tend to make mistakes. In either case the focus should be on improving testing, not trying to manually verify if the translation was correct by eye.
The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long as the original. And that's where it all falls apart, because maintenance will be a nightmare. Nobody knows how the new thing works.
Ladybird's Rust port of the JS engine was a good example. Compare the output byte-for-byte, run both in production (with the new code disabled but checked) before releasing. It was LLM-translated but done carefully.
I mean, yes? Every engineer on my team produces better code than Claude. There are plenty of examples of excellent human produced code, so this argument always falls flat for me.
`mostly` is doing a lot lifting here. The Go rewrite uses plenty of copilot. The reason you trust it is because you trust the people doing the rewrite.
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.
How do you break a regression? A regression is breakage. Are you one of the people who use "regression" to mean "regression test"? Did Codex learn this from you? I hate it.
The same basically holds for proofs in the absence of coherent global correctness criteria like, say, confluence and normalization for a lambda calculus, or soundness and completeness for a logic.
Fable's napkin estimate of the effort required to produce a passable reference semantics for Postgres, which would involve novel discoveries in denotational semantics of concurrent transactions and so on, might be in the ballpark of 30–60 years of PhD level work.
So realistically I think the only way to validate a Postgres implementation involves differential testing, fuzzing, acceptance test suites, etc. And still you'll have bugs that need to be hammered out the good old fashioned way.
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.
Perhaps before embarking on one of these rewrites the first step should be a heavy round of mutation testing and property based testing. Contribute any new testing code from this back to the original project. And *then* embark on the rewrite.
If that's your concern, then your argument becomes "software should never change". Why dare patch any bug ever? It might be load-bearing in some unknown, undocumented, unsupported workflow somewhere in the world. No test imaginable can catch that apart from the scream test.
There are reasonable arguments against language ports, but this is not one. You're making an argument against code changing at all ever.
> 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.
> 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.
You don't write a test (just) to verify that your change fixed the issue, but to ensure it doesn't regress in the future after an unrelated refactor.
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.
I don't necessarily disagree, but two other points to consider:
1. Every test that is written is another use case that wasn't tested before. 100% test coverage is often impractical, but the more tests you have the more of the code you can be confident about.
2. Every test you add is another regression that can't happen in the future; if you test the index rebuilding code and validate the output then you know that you aren't going to make a change that breaks the index rebuilding code. If you have a legitimate change you update the tests, but if you're not expecting the change then you know there's a bug somewhere.
Anything that doesn't have tests is unspecified behaviour. While it is true that a port may differ in behaviour where the behaviour is unspecified, "fail" is not the right framing as there is no definition of what it should do.
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, ..
yea, I found LLMs poor at reasoning through concurrency. Good luck to the vibers when they try to rootcase a rare data-corruption problem. They will hand it off to fable which will do trial-and-error bug fix attempts, and eventually fail. What happens then ?
So many comments here talking about the downsides. The only reason to do a rewrite is because there are massive upsides. Maybe the implicit point is that the upside (memory safety must be the biggest), isn't worth the downside (lots of bugs to be figured out before you trust it).
I find a lot of HN discussions quickly turn into thought experiments and philosophical debates that largely forget the original topic. For the most part, I find this idiosyncrasy charming and entertaining, but it does frequently result in forests being missed for the trees.
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.
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.
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?
100% agree. And I am one of those people that (out of curiosity) am doing something similar. Yes, all tests pass today but tsz is nowhere near a complete project. For tsz it was rather easy to prove "passing all tests" ≠ "it is ready"
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.
> I start to see a lot of these re-writes that depend on tests to state that its working.
There's another way to validate the rewrite though. Just run both pgrust and postgres and compare the output. Know of an edge case? Run it too. Doesn't know? Use a fuzzer or some automated tool to find interesting inputs. Found an inconsistency? The input/output pair becomes a test case now
Not sure if there's tooling for that though. If there is, just give it to Claude so they will incorporate it in their development loop
I can recommend proptest. What you're describing is a common pattern in property-based testing which basically boils down to "comparing against an oracle". In this case, postgres would be the oracle, pgrust is the system under test, and the idea is to generate strategies comprised of sequences of valid (and invalid) SQL statements and ensure the system under test behaves the same as the oracle in every case.
Indeed. This approach is an improvement / augmentation over tests, not a panacea.
Neither postgres nor pgrust have their behavior specified using formal methods. (pgrust could write some contracts using something like kani or creusot, but having upstream postgres also write contracts is a tougher sell). If they had, one could write a giant proof that said the two software essentially do the same thing (at least in a subset of environments and some simplifying assumptions)
That's not relevant though. All concerns are secondary to security and Rust is the only language with security GUARANTEES. No other language is as secure. Therefore, even the worst Rust rewrite is automatically better than the best work in any other language, because it is the only one with guaranteed security.
If a Rust rewrite of any of your software becomes available and you aren't installing it immediately and without reservation, then you are simply not giving security the priority it both demands and deserves, and that makes you disastrously insecure. This is a serious issue that should be given all priority. There is no room for debate. Your only policies should be security before all else and compliance with those policies must be absolute and without deviation, or all is lost.
> If a Rust rewrite of any of your software becomes available and you aren't installing it immediately and without reservation
This is silly.
Rust is awesome, and it's hard to argue against in many domains. However, software is more than the language it is written in or the runtime serving it. Is the Rust rewrite fully compatible? Is it supported by a strong community? Is it likely to continue to be supported? Is its release cadence sensible? Is its licence compatible with your intended usage?
There are many questions needing to be answered before making rash decisions based purely on tech.
None of those concerns approach the level of priority that must be assigned to security. On defense, your security must be perfect forever or you are absolutely defeated. None of us are on the red team. It's not a rash decision, it's the only decision that logic allows. If you are not secure, you are NOTHING.
I strongly disagree. The easiest way to shut down your business is to insist on being 100% secure because the only way to have perfect security is to do nothing.
Also, there is more to security than memory errors. SQL injection, authentication, and access rules matter. It doesn’t matter if Rust database is secure to bad data if it lets anyone in to do anything. Or if it is crashing all the time or corrupting your data.
Not weighing in on this specific rewrite but tests are how you specify that your software works correctly. If a behavior isn’t covered by an automated test in some form you can’t assert that any given change doesn’t break it.
I think it is completely reasonable to use a preexisting unmodified test suite to state that something is working. The larger the project the more true this becomes. Real world production scars are documented and guarded against in the test suite otherwise those lessons get lost.
Also SQLite is legendary for its massive test suite and extensive fuzzing. They have 590x the amount of test code and scripts than normal code. Source: https://sqlite.org/testing.html
So, we should make it easier to feed that reliability back upstream.
Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!
If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.
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.
> Copyleft and the whole software licensing ecosystem are only applicable when producing software that actually required human effort.
Fixed that for you. Code generated by an LLM is not copyrightable (because copyright only protects human effort), so the codebase is automatically public domain and cannot be licensed at all.
They could theoretically copyright the prompts that they used, but as that's not part of the output, and the output doesn't deterministically arise from those prompts, they'd struggle to use that to back a copyright claim.
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 or SQL-ite or SQL-lite or SQ-lite.
AFAIK there is no official word on how the name is intended to be read or said.
Interesting, thanks for mentioning that. I've always wondered about the origins of the name, never found anything, but now with your mention of "mineral" I was able to find this:
> (Hipp) How do I pronounce the name of the product? I say S-Q-L-ite, like a mineral.
> But I also hear a lot people say, "Sequel lite and SQL lite." You know, I don't care. Whatever comes off of your tongue easily is fine with me.
It is theoretically possible to have a Rust port of Postgres support extensions. If you make all the relevant functions and structures ABI compatible with Postgres, extensions should work. The issue is the moment you're dealing with C pointers and C strings, pretty much all the code you have to write is unsafe.
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.
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 would expect Postgres to be heavily tested with things like Valgrind and various sanitizers. I'd be surprised if there were low-hanging fruit. But also, if there is code that does something fishy with pointers, wouldn't the AI likely paper over it by adding an unsafe block in the Rust version, preserving the same fishiness? It's hard to know how hard it would try to prove that the original is broken.
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.
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.
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.
I actually had a lot of problems with software cult followers of influencer gurus like ThePrimeagen, Lex Fridman, Theo, etc... Those are so worst. You can't resonate with them.
> 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 existing system works. Yes, it costs a lot to maintain, and you could definitely reduce that if you moved to a more modern system. So now you're talking payback periods. Cost of development / maintenance cost savings per year = number of years before you pay back the project.
Problem is, that the cost of the development is often unclear, and the maintenance cost savings, while definitely above zero, and often unclear, and approximated the numbers usually come to a payback period in decades.
And that's without the usual tech caveats; We can't promise there won't be bugs. We can't promise deadlines will be met. We can't promise the project will succeed at all. We can't promise existing functionality will be faithfully reproduced in the new system. The normal risks around any software dev project.
All in all, it looks really expensive and really risky compared to just doing nothing and running the same old system for another five years.
Source: I helped do some of the maths on this for a Y2K project.
I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue.
Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
> while you could ask your LLM to do that you aren't going to run your bank on the result.
Why not?
I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences.
The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them!
So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output?
At the end of the day, humans are not without fault either.
I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception.
As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans.
[1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.
Because you know that the current one works. If you have a bank running on COBOL (or whatever), you've had that for 30+ years now, so while it might have bugs, you know what they are. You don't know what the LLM output is. Hence back to my original point: writing the code is not the hard bit. Making yourself (and your CEO etc) comfortable to put that into production is one of the hard bits.
Okay, so it doesn't work, you know it doesn't work, it's just that you accept the specific ways in which it doesn't work.
I've lost track of all the myriad stupid ways in which these ancient systems are hugely ineffectual without even being outright faulty.
Like airline tickets where your name is printed as "LASTFIRSTMR" in all caps and no spaces because their systems are ancient beyond belief.
Similarly, my bank statements are security-critical, because anyone with a copy of my credit card details can pull money out of my account without my express authorization. But...
... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!
I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.
If you look at it from the perspective of someone used to modern web security, then you realise that banking is a raging tyre in comparison. Banks literally just accept a certain rate of criminal activity and "price that in", reversing transactions when asked -- which itself can also be a criminal activity. They just shrug their shoulders.
"What can we do about this?" -- says the people that have tried nothing and are all out of ideas.
Rewrite it. The whole thing.
Use an actual database, something made in the last three decades instead of half a century ago.
Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.
Etc.
I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.
It runs and accepts people's payments, which means you're not on the front page of the newspaper (not in a good way).
> ... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!
They also have to go through payment networks which are very often the limits on those things. So yeah, it sucks, but just fixing one DB isn't enough - the whole thing has to get upgraded.
> I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.
There is a little bit, but not much. Again, if these transfers are happening via card, it's all a terrible old fixed-length setup. Would be great if it was better, but you need Visa and Mastercard to upgrade as well.
And of course there _is_ verification - most banks don't do a great job of surfacing this but they know if they've verified a PIN or CVC, or if it was contactless (in which case it _is_ unverified, but society realised we prefer the convenience there).
> Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.
Obvious question then: You've made a card transaction. It is signed with the other party's private key. What does that buy you? How do you attach trust to this key? Whose is it - the payment gateway or the merchant?
> I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.
Sure, and if the LLM can rewrite enough of this system to get what you want, there's heaps of room for improvement. But this is orders of magnitude bigger in scope than rewriting your one old bit of COBOL software, it's systematic.
> It runs and accepts people's payments, which means you're not on the front page of the newspaper (not in a good way).
"It works if nobody attacks it." isn't security.
> They also have to go through payment networks which are very often the limits on those things.
For the same reasons.
> need Visa and Mastercard to upgrade as well.
They won't, and it's not worth asking them to. They're dinosaurs and will simply be replaced by a newer, more agile competitor.
It's already happening! Billions of people in Asia pay with their phones using home-grown payment systems, most of which are generally much more modern and better engineered.
> It is signed with the other party's private key. What does that buy you?
Same as what HTTPS does: attestation of identity by some trusted third-party, to some non-zero level. This could be literally just the existing CA networks and DNS domains as identity, but it could be governments, the banks themselves, etc.
I had some fraudulent transactions on my account labelled "Microsoft Subscription". It wasn't Microsoft. How can I tell?
Not even the bank knew the identity of the third party!
> but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
If only we had a way to solve these issues with tools capable of running Rust programs in that way. I guess every company that needs distribution / failover has a mainframe sitting in their office nowadays huh?
You could run one of these things on a mainframe, because it's a zero-downtime machine - you can swap out parts of them as they run. But fundamentally it's a singleton. It is deeply naive to believe you can trivially translate that to something running on Kubernetes just "because Rust".
Of course most companies that need distribution do manage to do that, and eventually the banks will get there too. But it isn't feasible to do that by translating their existing non-distributed COBOL code, they need a fundamental re-architecture, and that is much harder.
It's not enough to do a rewrite. Someone has to maintain it. Such a huge codebase with literally zero experts is unmaintainable. There is no one who knows how the internals work.
Sure you could keep vibe coding it but I wouldn't bet my data on that. A database needs to be rock solid.
At the same time, that was historically the only reason for moving to a new programming language: everything needing to be rewritten meant all the cruft accumulated in earlier programming languages was reset.
> 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?
Rust attracts zealots because of the various kinds of safety guarantees. The speed means it can replace more or less anything.
People see the safety as a moral superiority so it attracts obnoxious zealots.
Other languages' features and syntax aren't nearly so easy for zealots to form behind. The perception of absolute safety it puts in some people makes them crazy.
People were told for years they can't use Rust for their new projects because it hasn't been "proven" in industry yet. So the option was to sit back and wait (chicken and egg) or move to rewrite a bunch of projects so that it could actually be "proven". Not saying this is the only reason why it happens (every language has its Zealots) but it certainly makes more sense.
Due to the explosion of new programming languages over the past few decades your options are to either aggressively expand wherever possible or die out because you're not "proven".
what do you mean by that? were there people brigarding postgres to rewrite to rust? otherwise relative to popularity i do also constantly see posts on here about Project X rewritten in Go, Zig, C etc...
> Why should a developer use this for anything beyond a pet project?
If it _is_ 50% faster, then that's the reason
Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?
As someone who loves Rust the language and tool set: This class of projects [LLM rewrite of a reliable piece of software honed over decades) is embarrassing.
If you are watching this and haven't used rust: Please don't judge the language by this part of its users.
The community is what makes the language. If the community is toxic, than the language becomes toxic.
One stinks the other even if it's the shiniest plate in the cake shop. My first thought to starting a project in the programming language is, will my question end up with a lynch mob?
I'll give high praise to the Lazarus community. Members went out to demonstrate and constructed me alternatives when I was new to Pascal. Meanwhile, the Python community you end up with folk foaming at the mouth.
> 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 w
poetic ! You have nailed it. There are some folks who behave holier-than-thou just because they happen to use some language. Language missionaries if you will, and they are insufferable.
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'm working with malisper on this), we are now focusing on improving many things about postgres! Some we have written about before [0], and we have much more in mind too. Malis wrote another comment about analytical workloads being 300x faster now than postgres for a version we're working on right now
Aiming for postgres compatible database with a 2026 architecture
> Aiming for postgres compatible database with a 2026 architecture
Except you didn't improve the architecture, did you? You just asked an LLM to copy what was already there. Making real improvements to the database architecture requires understanding the database architecture, not just asking a calculator to do the work for you.
Better benchmark performance means nothing if the underlying guarantees break, and a 300x improvement sure makes me suspicious. I would look at something like this if it passes a Jepsen test, otherwise you simply will not be able to convince me that it's worth my time.
The version we have live right now is pre architecture changes, we wanted to make sure we could hit this milestone first. And agree about proving the underlying guarantees. It will be pretty exciting when we do
Why not then doing it as a fork - using existing code and language to re-architect? What value does Rust bring here? You are using LLMs to rewrite, so the language is pretty much irrelevant from developers perspective.
You can say "we want it in Rust" and leave it there - I'd be fine with it. Wouldn't use it though.
There is big appetite for PostgreSQL in business cases. But there's also a lot of problems in PG and people want to solve them. But there's ~10 people in the core of PostgreSQL who contribute to it and know how to change the core. If you have a business use case that would require changing the core, doing it in safer, less error prone technology would be way better. That's why you have other products that had to be created that talk PG protocol, but aren't using official build.
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 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?
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
More that I got confused by the C function returning bool, not as an error value, but as a result, which is my fault for skimming it quickly.
I have taken a closer look at the code, and it seems superficially a somewhat faithful rewrite, not quite idiomatic Rust, but closer than I anticipated at first. I know there are non-LLM rewriting tools for C to Rust, and with a test suite to help, a rewrite to Rust might be greatly helped. The new Rust code does have some drawbacks in some ways, and there are topics I am curious about.
People feel threatened by LLMs doing things well that they feel should require their skills and talent.
That's understandable but it's still a bit of a negative emotion that probably isn't very productive. Or very rational. This thread is full of people trying to argue that this can't be any good, shouldn't be any good, and is clearly going to end in tears. And obviously this thing passing tens of thousands of carefully curated tests that accumulated over decades suggests otherwise. It's hard to argue against that.
This probably is going to have some new issues. But it's an impressive achievement.
I mean you can learn a lot. You can learn what's possible with less effort to build a proof of concept. It's kind of like you had another engineer do it for you, you don't completely learn how to do it yourself but you can still learn a lot with much less effort
You would learn way more by asking an LLM how postgres works. Nobody is even reading this Rust code. There are 7000 commits over 2 weeks. What is being learned from that?
exactly zero knowledge gained. all former expert understanding is buried down in slop so it is inaccessible and will be completely inaccessible once slop-machine stops
You learn that you can build a version of Postgres that passes the tests and improves on these benchmarks in rust. You gain access to a codebase that does it which you can learn a lot from too. Definitely not zero like someone else said
1. Piggybacking established brand names (Postgres + Rust)
2. … without practicality nor advancement (e.g. this solves no extra problems)
3. … without trust (i.e. LLM-driven rewrite, with no capabilities to thoroughly review it)
I think people get easily upset when the title has high-signal names like Postgres, and the title touts it somehow, yet it’s obviously impractical for obvious reasons (short-/long-term practicality, social trust & network effect, etc)
There are new power tools for our craft. People are experimenting and having fun with said power tools, and have interesting results that may be transferrable to $YOUR_PROJECT.
Doing things just because we can is a great reason for hacking around.
Kudos for the author for answering questions and keeping up resilience - HN crowd is not what it used to be (shakes fist at a different cloud).
I'd love to be proven wrong, but chances are that nobody will use this in production, people will completely forget about the project in 6 months, and the project will be archived not long after that.
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.
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.
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.
I wrongly guessed that the boolean in the original C code was for error handling when I skimmed it, but instead it is just a result value, while elog() and related macros/functions are used for general error handling in the C version. I agree that it makes sense in Rust and other languages with tagged unions.
Though often when applicable, a simple tagged union is used instead when that would document the intention better. Like, the Rust version of search_pg_class_full_form::call() returns a Some for cache hit and None for cache miss as far as I can skim, and that group of methods returning that could arguably have returned a basic enum instead with CacheHit(value) and CacheMiss. Though this is a nitpick on my part.
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.
The version in the GitHub repo is ~8x slower than Postgres. I have a new unpublished version that is 50% faster than Postgres on transactional workloads and ~300x faster on analytical workloads.
This seems to be a multi-phased project. First phase (completed) was the re-write in Rust. There doesn't seem to be a performance gain and no significant one should be expected. In a 2nd phase a new architecture is implemented which malisper claims to perform much better.
I wished the two phases would have been tackled in reverse order.
> I wished the two phases would have been tackled in reverse order.
Well, tackling them in reverse order would require the humans behind this to develop an actual understanding of the existing code and architecture before starting the project, instead of just asking claude to do it. So, here we are.
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
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.
The challenge is that more and more people are producing project like this - 1,000s of commits and > 200k lines of code - and saying it was carefully created using agent based workflows and not vibe coded.
Quite amusing we have decades of human written code much of it sub standard and yet no one demanded proof till now of Open Source projects having to ‘demonstrate’ anything.
I get what you’re saying and agree with the last sentence. Just wanted to touch on the “why” part.
In the world of exclusively human written software the existence of the artefact itself (code, documentation) served as the proof that there’s someone with half a brain behind it. Now that’s not the case anymore.
The conclusion stays though - it’s OSS, authors/maintainers have no obligation to anyone to do anything. Like it, use it, don’t like it, don’t use it.
As for me, I’ve found that the community and activity proxies are still good.
It will be interesting to see how the project activity is unfolds? Are people using it in production. How many errors do they find. What do those fixes entail. What happens with the docs over time. Etc.
I haven't had a change to look in depth, but based on a quick glance I'd say that the activity on the project seems like the tempo you'd expect of a similar open source project.
One of the projects Im working on and off is a tamper-proof audit log, based on some PoC code I created almost 10 years go; unit and integration testing are good at preventing defects and regressions, but they will not guarantee your software will work. However, with the power of LLMs, one can easily use model checking (in my case with Quint) and/or other formal proof approaches to ensure the software conforms as specified. The result (in my opinion) is an implementation guided by a single human that is actually more trustworthy than manual human-made software using the traditional approach.
> 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.
I think the focus for projects like this is going to shift to reviewing the testing/fuzzing process instead of reviewing each commit (going much further than what the postgres regression/isolation/crash tests do).
Some of this post reminds me of a story I heard long ago from someone who had worked at a HW/SW company. They’d transferred an engineer from the ASIC design team to the OS kernel team, though he’d never been on a software team before. After a while the manager called him in for the following conversation:
Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get their bug count down too.
Very carefully - and I mean extremely carefully - word it so that it describes what it does, while implying what it should do without confirming that it actually does that.
Also helps if you fix the bug or change the behavior, the docs are still technically correct. I'm only partially kidding, I swear I've seen this a million times in documentation I read.
Funny story but in my experience hardware engineers produce some of the worst software of the industry. Of course there must be some hardware engineers out there who do hood software but generally what they build are disasters.
I bet it's being organized by project rather than product. Conway's law ensures such an org will create code around projects, not products, and that always ends horribly.
Honestly, i do not blame them for that though. The whole eco-system of in C- procedurally bitbang on some registers and read on others, until some circuit that might be there is coerced into doing work - often with faulty prototypes you have to rewire yourself, whos documentation is - non-existant-complete while having deadlines within deadlines. And the project-culture is just "aggregate" a layer, wrap the problem like a pearl in shellacks as the main abstraction.
For large projects like this I think a hierarchical division of labor also helps.
If you first carefully define the overall architecture and thus individual high level components of the system, then you know which of those components are mission critical and which are commodity. Mission critical would be anything ensuring ACID, etc. That way, no matter what you farm out to LLMs, you can keep the majority of limited human focus on the far fewer mission critical components. If tests end up not being robust enough to catch all issues, at least they'll be isolated to commodity code where damage is limited to things like DoS, etc, and not code that could cause data loss.
I also think it's important to first define the _contracts_ on and between each of these components, and derive tests from those contracts. Partly because contracts more succinct and easier to reason about. And partly because Rust provides many tools to enforce contracts at compile time, reducing the need for tests (which themselves could end up subtly flawed). Contracts can be enforced through typing, private vs public APIs, etc. Newtypes are _incredibly_ powerful for both enforcing contracts and making footguns much less likely.
Though beyond testing, I think there will be increasing focus on proofs of correctness. (Testing can only show the presence of bugs, not the absence. —Dijkstra)
I'm not sure how much though. (Only for critical stuff or will it go mainstream?) The economics and the incentives will determine that. (And the cultural inertia! :)
In general (I’m not saying this is the case with this project) if you don’t have their prompt history and you can’t re-run the LLM “compilation” yourself, is it open source? It feels a bit more like those “source available” projects where you can read the code but don’t have access to the build system.
On the other hand, aside from the commit messages, one didn’t ever have access to the underlying thought process of human developers either, so maybe it’s not equivalent to say that secret prompts mean closed-source.
What an incredibly bad take. "It's not open source because we have the source but not the thought process of the developer" - well then no project on this earth is truly open source by your definition.
> The "source code" for a work means the preferred form of the work for making modifications to it.
With that definition, there's definitely space for arguing that the AI tooling for modifying the code is necessary for the modification process to be sane therefore "preferable" for any human, if the code is "designed" (or lack of design thereof) around the idea of being AI-maintained.
Otherwise, it's not source-code, it's not meaningfully-modifiable, it's basically equivalent to just decompiling a binary. (similarly-bad quality may of course be human-produced too, though then at least you have direct proof of it being the preferred form for at least one person - the author)
True, but internal dependencies aren’t upstream. I care very little how a project is laid out on disk before it’s built unless I’m going to work on the source.
You can also depend on a lot of libraries that have potentially high quality rather then writing a lot yourself. The defense against compromised dependency can't be 'Ill write everything myself and do it with the same quality as the ecosystem'.
Disaster. Well, I read stories about Rust and how there isn't much in the stdlib, but this is just too much. How many dependencies are there, on average, in other projects? I guess I am spoiled with Go.
In a typical Rust project you organize your project into many crates. I haven't checked, but I'd guess that the vast majority of those dependencies are internal dependencies. After all, this project started by running an automated C to Rust converter, which the authors claimed produced over a thousand crates.
The lock format is a multi-line TOML, with a varying number of lines per dep due to redundantly listing deps-of-deps, so a naive line count massively overstates the number.
Cargo.lock contains many unused dependencies, because it's a superset of all combinations of all optional/disabled features of all transitive deps across all possible platforms (so that the deps don't reshuffle even if you enable/disable feature flags or compile on another platform). But that means Cargo.lock is going to have 3 async runtimes even if you use one. It's going to have syscall definitions for RedoxOS and wrappers WASM, because some dep of dep is compatible with those platforms. But these deps won't even be downloaded if you don't build for these platforms.
The number you got presented is not representing the unit you're insinuating. A crate in Rust is a compilation unit. It's common for projects to ship as a collection of many crates. It's a smaller unit than what C counts as one dependency, and slightly coarser than an .o file. I don't see people freaking out by how many .o files their projects have, including all transitive ones from deps like openssl or curl.
> 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
I could not care less about any of this. Truth is code, as it is now. I don't care when (and certainly not by who) a bug got introduced, it's here, shut up and fix it.
> But with LLMs generating 7101 commits in less than a month that isn't feasible.
I don't think trying to understand LLM generated code is feasible for anything other than very small projects. IMO it's a big problem with using LLMs for coding. Sure, they can generate a bunch of stuff, but in some ways that just makes the real problems of software development even harder.
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.
In this case it's justified because Rust allows safe implementation of threaded code. Current Postgres is per-process. Switching to threading yields performance improvements.
If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.
There is an expectation that threads are more performant than processes all else being equal. Obviously there is some work involved to make "all else be equal", like maybe threads have less isolation from each other etc but if you can mechanically convert code to use threads where it used to use processes I can see the claim standing up.
Threads generally have less memory overhead and context switching between them is theoretically faster, but as I suspect you know it is situational and not as simple as just s/process/thread/g. There are many tradeoffs, including the loss of memory isolation, and since Postgres is a network application which holds a rather important position in most architectures, proper memory isolation is very important.
Switching to threads doesn't guarantee weaker isolation, just like it doesn't guarantee better performance, but those nuances are why "switching to threading yields performance improvements" is over simplified to the point of uselessness. It simply reeks of the same kind of ignorance that used to drive statements like "rust doesn't have vulnerabilities" and "rewrite it in javascript for web scale performance".
I do agree, but maybe there is a valid mechanical conversion thats applicable in the postgresql codebase? I do get what you're saying but on the other hand, if he's passing tests with his conversion then this is different than some hypothetical, I'm just saying I would believe his claim on this one. I'm not going to port my erp to it yet but the performance win could actually be there.
I'm not interested in a technical conversation with you; I was answering someone else. The top voted comment thread of this page, which dominates discussion, already covers everything you'd want to know.
The author was talking about eliminating memory being copied between processes. That's a performance improvement. I don't know how the 300x improvement was made or whether that's even real - you should really be arguing with the author about that. I didn't seriously put stock into it because you know, they used AI to rewrite it. I doubt their testing methodology is sound.
I appreciate the condescension though. Thanks for teaching stupid old me how a database works.
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 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:
It looks as if it's building structs out of information in (mutable pointers) to other structs without an Rc in sight. Which makes sense for a C parser: you've got a table with data, so you just link to it. It's fast, and when you know you're not going to touch it, it's safe. But this doesn't make the Rust code any better than the C code.
Note that the code I believe you are referring to is from the parser which was generated with c2rust. The Postgres parser is generated from yacc/bison so rather than try to rewrite it idiomatically, I did so mechanically.
This is actually a great point I have not seen articulated. A motivation for clear architecture and good design is being able to evolve the system over time. Does LLM code have that capacity? Are LLMs themselves able to increment iteratively?
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.
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.
A lot of it is actually GPL-washing and rust is the excuse.
I'm on the rewrite it in rust bandwagon, but I secretly want to rewrite things in rust so they can be refactored and made easier to maintain and add features. So "rewrite it in rust" is just like "rewriting it in anything that I'm currently enamored with," and doing it with an LLM (defactoring?) would miss the point for me.
rust being safe(r) just makes the rewrite less risky.
A lot of the software being rewritten in Rust is not GPL to begin with, like PostgreSQL here which has its own BSD/MIT-like license: https://www.postgresql.org/about/licence/
637 comments
[ 4.1 ms ] story [ 201 ms ] threadExcept for when they do, like the new TypeScript...
It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)
LLMs sometimes confidently leave things out or they will overbuild.
I use them all the time but mistakes happen. It's not exactly a scalpel, more like a sledge hammer.
is it the craftsmanship, or the deliberate decision making of industry veterans?
Hours of human attention
or a few seconds of AI attention?
I am not just talking about writing the code but the brainstorming that goes into it.
`mostly` is doing a lot lifting here. The Go rewrite uses plenty of copilot. The reason you trust it is because you trust the people doing the rewrite.
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.
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.
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.
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
Fable's napkin estimate of the effort required to produce a passable reference semantics for Postgres, which would involve novel discoveries in denotational semantics of concurrent transactions and so on, might be in the ballpark of 30–60 years of PhD level work.
So realistically I think the only way to validate a Postgres implementation involves differential testing, fuzzing, acceptance test suites, etc. And still you'll have bugs that need to be hammered out the good old fashioned way.
There are reasonable arguments against language ports, but this is not one. You're making an argument against code changing at all ever.
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.
You don't write a test (just) to verify that your change fixed the issue, but to ensure it doesn't regress in the future after an unrelated refactor.
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.
1. Every test that is written is another use case that wasn't tested before. 100% test coverage is often impractical, but the more tests you have the more of the code you can be confident about.
2. Every test you add is another regression that can't happen in the future; if you test the index rebuilding code and validate the output then you know that you aren't going to make a change that breaks the index rebuilding code. If you have a legitimate change you update the tests, but if you're not expecting the change then you know there's a bug somewhere.
https://sqlite.org/testing.html
> 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?
https://github.com/tsz-org/tsz/
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.
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.
There's another way to validate the rewrite though. Just run both pgrust and postgres and compare the output. Know of an edge case? Run it too. Doesn't know? Use a fuzzer or some automated tool to find interesting inputs. Found an inconsistency? The input/output pair becomes a test case now
Not sure if there's tooling for that though. If there is, just give it to Claude so they will incorporate it in their development loop
I can recommend proptest. What you're describing is a common pattern in property-based testing which basically boils down to "comparing against an oracle". In this case, postgres would be the oracle, pgrust is the system under test, and the idea is to generate strategies comprised of sequences of valid (and invalid) SQL statements and ensure the system under test behaves the same as the oracle in every case.
The space of inputs and outputs is infinite. You can't prove programs are the same by "just" testing a bunch inputs.
Neither postgres nor pgrust have their behavior specified using formal methods. (pgrust could write some contracts using something like kani or creusot, but having upstream postgres also write contracts is a tougher sell). If they had, one could write a giant proof that said the two software essentially do the same thing (at least in a subset of environments and some simplifying assumptions)
If a Rust rewrite of any of your software becomes available and you aren't installing it immediately and without reservation, then you are simply not giving security the priority it both demands and deserves, and that makes you disastrously insecure. This is a serious issue that should be given all priority. There is no room for debate. Your only policies should be security before all else and compliance with those policies must be absolute and without deviation, or all is lost.
This is silly.
Rust is awesome, and it's hard to argue against in many domains. However, software is more than the language it is written in or the runtime serving it. Is the Rust rewrite fully compatible? Is it supported by a strong community? Is it likely to continue to be supported? Is its release cadence sensible? Is its licence compatible with your intended usage?
There are many questions needing to be answered before making rash decisions based purely on tech.
Security is always about tradeoffs.
Con: The database no longer exists.
Also, there is more to security than memory errors. SQL injection, authentication, and access rules matter. It doesn’t matter if Rust database is secure to bad data if it lets anyone in to do anything. Or if it is crashing all the time or corrupting your data.
I think it is completely reasonable to use a preexisting unmodified test suite to state that something is working. The larger the project the more true this becomes. Real world production scars are documented and guarded against in the test suite otherwise those lessons get lost.
Also SQLite is legendary for its massive test suite and extensive fuzzing. They have 590x the amount of test code and scripts than normal code. Source: https://sqlite.org/testing.html
I was trying to call out that SQLite often credits their massive test suite for their stability but likely didn’t communicate that well.
"Mom, can I have battle-tested, reliable software"
"We have battle-tested, reliable software at home"
Battle-tested, reliable software at home: (Pic of green text from `cargo test`)
So, we should make it easier to feed that reliability back upstream.
Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!
If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.
Copyleft and the whole software licensing ecosystem only matter when producing that software actually requires serious human effort and dedication.
Fixed that for you. Code generated by an LLM is not copyrightable (because copyright only protects human effort), so the codebase is automatically public domain and cannot be licensed at all.
They could theoretically copyright the prompts that they used, but as that's not part of the output, and the output doesn't deterministically arise from those prompts, they'd struggle to use that to back a copyright claim.
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 or SQL-ite or SQL-lite or SQ-lite.
AFAIK there is no official word on how the name is intended to be read or said.
> (Hipp) How do I pronounce the name of the product? I say S-Q-L-ite, like a mineral.
> But I also hear a lot people say, "Sequel lite and SQL lite." You know, I don't care. Whatever comes off of your tongue easily is fine with me.
> (Q) But the official correct way is S-Q-L-ite?
> (Hipp) Yes, like a mineral.
https://www.listennotes.com/podcasts/the-changelog/why-sqlit...
So, he means SQL-ite, but doesn't want to proscribe this as the only way people should say it. I like all of that.
Maybe we should follow his example.
In fact from a porting effort this is the first blog post I would expect. Not that the hey we successfully did it.
They will ask relevant Claude skill.md
Is it cheaper to find them at compile time rather than runtime? Yes.
But it’s not an unsolved problem. Memory bugs are a known unknown.
Which project are you referring to? Yes not every open source project uses memory tools.
DST systems such as Antithesis can definitely help.
This thread is enumerating all the same talking points of both sides.
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.
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.
I will note that, very funny
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.
We have a problem with software religious fundamentalists in our organisation and it's an apt description.
We went down the earlier Udi Dahan and DDD crap.
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!
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 existing system works. Yes, it costs a lot to maintain, and you could definitely reduce that if you moved to a more modern system. So now you're talking payback periods. Cost of development / maintenance cost savings per year = number of years before you pay back the project.
Problem is, that the cost of the development is often unclear, and the maintenance cost savings, while definitely above zero, and often unclear, and approximated the numbers usually come to a payback period in decades.
And that's without the usual tech caveats; We can't promise there won't be bugs. We can't promise deadlines will be met. We can't promise the project will succeed at all. We can't promise existing functionality will be faithfully reproduced in the new system. The normal risks around any software dev project.
All in all, it looks really expensive and really risky compared to just doing nothing and running the same old system for another five years.
Source: I helped do some of the maths on this for a Y2K project.
Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
Why not?
I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences.
The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them!
So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output?
At the end of the day, humans are not without fault either.
I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception.
As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans.
[1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.
I feel like AI has dramatically changed how complete rewrites can be considered, especially for long-lived, legacy projects.
What do you even mean by "works", specifically?
> it might have bugs, you know what they are.
Okay, so it doesn't work, you know it doesn't work, it's just that you accept the specific ways in which it doesn't work.
I've lost track of all the myriad stupid ways in which these ancient systems are hugely ineffectual without even being outright faulty.
Like airline tickets where your name is printed as "LASTFIRSTMR" in all caps and no spaces because their systems are ancient beyond belief.
Similarly, my bank statements are security-critical, because anyone with a copy of my credit card details can pull money out of my account without my express authorization. But...
... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!
I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.
If you look at it from the perspective of someone used to modern web security, then you realise that banking is a raging tyre in comparison. Banks literally just accept a certain rate of criminal activity and "price that in", reversing transactions when asked -- which itself can also be a criminal activity. They just shrug their shoulders.
"What can we do about this?" -- says the people that have tried nothing and are all out of ideas.
Rewrite it. The whole thing.
Use an actual database, something made in the last three decades instead of half a century ago.
Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.
Etc.
I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.
It runs and accepts people's payments, which means you're not on the front page of the newspaper (not in a good way).
> ... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!
They also have to go through payment networks which are very often the limits on those things. So yeah, it sucks, but just fixing one DB isn't enough - the whole thing has to get upgraded.
> I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.
There is a little bit, but not much. Again, if these transfers are happening via card, it's all a terrible old fixed-length setup. Would be great if it was better, but you need Visa and Mastercard to upgrade as well. And of course there _is_ verification - most banks don't do a great job of surfacing this but they know if they've verified a PIN or CVC, or if it was contactless (in which case it _is_ unverified, but society realised we prefer the convenience there).
> Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.
Obvious question then: You've made a card transaction. It is signed with the other party's private key. What does that buy you? How do you attach trust to this key? Whose is it - the payment gateway or the merchant?
> I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.
Sure, and if the LLM can rewrite enough of this system to get what you want, there's heaps of room for improvement. But this is orders of magnitude bigger in scope than rewriting your one old bit of COBOL software, it's systematic.
"It works if nobody attacks it." isn't security.
> They also have to go through payment networks which are very often the limits on those things.
For the same reasons.
> need Visa and Mastercard to upgrade as well.
They won't, and it's not worth asking them to. They're dinosaurs and will simply be replaced by a newer, more agile competitor.
It's already happening! Billions of people in Asia pay with their phones using home-grown payment systems, most of which are generally much more modern and better engineered.
> It is signed with the other party's private key. What does that buy you?
Same as what HTTPS does: attestation of identity by some trusted third-party, to some non-zero level. This could be literally just the existing CA networks and DNS domains as identity, but it could be governments, the banks themselves, etc.
I had some fraudulent transactions on my account labelled "Microsoft Subscription". It wasn't Microsoft. How can I tell?
Not even the bank knew the identity of the third party!
That's insane.
If only we had a way to solve these issues with tools capable of running Rust programs in that way. I guess every company that needs distribution / failover has a mainframe sitting in their office nowadays huh?
https://k3s.io/
https://kubernetes.io/
https://aws.amazon.com/
https://www.erlang.org/
etc.
You could run one of these things on a mainframe, because it's a zero-downtime machine - you can swap out parts of them as they run. But fundamentally it's a singleton. It is deeply naive to believe you can trivially translate that to something running on Kubernetes just "because Rust".
Of course most companies that need distribution do manage to do that, and eventually the banks will get there too. But it isn't feasible to do that by translating their existing non-distributed COBOL code, they need a fundamental re-architecture, and that is much harder.
Sure you could keep vibe coding it but I wouldn't bet my data on that. A database needs to be rock solid.
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?
People see the safety as a moral superiority so it attracts obnoxious zealots.
Other languages' features and syntax aren't nearly so easy for zealots to form behind. The perception of absolute safety it puts in some people makes them crazy.
People were told for years they can't use Rust for their new projects because it hasn't been "proven" in industry yet. So the option was to sit back and wait (chicken and egg) or move to rewrite a bunch of projects so that it could actually be "proven". Not saying this is the only reason why it happens (every language has its Zealots) but it certainly makes more sense.
Due to the explosion of new programming languages over the past few decades your options are to either aggressively expand wherever possible or die out because you're not "proven".
If it _is_ 50% faster, then that's the reason
Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?
If you are watching this and haven't used rust: Please don't judge the language by this part of its users.
One stinks the other even if it's the shiniest plate in the cake shop. My first thought to starting a project in the programming language is, will my question end up with a lynch mob?
I'll give high praise to the Lazarus community. Members went out to demonstrate and constructed me alternatives when I was new to Pascal. Meanwhile, the Python community you end up with folk foaming at the mouth.
poetic ! You have nailed it. There are some folks who behave holier-than-thou just because they happen to use some language. Language missionaries if you will, and they are insufferable.
I'd like to know if the "authors" know what I'm talking about.
We really should have used postgres instead, but it was the "big data" period so you had to use mongodb.
Aiming for postgres compatible database with a 2026 architecture
[0] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
Except you didn't improve the architecture, did you? You just asked an LLM to copy what was already there. Making real improvements to the database architecture requires understanding the database architecture, not just asking a calculator to do the work for you.
Better benchmark performance means nothing if the underlying guarantees break, and a 300x improvement sure makes me suspicious. I would look at something like this if it passes a Jepsen test, otherwise you simply will not be able to convince me that it's worth my time.
You can say "we want it in Rust" and leave it there - I'd be fine with it. Wouldn't use it though.
Why does there need to be a business case? They aren't selling it.
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?
LLM companies steal the original work and LLM users dont even know where the replicated code was lifted from or how it was licensed.
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
I have taken a closer look at the code, and it seems superficially a somewhat faithful rewrite, not quite idiomatic Rust, but closer than I anticipated at first. I know there are non-LLM rewriting tools for C to Rust, and with a test suite to help, a rewrite to Rust might be greatly helped. The new Rust code does have some drawbacks in some ways, and there are topics I am curious about.
https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...
That's understandable but it's still a bit of a negative emotion that probably isn't very productive. Or very rational. This thread is full of people trying to argue that this can't be any good, shouldn't be any good, and is clearly going to end in tears. And obviously this thing passing tens of thousands of carefully curated tests that accumulated over decades suggests otherwise. It's hard to argue against that.
This probably is going to have some new issues. But it's an impressive achievement.
The only one using feelings rather than reason here is you.
1. Piggybacking established brand names (Postgres + Rust)
2. … without practicality nor advancement (e.g. this solves no extra problems)
3. … without trust (i.e. LLM-driven rewrite, with no capabilities to thoroughly review it)
I think people get easily upset when the title has high-signal names like Postgres, and the title touts it somehow, yet it’s obviously impractical for obvious reasons (short-/long-term practicality, social trust & network effect, etc)
But then its credibility would be abysmally low, which makes it undesirable for the authors.
There are new power tools for our craft. People are experimenting and having fun with said power tools, and have interesting results that may be transferrable to $YOUR_PROJECT.
Doing things just because we can is a great reason for hacking around.
Kudos for the author for answering questions and keeping up resilience - HN crowd is not what it used to be (shakes fist at a different cloud).
I'd love to be proven wrong, but chances are that nobody will use this in production, people will completely forget about the project in 6 months, and the project will be archived not long after that.
This is not the first one of similar projects.
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.
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.
Though often when applicable, a simple tagged union is used instead when that would document the intention better. Like, the Rust version of search_pg_class_full_form::call() returns a Some for cache hit and None for cache miss as far as I can skim, and that group of methods returning that could arguably have returned a basic enum instead with CacheHit(value) and CacheMiss. Though this is a nitpick on my part.
I wonder how many "unsafe" blocks are in there...
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?
https://knowyourmeme.com/memes/i-dont-want-to-play-with-you-...
I wished the two phases would have been tackled in reverse order.
Well, tackling them in reverse order would require the humans behind this to develop an actual understanding of the existing code and architecture before starting the project, instead of just asking claude to do it. So, here we are.
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-...
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.
If you find some, fix them.
Went straight into my vault of brilliant quotes!
If ya don’t wanna use it, don’t. Simple.
In the world of exclusively human written software the existence of the artefact itself (code, documentation) served as the proof that there’s someone with half a brain behind it. Now that’s not the case anymore.
The conclusion stays though - it’s OSS, authors/maintainers have no obligation to anyone to do anything. Like it, use it, don’t like it, don’t use it.
As for me, I’ve found that the community and activity proxies are still good.
Definitely still something to look into. A project I'm checking in on from time to time is https://github.com/emdash-cms/emdash/.
It will be interesting to see how the project activity is unfolds? Are people using it in production. How many errors do they find. What do those fixes entail. What happens with the docs over time. Etc.
I haven't had a change to look in depth, but based on a quick glance I'd say that the activity on the project seems like the tempo you'd expect of a similar open source project.
Why is that a challenge? As long as they are open about this, all is OK.
It was also never meant to hit production.
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...
Maybe I'm just being a little grumpy. If I really need to look into a repository, I clone it and use vanilla git command line tools to have a look.
It's just annoying that the modern web UI from GitHub takes >1s second to load a page with 34 commits
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.
You can use the syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 (-1 for the latest and -1 for the last)
ex : https://github.com/malisper/pgrust/commits/?after=3646a73515...
I think the focus for projects like this is going to shift to reviewing the testing/fuzzing process instead of reviewing each commit (going much further than what the postgres regression/isolation/crash tests do).
related post from danluu: https://danluu.com/ai-coding/
Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get their bug count down too.
Engineer: We’re allowed to have bugs?
Hardware Engineers: "None. We'll fix it in firmware."
Firmware Engineers: "None. We'll fix it in software."
Software Engineers: "None. We'll document it in the manual."
Technical Writers: "None. The user can figure it out." etc.
Me: This is what you said it does, and this is what it actually seems to do. Which one is right?
Engineer: Shit.
Also helps if you fix the bug or change the behavior, the docs are still technically correct. I'm only partially kidding, I swear I've seen this a million times in documentation I read.
Sadly, monospaced fonts kill sarcasm.
If you first carefully define the overall architecture and thus individual high level components of the system, then you know which of those components are mission critical and which are commodity. Mission critical would be anything ensuring ACID, etc. That way, no matter what you farm out to LLMs, you can keep the majority of limited human focus on the far fewer mission critical components. If tests end up not being robust enough to catch all issues, at least they'll be isolated to commodity code where damage is limited to things like DoS, etc, and not code that could cause data loss.
I also think it's important to first define the _contracts_ on and between each of these components, and derive tests from those contracts. Partly because contracts more succinct and easier to reason about. And partly because Rust provides many tools to enforce contracts at compile time, reducing the need for tests (which themselves could end up subtly flawed). Contracts can be enforced through typing, private vs public APIs, etc. Newtypes are _incredibly_ powerful for both enforcing contracts and making footguns much less likely.
I've got insanely good at testing oracles over the last year for exactly this reason.
https://news.ycombinator.com/item?id=48856535
Though beyond testing, I think there will be increasing focus on proofs of correctness. (Testing can only show the presence of bugs, not the absence. —Dijkstra)
I'm not sure how much though. (Only for critical stuff or will it go mainstream?) The economics and the incentives will determine that. (And the cultural inertia! :)
I usually check the history of a file not easily changed like .gitignore.
The first commit seems to be this one
https://github.com/malisper/pgrust/commit/22113dc36b02973060...
On the other hand, aside from the commit messages, one didn’t ever have access to the underlying thought process of human developers either, so maybe it’s not equivalent to say that secret prompts mean closed-source.
> The "source code" for a work means the preferred form of the work for making modifications to it.
With that definition, there's definitely space for arguing that the AI tooling for modifying the code is necessary for the modification process to be sane therefore "preferable" for any human, if the code is "designed" (or lack of design thereof) around the idea of being AI-maintained.
Otherwise, it's not source-code, it's not meaningfully-modifiable, it's basically equivalent to just decompiling a binary. (similarly-bad quality may of course be human-produced too, though then at least you have direct proof of it being the preferred form for at least one person - the author)
Then I lost count, so I ran wc -l Cargo.lock
Easily over a thousand dependencies. And "rewritten in Rust" is supposed to be a good thing? I bet this doesn't even compile faster than the original.The lock format is a multi-line TOML, with a varying number of lines per dep due to redundantly listing deps-of-deps, so a naive line count massively overstates the number.
Cargo.lock contains many unused dependencies, because it's a superset of all combinations of all optional/disabled features of all transitive deps across all possible platforms (so that the deps don't reshuffle even if you enable/disable feature flags or compile on another platform). But that means Cargo.lock is going to have 3 async runtimes even if you use one. It's going to have syscall definitions for RedoxOS and wrappers WASM, because some dep of dep is compatible with those platforms. But these deps won't even be downloaded if you don't build for these platforms.
The number you got presented is not representing the unit you're insinuating. A crate in Rust is a compilation unit. It's common for projects to ship as a collection of many crates. It's a smaller unit than what C counts as one dependency, and slightly coarser than an .o file. I don't see people freaking out by how many .o files their projects have, including all transitive ones from deps like openssl or curl.
I could not care less about any of this. Truth is code, as it is now. I don't care when (and certainly not by who) a bug got introduced, it's here, shut up and fix it.
don't be obtuse. Nobody needs to do either.
> But with LLMs generating 7101 commits in less than a month that isn't feasible.
I don't think trying to understand LLM generated code is feasible for anything other than very small projects. IMO it's a big problem with using LLMs for coding. Sure, they can generate a bunch of stuff, but in some ways that just makes the real problems of software development even harder.
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.
Please describe in detail what you believe this means and the mechanism by which switching from processes to threads improves performance.
Switching to threads doesn't guarantee weaker isolation, just like it doesn't guarantee better performance, but those nuances are why "switching to threading yields performance improvements" is over simplified to the point of uselessness. It simply reeks of the same kind of ignorance that used to drive statements like "rust doesn't have vulnerabilities" and "rewrite it in javascript for web scale performance".
I appreciate the condescension though. Thanks for teaching stupid old me how a database works.
You're welcome, someone had to.
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
The parser was generated by c2rust. The Postgres parser is generated from yacc/bison itself so I didn't bother making it idiomatic.
Rewriten in Rust is becoming a meme now.
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.
I'm on the rewrite it in rust bandwagon, but I secretly want to rewrite things in rust so they can be refactored and made easier to maintain and add features. So "rewrite it in rust" is just like "rewriting it in anything that I'm currently enamored with," and doing it with an LLM (defactoring?) would miss the point for me.
rust being safe(r) just makes the rewrite less risky.