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

832 728 14 days ago

juliangmp• 14 days ago

I feel like we need to heavily differentiate between a rewrite and an AI rewrite.

mrklol2• 14 days ago

I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!

colordrops5• 14 days ago

Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?

AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.

queoahfh6• 14 days ago

Didn't the initial rewrite of Bun into Rust have an ocean of "unsafe" in it, and wasn't it entirely dysfunctional?

dwedge3• 14 days ago

Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previously great devs are throwing in PRs that touch hundreds of files at once with one commit.

A lot of people I previously considered great developers have become people I would not recommend for a job in the past 2-3 years.

If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary.

Sure, but this is just begging the question. If nobody could tell, the term 'slop' wouldn't have become so popular.

lenkite• 14 days ago

Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Aren't you making a strawman argument ? AFAIK this project is not made by an official PostgreSQL core developer, so the entire premise of your argument is invalid.

mebcitto3• 14 days ago

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

Dormeno• 14 days ago

When the majority of the code is written by AI, it is more than 50%.

guenthert5• 14 days ago

Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.

Who wants to contribute to an unmaintainable code base?

lowsong• 13 days ago

I think close to 100% of new ambitious projects are going to leverage AI at least to some degree.

Once the free money dries up that number will rapidly tend towards 0%.

So how much AI usage does it make it an “AI rewrite”?

Any amount.

baq• 14 days ago

It’s just a build step now.

satvikpendem4• 14 days ago

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.

Zecc• 14 days ago

You underestimate what people are willing to do just for fun.

queenkjuul4• 13 days ago

No human would want to rewrite one technology to another

Except for when they do, like the new TypeScript...

bozdemir3• 14 days ago

I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.

raincole• 14 days ago

Or, you know, you can use Postgres. It's right there for you.

OtomotO4• 14 days ago

AI is an average coder.

It was trained on all code the code that could be found.

Not just code written by genius programmers like Carmack and Bellard.

Given that it's average, I'd prefer a human coder above average :)

jatins• 14 days ago

rewrites feel like an area where LLMs are better suited than humans imo

It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)

silon422• 14 days ago

It's not that... It's a rewrite by project maintainers vs a fork.

maxloh3• 14 days ago

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.

rjh297• 13 days ago

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.

subygan• 13 days ago

What about human written software makes it more reliable than LLM written software?

is it the craftsmanship, or the deliberate decision making of industry veterans?

rirze• 13 days ago

mostly by humans

`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.

dboreham• 13 days ago

Many projects that were done by humans and took a year can certainly not be trusted.

egorfine9• 14 days ago

We already have a well established term for AI rewrites.

byzantinegene3• 14 days ago

A human rewrite without maintenance is just a hobby project. An AI rewrite is just wasting tokens for god knows what?

langs• 13 days ago

nope. any rewrite will be an AI rewrite soon.

gingersnap• 14 days ago

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.

kstrauser• 14 days ago

In a project like PostgreSQL, those scars are reflected in unit tests demonstrating that they’re fixed. It’d be hard to pass its test suite and not be as robust as the original.

dwedge3• 14 days ago

Sure but these scars/tests are from the original implementation. Just because it doesn't have issues there doesn't mean it didn't bring its own set of issues

kelnos2• 14 days ago

Passing a regression test suite only proves that those particular regressions aren't present. It proves nothing about robustness beyond that.

ShinTakuya• 14 days ago

This is all well and good in theory, but the number of times I've seen tests that don't actually test what they say they're testing is hard to count. Yes even when you encourage the developers to ensure the test fails first and do TDD. Tests help you ship with confidence but there's usually at least a few that are just passing by pure luck.

So no, I wouldn't judge a rewrite as being equal just because it passes the tests. That said, I don't think that means you shouldn't do it. You just have to be pragmatic about it.

simiones• 14 days ago

It’d be hard to pass its test suite and not be as robust as the original.

This is not true, even in principle, even for Postgres itself. You'd be right to say that it'd be hard to pass the test suite and not be robust at all to some extent. But even in Postgres, I bet that you can quite easily introduce a change that will pass the whole test suite but reduce robustness compared to the latest release (for a somewhat silly example, add a call to `exit()` on a timer that's longer than the longest duration test in the suite - that will significantly reduce robustness while still passing the entire test suite).

guenthert5• 14 days ago

They ought to, but are they? In https://wiki.postgresql.org/wiki/Developer_FAQ I don't see a requirement to provide a regression test for a bug fix.

oblio2• 14 days ago

Edsger W. Dijkstra:

"Program testing can be used to show the presence of bugs, but never to show their absence!"

tpetry• 14 days ago

You immply that a testcase exists for every weird edge case. Especially filesystem and concurrency is things you can barely build test cases for.

Even a 100% test coversge is far away from verifying all behaviour.

kjs3• 13 days ago

I dunno...I can envision something vibecoded prioritizing passing test suites producing something that does that, but isn't even functional in real-world production. Sort of like in the pre-AI world, where someone claims 'standards compliance' by way of passing compliance test suites, but can't actually interoperate well with other implementations of the standard. YMMV.

surajrmal• 13 days ago

Unit tests aren't useful for rewrites, only integration tests are. So there may be missing coverage. Also many things are simply difficult to test (eg performance under very specific conditions)

mrklol2• 14 days ago

And also the amount of people running it in thousands of scenarios. Not sure if these areas can be even tested for, but I guess time will tell (can observe Bun if it breaks somewhere as that’s afaik the first big AI rewrite which got into prod for masses).

joshka3• 14 days ago

A lot of the signal (github, forums, mailing lists, discord, etc.) can be turned into signal. Right now it's easy enough to collect. In future it will be easy enough to cluster and generate preferences, experience, etc.

Every bug report, code change as a result, PR / commit message, PR comment that steers preferences, etc. is solid signal to generate future tests.

sshine• 14 days ago

not mostly the test, but the real world production scars

Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.

SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some guarantee of equivalent diligence.)

And yes, years and years of running.

hvb2• 14 days ago

The maintainers that wrote those tests will have experience you won't get out of a rewrite.

I think this is also where the real work is. A rewrite is one thing, that you can show off with a flashy blogpost. The maintenance, for years to come, won't be of that nature yet it still requires as much work.

rustyhancock• 14 days ago

One issue is those are the bugs you get when you write it in C++.

They aren't the bugs you get when you write it in Rust.

The kind of bugs you get are usually a function of the problem, language, implementation approach.

kelnos2• 14 days ago

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.

nicce• 14 days ago

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.

martin-adams• 14 days ago

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.

_s_a_m_• 14 days ago

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, ..

byzantinegene3• 14 days ago

a code written to pass a test can surface unintended new bugs.

lukasco2• 14 days ago

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).

danudey2• 13 days ago

sqlite is the pathological case though; it has ~590 times more SLOC in the test suite than in the actual sqlite project.

https://sqlite.org/testing.html

rsoto2• 13 days ago

having a large test suite does not equal to testing every potential edge scenario that has never broken before in production.

rowanG077• 14 days ago

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.

hk__2• 14 days ago

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.

throwaway132448• 14 days ago

Wait - does the AI rewrite the tests too? If so, lol.

thunderbong• 14 days ago

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?

zsoltkacsandi• 14 days ago

Completely agree with this.

The biggest lie of software engineering is that everything can be testable with tests. That a 100% test coverage is an indicator of quality software.

Lomlioto• 14 days ago

I hope you are not true at all.

Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.

I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.

What is this even for logic?

I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.

And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.

xlii• 14 days ago

As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.

The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.

And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.

Now the new, test-based implementation, has to prove it can handle remaining 99%.

nextaccountic4• 14 days ago

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

booksock6• 13 days ago

(I'm working with malisper on this) we built this too and are using it for a new version we're working on right now

271832• 13 days ago

Not sure if there's tooling for that though.

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.

mahogany3• 13 days ago

Just run both pgrust and postgres and compare the output.

The space of inputs and outputs is infinite. You can't prove programs are the same by "just" testing a bunch inputs.

Suzuran2• 13 days ago

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.

bbg2401• 13 days ago

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.

queenkjuul4• 13 days ago

What if the rust rewrite uses "unsafe" on every line?

ianburrell• 13 days ago

Pro: Database is perfectly secure.

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.

dapperdrake2• 13 days ago

"Everybody has a production system. The lucky ones also have a test system."

alemanek2• 13 days ago

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

LtWorf6• 13 days ago

But they aren't all open, so your llm rewrite/copyright eraser won't be taking advantage of them all.

the__alchemist2• 13 days ago

Great point. Stated another way:

"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`)

edelbitter• 13 days ago

That's where the reliability comes from

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.

tormeh2• 14 days ago

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.

Ameo• 14 days ago

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.

ncruces• 14 days ago

Also can the code even be copyrighted?

For my machine translation of SQLite to Go I added this to the README as to licencing:

Most of the code here is machine translated using wasm2go. As such, the original authors retain copyright and the original licenses remain in effect. Everything else is licensed under MIT-0.

The translator (wasm2go) has a licence chosen by, and a copyright notice from, me. Makes no sense for the translated code.

marcus_holmes2• 14 days ago

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.

satvikpendem4• 14 days ago

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.

dxdm2• 14 days ago

How do you know it's not SQL-lite with the single L serving a double role?

Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.

AFAIK there is no official word on how the name is intended to be read or said.

richie_adler• 13 days ago

Richard Hipp says he doesn't care how anybody pronunces it. That said, he pronounces it "S-Q-L-ite".

satvikpendem4• 13 days ago

Because the creator himself said it's an -ite suffix similar to minerals like bauxite, not -lite.

mebcitto3• 14 days ago

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

ZiiS2• 14 days ago

They would need rewriting (a few are included)

malisper22• 14 days ago

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.

mebcitto3• 14 days ago

Perhaps pure pgrx extensions would make sense as a first target?

jeltz10• 13 days ago

They would need to be rewritten as there is no formal extension API. Extensions can call into almost any part of PostgreSQL.

theplumber• 14 days ago

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.

ZiiS2• 14 days ago

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...

whatever1• 14 days ago

You are exactly right. There is no freaking way there was no unsafe behavior in a code case of the size of Postgres.

In fact from a porting effort this is the first blog post I would expect. Not that the hey we successfully did it.

derdi2• 14 days ago

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.

pknerd3• 13 days ago

What would be interesting is if they found a memory unsafe bug

They will ask relevant Claude skill.md

groundzeros20155• 13 days ago

C programmer have learned how to deal with memory problems and have whole suites of tools for finding them.

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.

addedGone2• 12 days ago

except that lately we've had a ton of CVE related to memory, so in practice it's not exactly right.

ronfriedhaber• 14 days ago

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

DST systems such as Antithesis can definitely help.

empiricus• 14 days ago

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

raverbashing• 14 days ago

Also, are they calling it Postgrust?

reddit_clone• 13 days ago

That made me laugh.

This thread is enumerating all the same talking points of both sides.

flanked-evergl• 14 days ago

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.

ottavio4• 14 days ago

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.

alex_duf• 14 days ago

I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs.

You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.

oblio2• 14 days ago

The cost of surface level rewrites has crashed. Which will probably cover 80% of cases. Caveat emptor on which side your project falls.

dixtel• 14 days ago

software talibans

I will note that, very funny

ottavio4• 14 days ago

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.

m00dy• 14 days ago

what does it mean ?

cryo322• 14 days ago

Yeah I'm using that one.

We have a problem with software religious fundamentalists in our organisation and it's an apt description.

arka2147483647• 14 days ago

Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything.

Cue some story here on a bank or airline somewhere still relying on cobol backend servers.

These LLM conversions really seem to make modernization of large parts software layers possible!

geraneum• 14 days ago

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.

rixed• 14 days ago

the biggest blocker on moving to a new programming language, is the cost of re-writing everything

In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?

CamouflagedKiwi4• 14 days ago

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.

BadBadJellyBean2• 14 days ago

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.

bjt• 13 days ago

OK but, Postgres is not one of those clunky "we have to replace this" systems.

win311fwg6• 13 days ago

At the same time that was ever the only reason for moving to a new programming language: abandoning all the bad ideas and craft that had accumulated in the previous language ecosystem. Needing to rewrite everything meant starting from a clean slate, allowing the new systems to be designed for the new age, making everything in that new language feel sleek and modern and thus appealing. Of course, as time progresses even the new language starts to accumulate bad ideas and cruft, historically necessitating yet another language to offer the clean slate again.

If the code is going to be translated forward instead of abandoned and then rewritten, as is now completely viable via LLM, there is no reason to move to a new language at all.

egorfine9• 14 days ago

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?

jackphilson2• 14 days ago

It's pretty ergonomic to agents. Like typescript.

colechristensen• 14 days ago

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.

zeratax2• 14 days ago

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...

shawabawa3• 14 days ago

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?

LtWorf6• 13 days ago

It probably is 50% faster, probably by skipping flushing data to disk.

0dayz• 14 days ago

How exactly are rewriting something the equivalent of being the taliban?

skywhopper• 14 days ago

Because they are blowing up old monuments as part of an attempt to enforce a hardline but nonsensical purity on other people.

the__alchemist2• 13 days ago

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.

bwfan1232• 12 days ago

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.

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.

voidUpdate• 14 days ago

I wonder how long this will be maintained for...

musicmatze2• 14 days ago

As long as tokens are cheap

pknerd3• 14 days ago

I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?

musicmatze2• 14 days ago

I think a business case for a "look I let an LLM rewrite a large codebase" does not exist.

silon422• 14 days ago

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.

fragmede3• 14 days ago

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.

pknerd3• 14 days ago

Well, I will give 7/10 as an FYP

LtWorf6• 13 days ago

Rust doesn't have ACID and I'm sure this doesn't either.

I'd like to know if the "authors" know what I'm talking about.

egorfine9• 14 days ago

It's pure virtue signaling.

wartywhoa233• 14 days ago

"Look mum, no brains!"

wartywhoa233• 14 days ago

Software raidership?

booksock6• 13 days ago

(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

[0] https://malisper.me/the-four-horsemen-behind-thousands-of-po...

solid_fuel8• 13 days ago

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.

rozhok• 13 days ago

Wondering if its possible to backport performance improvements into upstream. Should be a big deal.

dstanko• 12 days ago

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.

signatoremo• 13 days ago

Why not? The author have their own reasons to do it. Did they ask you to use it instead of the official build? It's a github repo.

Why does there need to be a business case? They aren't selling it.

wkoszek9• 12 days ago

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.

josefrichter2• 14 days ago

Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?

piker2• 14 days ago

Because it’s uncomfortable to see decades of work copied so trivially.

nasretdinov• 14 days ago

I can trivially copy any code even without an LLM though with a simple tool called rsync!

antihero2• 14 days ago

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?

alirezaxdehghan• 14 days ago

Imagine the feelings of a dude who used to code in assembly and then some punk writes in c++ and uses gcc... decades of work wasted.

groundzeros20155• 13 days ago

They have the source right in front of them.

bakugo2• 14 days ago

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?

manquer2• 13 days ago

How much token this would burn is of interest I suppose

queoahfh6• 14 days ago

I am concerned about the quality. Even a cursory skim of the code makes the code appear asinine. Unless the genius aspects of the code elude me.

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

mechazawa• 14 days ago

Yeah same. The structure makes no real sense and when digging into the code it reads like I'm the first human to look at it.

mataamad• 14 days ago

This is a (slightly more typesafe) transliteration of the C code.

https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...

jillesvangurp2• 14 days ago

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.

LtWorf6• 13 days ago

Irrational fear… that's why we all collectively ditched gcc and moved to that llm rewrite made in rust right?

The only one using feelings rather than reason here is you.

hexo4• 13 days ago

I can't see the achievement here.

byzantinegene3• 14 days ago

can you enlighten me, what exactly do you learn from asking a llm to do a rewrite?

josefrichter2• 13 days ago

No, I can’t. The way you frame your question tells me you’re not seeking enlightenment.

subarctic3• 13 days ago

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

hexo4• 13 days ago

well, it accelerates icebergs meltdown. so it helps...

esjeon• 13 days ago

Possibly:

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)

kvuj• 12 days ago

Yeah, if the title was : Vibe coded SQL engine written in rust, I don't think much anger would be found in the comments.

But then its credibility would be abysmally low, which makes it undesirable for the authors.

nodoodles• 13 days ago

Agreed, the negativity here is quite wild.

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).

fg1377• 13 days ago

Because it's a waste of token.

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.

queoahfh6• 14 days ago

What a peculiar kind of rewrite.

Rust:

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

Original:

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

Usage:

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

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

pdevr• 14 days ago

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.

queoahfh6• 14 days ago

Yes, but the original boolean seems to have been used for error handling, and the tagged union is also used for error handling. Why have both simultaneously in the same function instead of just one of the two?

Edit: Looking at the code again, perhaps I was mistaken, since the boolean might not have been for error handling, just the result of the function, and C's limitations regarding error handling led it to using something like elog(), apparently a macro defined in https://github.com/postgres/postgres/blob/master/src/include... .

khuey• 14 days ago

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.

queoahfh6• 14 days ago

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.

znpy• 14 days ago

Is this another llm-driven rewrite?

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

queoahfh6• 14 days ago

From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function?

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

malisper22• 14 days ago

I'm not sure what you mean? The rust code you're showing mimics the Postgres code: https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...

The boolean being returned is the return value of the function. It's not used to return an error.

eu-tech-tak3• 14 days ago

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?

orphea• 14 days ago

  will it only bring more "memory safety" or is there a serious performance gain as well?

The project will die in a couple of days or weeks. You're making a mistake if you're seriously consider using this in any capacity.

rhogan• 14 days ago

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.

emilsedgh• 14 days ago

Maybe it will, but having a performance comparison will be very interesting nontheless.

vips7L2• 13 days ago

As is every slop generated project. It’s the Toy Story meme irl.

https://knowyourmeme.com/memes/i-dont-want-to-play-with-you-...

eu-tech-tak3• 13 days ago

I am not considering it at all. I am simply curious if switching to Rust has any significant performance benefits or not.

malisper22• 14 days ago

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.

groundzeros20155• 13 days ago

I don’t think that’s true.

guenthert5• 13 days ago

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.

solid_fuel8• 13 days ago

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.

dirkc4• 14 days ago

How would one go about reviewing a piece of code like this?

One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you much anyway.

ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious

[1] https://github.com/malisper/pgrust/commits/main/?since=2026-...

bakugo2• 14 days ago

Vibe code was never meant to be reviewed.

These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done.

In practice, this is never true for any codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.

coldtea• 14 days ago

And run them in test setups to try to find bugs.

If you find some, fix them.

wartywhoa233• 14 days ago

reality doesn't seem to be an obstacle for vibe

Went straight into my vault of brilliant quotes!

dirkc4• 14 days ago

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.

aforwardslash• 13 days ago

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.

mvanbaak2• 12 days ago

Vibe code was never meant to be reviewed.

It was also never meant to hit production.

DuncanCoffee• 14 days ago

The github cli has a command to query commits with a sorting asc/desc flag

https://cli.github.com/manual/gh_search_commits

here's the docs with more syntax using the "before x date"

https://docs.github.com/en/search-github/searching-on-github...

there's also an advanced search page, but it does not support commits when filtering with dates

https://github.com/search/advanced

or you can bisect the date in the search widget, this is the first day with a commit

https://github.com/malisper/pgrust/commits/main/?since=2026-...

first commit:

https://github.com/malisper/pgrust/commit/22113dc36b02973060...

dirkc4• 14 days ago

Thanks for all the info you've provided!

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

egorfine9• 14 days ago

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.

EDM115• 14 days ago

How do you easily get to the first commit in a repo on GitHub?

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...

booksock6• 13 days ago

(I'm working with malisper on pgrust),

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/

wrs• 13 days ago

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.

Engineer: We’re allowed to have bugs?

fpgaminer2• 13 days ago

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.

erichocean• 13 days ago

reviewing the testing/fuzzing process

I've got insanely good at designing testing oracles over the last year for exactly this reason.

I've ported some extremely finicky software between languages that it would have been borderline abusive to have a human do.

Codex 5.3 and later for those interested.

dmitrygr2• 13 days ago

And what happens when your "tests" are also vibecoded. Right now all of these houses of cards reset on human-written tests. What happens without them?

andai4• 13 days ago

Oh, I just posted a similar comment elsewhere in the thread.

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)

At any rate, it's never been this cheap to produce the proof of correctness of a program, or on the other hand, to produce an exploit for an incorrect program.

skydhash• 13 days ago

ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious

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...

isatty2• 13 days ago

Very smart. I like it.

jimbokun3• 13 days ago

You don’t. You trust that passing the regression tests means you are totally compatible with the original version.

gorgoiler• 13 days ago

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.

anhner• 13 days ago

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.

tosti• 13 days ago

I started by looking at the dependencies.

Then I lost count, so I ran wc -l Cargo.lock

   1467 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.

ChadNauseam• 13 days ago

Do you pick your databases based on how quickly they compile and how many dependencies they have? I normally chose based on factors like performance and reputation for reliability

gen2brain2• 13 days ago

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.

figassis• 13 days ago

The naysaying here is insane. Should a project like this not exist?

WillDaSilva• 12 days ago

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.

pornel• 12 days ago

Use cargo tree to understand Rust/Cargo deps.

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 for 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.

HumblyTossed2• 12 days ago

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.

wtetzner3• 12 days ago

So your solution is to just read through all 1M+ lines of code?

cyberjar• 14 days ago

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.

rjh297• 13 days ago

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.

solid_fuel8• 13 days ago

Current Postgres is per-process. Switching to threading yields performance improvements.

Please describe in detail what you believe this means and the mechanism by which switching from processes to threads improves performance.

scotty79• 14 days ago

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.

evil-olive• 14 days ago

The goal is to make Postgres easier to change from the inside

uh-huh, sure.

you want to show off "look what the LLM can do / look what I burned a bunch of tokens on"?

you want to brag about how your LLM-generated slop is somehow more maintainable than the original because blah blah blah Rust?

here [0] is the version history of Postgres. pick a version from the past. let's say 14.x because it's the most current that's still under active support.

have your LLM implement version parity with 14.x. show off how it passes all the tests blah blah blah.

then have it upgrade your codebase to parity with 15.x, implementing whatever new features and bugfixes that includes.

and have it generate an automated test that demonstrates upgrading an actual database from LLM-14.x to LLM-15.x and verifying there's no data loss or corruption. maybe even multiple such tests, if you're feeling fancy.

then lather, rinse and repeat with 16, 17, and 18.

and show off the diffs of each version. does the LLM rewrite a huge pile of already-working code in the process of each version upgrade? does it introduce new latent bugs in the process - the kind of things the existing test suite didn't think to explicitly test for?

"I took a static snapshot of code and converted it to another static snapshot of code" is meaningless. all you're doing is bragging about having more money than good sense.

the stability and trustworthiness of software like Postgres does not come from a one-time snapshot showing tests passing. it comes from the engineering process that produces the software and its test suite.

oh, and for shits and giggles, because this same test was so illuminating with the Bun "rewrite" into Rust, here is the file with the most unsafe blocks in the codebase:

    > rg -c unsafe crates/backend/parser/gram_core/src/convert_ddl.rs
    128
    > wc -l crates/backend/parser/gram_core/src/convert_ddl.rs
    2055 crates/backend/parser/gram_core/src/convert_ddl.rs

why 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

tgv2• 14 days ago

It's not just unsafe, it's this:

    let r = unsafe { &*p };

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.

ykonstant• 14 days ago

Genius! Rewrite Postgres in Rust by rewriting Rust in C!

malisper22• 14 days ago

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.

malisper22• 14 days ago

why is the parser unsafe at all?!?

The parser was generated by c2rust. The Postgres parser is generated from yacc/bison itself so I didn't bother making it idiomatic.

groundzeros20155• 13 days ago

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?

grugdev42• 14 days ago

Neat as a pet project, but anyone thinking of using this is production is insane.

Rewriten in Rust is becoming a meme now.

isatty2• 13 days ago

Been a meme for a while now. I avoid that noise on principle.

sneak• 14 days ago

Now do Freetype and libtiff/libpng/etc.

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

melodyogonna• 14 days ago

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.

pessimizer• 13 days ago

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.

pezezin• 13 days ago

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/

voihannena• 14 days ago

<something> rewrite to rust using AI sound like meme now.

https://news.ycombinator.com/item?id=48474313

Xmd5a• 14 days ago

Rust is a stripper

booksock6• 13 days ago

jstrong• 14 days ago

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

rjh297• 13 days ago

Yes, see top comment.

rubnogueira• 14 days ago

I think the cool thing about these projects is that even if test parity reaches 100%, some bugs are going to surface on the new project that don't exist on the original project.

This is usually a good example of a test case that the upstream project is not covering and can be contributed back.

Parity should be bidirectional, so definitely it is possible for both parties to benefit from it.

malisper22• 14 days ago

Hey author here. Wasn't expecting to see this up.

To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture.

I'm now working on a new, not yet published version of pgrust that incorporates a lot of techniques. Currently the new version:

  - Passes 100% of Postgres regression suite
  - Implements a thread per connection model instead of the process per connection model Postgres does
  - Is 50% faster than Postgres on transaction workloads
  - Is ~300x faster than Postgres on analytical workloads. Right now it's 2x slower than Clickhouse on clickbench and I think it's possible to get faster than Clickhouse

If you have any questions, I'm happy to answer them.

barrkel• 14 days ago

Is it being used in production anywhere, even if only a toy app?

I know you say it's not production ready and not optimized yet, but in the same breath - in your comment here - you say it's already faster.

malisper22• 14 days ago

It's not used in production. I've been using different benchmarks to compare the performance vs other systems. Namely sysbench-tpcc[0] and clickbench[1]

[0] https://github.com/Percona-Lab/sysbench-tpcc

[1] https://github.com/ClickHouse/ClickBench

jl6• 14 days ago

"Is 50% faster than Postgres on transaction workloads" - That is a very big claim! 50% faster on everything? Is it a strict improvement across the board or are there tradeoffs that make some workloads slower?

malisper22• 14 days ago

The 50% is specifically on percona-tpcc[0]. I got there through a mix of batching (postgres processes a row at a time), prefetching, and several handful of other optimizations.

  [0] https://github.com/Percona-Lab/sysbench-tpcc

tudorg3• 14 days ago

- Is ~300x faster than Postgres on analytical workloads. Right now it's 2x slower than Clickhouse on clickbench and I think it's possible to get faster than Clickhouse

That sounds like you are storing the data in a columnar format? Or do you do both row and columnar?

In a somewhat similar (yet also quite different) effort, I've been working on δx, a Postgres extension that compresses the data in a columnar format stored in normal Postgres tables (so replication, crash recovery, pg_dump, etc. still work normally). https://github.com/xataio/deltax

It is currently about 30-40% slower than ClickHouse (single node, ofc). The PR to add it to clickbench was just accepted, so you can see the comparison here: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

malisper22• 14 days ago

Yep! The new version of pgrust supports batch based execution and a columnar format. I'm curious how you got δx to perform that well? From what I've seen a columnar layout only gets you part of the way and really good parallelism and really fast hash tables seem to make up a significant portion of why Clickhouse is faster.

gnull2• 14 days ago

What was your methodology and structure in making the prompts for the rewrite? Did you let the LLM roam in all of the codebase and tests from the beginning, or revealed things to it gradually in some way?

boomskats• 14 days ago

This is great! Those analytical workloads numbers are mad - I'd love to see the benches, and I'm happy to contribute to some of the profiling.

How does your thread-per-connection model compare to Heikki's proposal[0][1] from back in 2023?

[0] https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5... [1]: https://www.youtube.com/watch?v=xLLakMmVtbY

malisper22• 14 days ago

Rust actually made the change pretty simple. The main changes are:

  - Use thread local variables
  - Move everything from shared memory to process memory
  - Use threads instead of processes

I've started to see meaningful benefits by changing the parallel algorithms to use a shared memory space. For example parallel hash joins have to copy tuples through shared memory to pass them between workers. That's just not something I have to do.

dimes2• 13 days ago

While a thread-per-connection seems like an improvement, do you have any plans to allow query multiplexing over a single connection? That would be a huge improvement IMO.

malisper22• 13 days ago

Can you elaborate on the use case for query multiplexing? Is it so your client would only need to establish one connection with Postgres and then could run as many queries as it wanted?

solomatov2• 13 days ago

Super impressive! Is it possible for you to share your methodology of using LLMs?

malisper22• 13 days ago

My approach has changed throughout the course of this project. Throughout most of the project, we were working off of a c2rust translation of Postgres to Rust. That gave us a bunch of Rust code that was unsafe but did pass the Postgres test suite and was fast. c2rust had split Postgres into 1000 different crates. We then went through 1 by 1 and rewrote each crate into idiomatic rust.

This naturally lended itself to a suite of skills to describe how to rewrite a crate from unsafe rust to idiomatic rust. The main three skills I had were 1) a skill for identifying the next crates to port 2) a skill for rewriting a crate and 3) a skill for auditing a crate and making sure there weren't any outstanding issues.

My exact approach for managing subagents changed throughout the project. Initially I was doing parallel coding sessions with Conductor. After dynamic workflows came out, I used that as it was really easy to spin up dozens of parallel subagents and manage it from a single orchestrator. Over time I switched from using dynamic workflows to manually spinning up subagents from a central agent. The issue with dynamic workflows is they waterfall. Each step needs to finish before the next one starts. By manually spinning up subagents, I could have claude start porting a new crate as soon as a prior subagent finished.

film424• 13 days ago

A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.

fpgaminer2• 13 days ago

If it's a choice between performance and being able to "safely" run sketchy extensions, I'd rather have performance.

fluffybucktsnek• 13 days ago

I'm not informed of the Postgres's internals, but, maybe, that can be solved by grouping threads into different processes depending on which set of extensions they request.

toast0• 13 days ago

Doesn't postgres (rightly) have a cow if a process has a disorderly shutdown (at least while in a write transaction) because there's shared memory between the processes?

win311fwg6• 13 days ago

An OS thread per connection can be fine for performance if you don't have to scale your connections, but if you don't need to scale connections why have connections at all? Databases are even more performant when you eliminate connection overhead entirely.

TZubiri• 13 days ago

Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested."

Clearly a process per connection is more stable and that's what I'm using.

It's unclear what problem such optimizations are solving anyway, with the old way you could only support a million concurrent users with a single server? Are we missing out on supporting ten million concurrent users with 2 servers instead of 10? Ostensibly reducing the minimum db hardware opex for a 10B$ company from 10k$/month to 2k$/month?

pilif• 13 days ago

That’s not true for Postgres however: due to its usage of a shared memory pool, whenever a subprocess is terminated unexpectedly, Postgres will kill all other processes and enter recovery mode, replaying the WAL, during which time it will not accept connection requests.

It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.

skybrian2• 13 days ago

A more modern way to do this might be to support WebAssembly plugins.

The extensions might need to be rewritten, but hey, we have AI for that now, so why not :-)

andai4• 13 days ago

Is that a serious issue? Wouldn't it just restart the split second later? Or does it take a long time to start?

(Or I guess it would get stuck in a doom loop or something?)

quadrature2• 13 days ago

Are you fixing the heap and table management ?. Postgres does not use an undo log and manages all table updates directly in table storage which slows MVCC.

also have you told Ben Dicken ? https://x.com/BenjDicken/status/2074326407795417435

malisper22• 13 days ago

That's something I eventually want to fix. The challenge is the storage format is so integral to Postgres that it's going to be a huge PITA to come up with a novel design.

Right now OrioleDB is in beta. Once that becomes production ready, I'll evaluate incorporating it into pgrust.

For Ben Dicken, he has seen the project: https://x.com/BenjDicken/status/2074512043462603236. We're still working on all the novel features so I don't think it meets his bar quite yet.

OsrsNeedsf2P• 13 days ago

What's your actual background and expertise with Postgres and databases more broadly? Basically, do you actually know what you're doing, or is there likely a massive footgun you don't know or haven't shared with us?

malisper22• 13 days ago

I spent a couple years managing a Postgres cluster with a petabyte of data. I wrote a couple blog posts from my work then[0][1]. I also wrote dozens of posts on the Postgres internals[2]. I've also given talks on how to generate fractals with SQL[3] and how to write a lisp interpreter in SQL[4].

[0] https://www.heap.io/blog/testing-database-changes-right-way

[1] https://www.heap.io/blog/analyzing-performance-millions-sql-...

[2] https://malisper.me/table-of-contents/

[3] https://www.youtube.com/watch?v=xKoYIvMFnoQ

[4] https://www.youtube.com/watch?v=MPSMH8w7nfw

happyPersonR• 13 days ago

Do you have anything in the regression test suite like jepsen etc?

malisper22• 13 days ago

Nothing major yet. Once I wrap up the performance work I'm doing I'll start looking at the best way to go about testing. I suspect there's a lot of novel things you can do with agents.

levkk• 13 days ago

Ouf. I don't know. I don't want to call you out without evidence -- I myself make benchmark claims all the time -- but 50% improvement in OLTP seems suspicious. I get that you used a standard benchmark, and I don't even know what it entails, but my spidey sense is going off. Perhaps, some trade off somewhere that won't make it to prod because it breaks MVCC -- and yes, I saw that it passes regression tests.

Just checking, is fsync on? :) Regression tests don't catch bad IO patterns afaik.

Anyway... sounds like a fun project to work on!

LtWorf6• 13 days ago

Remember when databases were faster to run in virtualbox rather than bare metal? (because virtual box was completely ignoring all the instructions to flush the data on the disks)

codys• 13 days ago

It'd be very unfortunate if Postgres didn't have regression tests for data loss due to bad io patterns. Should be possible to do some checks against those in an appropriate test harness. Which might mean "have qemu run something we can kill off and examine the results".

If those don't exist, I hope folks recognize how useful they are and add them.

f311a3• 13 days ago

Yeah, claims that it can be faster than CH are very suspicious. CH guys are very good at their craft, they spend hundreds of hours optimizing one single small detail.

kardianos2• 13 days ago

PG Wire proto 3 is my largest source of frustrations.

I'm playing with a POC for a better wire protocol here: https://github.com/solidcoredata/pgwire4

jeltz10• 13 days ago

404 Not Found

mattgreenrocks• 13 days ago

I am super curious how you went about the port using LLMs. At $WORK we are looking to port code, preferably with LLMs, and it seems daunting, even with a test suite. Do you have an approach that works well for you?

hoppp7• 13 days ago

Bun has an interesting blog post about how it was ported. It did cost a lot, much more than hiring people would cost outside USA.

reinitctxoffset• 13 days ago

This is how to LLM. Big ups, I wish the whole front page was stuff like this (and I think it'll happen).

Everyone is so worried about the value of commodity software going to zero. It's like, yeah, going into CS for the money always looked dumb to me, it's just not a good career path for that, you have to love it.

I am way more excited about a whole new class of stuff that obliterates the state of the art at every frontier.

Keep doing it legend.

kfsone• 13 days ago

It doesn't sound like you were trying to launch a product, but doing an experiment and someone threw you under the HN-spotlight-bus :) Is this a "see what I can achieve with LLM coding" or is this "build this and see how much of the coding can be accepted from LLMs"?

greatony• 13 days ago

It's a completely new era of software production (I will no longer call it development) LLMs give us unlimited manpower, and the language give us constraints to make more modern and safer softwares. Love to see this rewrite in Rust, and expecting much much more in next few month.

teravor• 13 days ago

when doing rewrites like these, why isn't the first step to instrument the original code so that you would get very good automated test suites to point the LLM toward?

use both synthetic and real data to sample the internals of the original software to duplicate.

locate all the data transformation junctures, sample and then replicate the tranforms 1:1 in the rewrite.

bluGill3• 13 days ago

That forces you not only in not the intentional good decisions of the past but also copies too many bad ones.

jimbokun3• 13 days ago

That…is really impressive. Well done!

chuliomartinez• 13 days ago

Just a couple of ideas if you run out of backlog:) - proper versionnumber (64bit) - native json streaming. It would be awesome to get to the point where i could somehow redirect the sql output to the browser directly, but piping will do for now. The idea is to be able to stream rows to client without caching and building json along the way.

drchaim• 13 days ago

i highly doubt you can make it faster than clickhouse, but happy to see it.

egorfine9• 13 days ago

build a better version of Postgres

Faster is quantifiable. How do you measure better?

up2isomorphism2• 13 days ago

300x is mostly a marketing term, especially without the test description.

BTW, showing no respect to what it is trying to copy looks uncomfortable.

brikym• 13 days ago

Awesome work. I'd love to see you add something like kusto query language or pql. The autocomple on kusto, (which can be embedded into web apps) is really amazing.

eu-tech-tak3• 13 days ago

How much of the performance gain is from using Rust, compared to using optimizations that are not done in the original PostgreSQL code (like using threads instead of processes, etc.)?

I am simply curious what the benefits of using Rust are in this instance.

agumonkey• 13 days ago

Is it your first rewrite/migration (with or without llm) ?

good luck nonetheless

Keyframe3• 12 days ago

I don't want to knock you down as most have already did. In-fact it's a useful exercise going forward in exploring how to work with AI. It's here, we're all going to use it one way or the other. Zero issues with that, in-fact kudos to going through the pain of it all.

Now, having gone through several such endeavors originally myself, albeit with internal tools and systems (as an exercise), I've noticed that while all my tests passed with flying colors the rewrite itself was broken even on basic functionality or missed a ton of details. It was in effect useless when I dived into it. Initial tests also showed massive gain in performance, and I know people who were involved aren't really dumb so something smelled funny. Turns out all those things left out and honestly... moments were the key ingredients.

What I did learn from those beginning explorations though was that one-shotting, grand architecture or source up-front, master plans up-front.. all these do not yield good results - YET. Who know what we'll see in few years though. What I did found that works (FOR ME, nota bene) is to keep the design and checklists for myself, written by myself and then do a small piece by piece.. as if you would if you were coding alone or if you would waterfalling a small team of talented juniors. Then, suddenly super happy results come out, but then it's mostly you driving all the way where llm writes code and offers advice (which for the most part you ignore). It's a happy place for myself at least. It's then truly unlocking yourself to the mythical 10x.

Rewriting a large proven system with decades of ultra expertise behind it, which I don't have, is guaranteed not to end up the same 1:1 replacement. If you found a recipe for that - please do share.

ramijames2• 12 days ago

I'm curious. Do you attribute this to weak and/or incomplete tests? How granular should tests be to have complete coverage so that an AI won't create a converted codebase that "passes tests" but is still functionally inaccurate?

jakswa• 12 days ago

what model did you try it with? I agree and also push back a bit: How will we know when the LLMs reach the point of handling it if no one takes the leap? I applaud more people sludging through the slop and hauling their slop buckets around.

An example is Fable being released. I felt like the most complex thing I was willing to sludge through was having it clone llama-server's web UI with my own opinions (I really like the original, kudos to them). And the initial skeleton was working so well I felt like I had sunk the tokens and committed to getting it the rest of the way: https://inkcap.click

gulugawa2• 12 days ago

I don't code with LLMs, and think you might be right.

However, Postgres is a tool with clearly defined functionality and doesn't have ambiguous requirements that are seen in user facing software. As a result, it is entirely plausible that the author created a working Postgres replacement for certain use cases.

I personally want to see more evidence about the quality of the tool after it is in a finished state.

AlexClickHouse• 12 days ago

Would you like to submit to ClickBench?

I can also do it if you would prefer...

zX41ZdbW• 2 days ago

https://github.com/ClickHouse/ClickBench/pull/983

gnull2• 14 days ago

Regression tests start to play a different role with LLMs.

On one hand, they give an LLM a short feedback loop to correct itself, and iterate fast when writing code. A human also uses it as a feedback loop, but we don't iterate as fast and don't handle big walls of conditions, so its effect is not as big.

On the other hand, LLM's ability to handle a big wall of if-conditions can backfire if it starts taking shortcuts and taking the tests-as-a-spec too literally, overfitting the solution, overly focusing on the given datapoints (conditions checked by tests) and missing the overall behavior shape that the tests intend to pin down. For humans, this is less of a concern because we are bad at big walls of if-conditions, and we'd rather try to see the original shape that the tests are pinning down than monkey-patch the solution to fit the individual points.

It's interesting to see how one balanced these two. In this case particularly. Maybe you could play around with separating the data you give an LLM into "training set" and "validation set", training set can be seen fully, but validation set is hidden and is only queried when the solution is deemed ready. Say, training set = original source code + half of the tests; LLM uses that for quick feedback loop. And validation set = the remaining half of the tests; test code is not shown to the LLM and run only when the LLM says it's done to catch potential overfitting of the resulting solution over training set.

To me, the credibility of a solution like that would depend on what methodology the authors used. If they just let the LLM see all tests, I'd be skeptical (albeit unable to point out specific bugs due to the volume of work and LLM's ability to make bad things look trustworthy). The good thing is, real-life use will add new, unseen before datapoints for testing — so validation set will build up with time. Really curious to see how it will work.

giovannibonetti• 13 days ago

Property testing and deterministic simulation seem like good alternatives.

mstaoru• 14 days ago

Great! Now ask it to rewrite it in CSS!

cyber12• 14 days ago

2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.

malisper22• 14 days ago

Note that most of the unsafes are confined to the parser which was generated by running c2rust over the Postgres parser. The Postgres parser is itself generated from yacc/bison, so I decided to port it over mechanically rather than idiomatically.

If there's particular unsafes that you think are egregious, let me know.

saym• 13 days ago

Just wanted to say: I'm thoroughly impressed with how far in the weeds you're replying in this comment section. I'm learning a lot from the threads.

dvhh2• 13 days ago

I don't know if converting the code could be an issue with copyright, but might be contrived as plagiarism

kaspar030• 14 days ago

I set all my Rust LLM written projects to 'unsafe=deny'. Not sure why not everyone is anticipating your comment.

HeavyStorm• 14 days ago

Why even use rust...

maximilianburke2• 13 days ago

Because in C everything is unsafe, by definition.

robotic• 13 days ago

Let me just copy this review comment into my prompt.

a few hours later

Fixed!

atombender• 12 days ago

Counterpoint: All of the current Postgres codebase is already wrapped in an invisible unsafe{}.

The difference with a Rust codebase like this is that all of the unsafe code has been neatly isolated and clearly marked. The outside code is safe — at least according to the definition of what Rust considers safe, which is a high bar indeed and objectively superior to the unsafe mess that is C — and the unsafe code is naturally fenced in, which means that it can be seen by developers and tackled by incrementally.

In some cases unsafe is unavoidable, but it is possible for a human to verify that it is, in fact, acceptably safe even if inside an unsafe block.

cyber12• 12 days ago

Valid point, but unsafe in Rust is more dangerous than unsafe in C, bcs of aliasing. For example PG is compiled with -fno-strict-aliasing.

Decabytes• 14 days ago

It’s interesting to see how llms have turned the concept of rewrite it in rust, from an impossibility for some projects (code is too large and complicated, it will take too much time) to a real possibility for even large projects.

vintagedave2• 14 days ago

This is impressive - but is a license change, from the PostgresQL license [0] to AGPL [1].

I like the AGPL and think it's the best truly free open source license, but I worry if this is compatible. Ie, if this is rewritten from the original source, should the original apply? (Yes.) There has been a trend to rewrite open source software with a more restrictive license (like coretools in Rust). This looks considerably more ethical by choosing the AGPL - I just wonder, safer with no change at all?

[0] https://www.postgresql.org/about/licence/

[1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

mustache_kimono• 13 days ago

Wow, yeah, really hate this.

eurleif• 13 days ago

You seem to have the restrictiveness backwards? The MIT license (uutils coreutils) is less restrictive than the GPL (GNU coreutils), and the AGPL is more restrictive than the PostgreSQL license.

And it doesn't violate the PostgreSQL license to license the rewrite more restrictively. That's part of what makes MIT-style licenses less restrictive than the GPL or AGPL: they allow for more-restrictive relicensing.

vintagedave2• 13 days ago

Perhaps ‘restrictive’ was a poor choice of words. ‘Less free’ in the free-software sense.

I’m still putting together my thoughts on various open source licenses especially as we see automated AI rewriting.

LastTrain2• 13 days ago

If you don’t like the license just let an LLM spend a few days “porting” it and give that port any license you like because that is apparently what we do now.

____tom____2• 13 days ago

Yeah. I'm gonna have an LLM rewrite Star Wars and then film it. Should be fine, right?

maxloh3• 13 days ago

The PostgreSQL License is a variant of the BSD license and is therefore compatible with the (A)GPL.

Comprehend it this way: You create a blank (A)GPL project and incorporate the upstream BSD codebase into it. While those original upstream files remain under their original permissive license, the project as a whole is governed by the (A)GPL (plus the attribution requirements of the upstream license, which the GPL permits). From there, you can add your own code under the AGPL and distribute the combined work under the AGPL.

If someone takes your code and uses only your portion, they can use it under the AGPL alone. However, if they also include the upstream source code, then the attribution requirements of the upstream license must still be met.

pavon• 13 days ago

Yes, BSD licenses are compatible with AGPL meaning BSD licensed code can be combined with AGPL licensed code while complying with both licenses. However, it does not give you permission to relicense the BSD code (or derivative works) as AGPL. The author is free to license any new code they write as AGPL, however the license for the machine translated code is another question. If it is considered a derivative work (which I think it should be) then it must remain under the Postgres license.

If it is not a derivative work, then for copyright to apply at all then it must be an "original work" which has "at least a modicum" of creativity applied by malisper in the translation. If this is satisfied then malisper could choose any license for the translated code they want, compatible with Postgres or not. If it isn't satisfied then no license applies, because it isn't eligible for copyright - essentially it is public domain.

The safe and polite thing to do is to keep the same license when performing machine translation.

otterley7• 13 days ago

If this software was written by a mechanical process, the license is a nullity. It’s public domain.

teraflop• 13 days ago

Being created by a "mechanical process" from an existing creative work doesn't mean it's not a derivative work.

For instance, if I take a copy of $BIG_BUDGET_MOVIE, and resample the video frames from 1080p to 720p through a purely mechanical transformation, that doesn't make the output public domain.

cestith3• 12 days ago

It wasn’t written by a mechanical process, though. It was ported (translated) from an existing creative work into a new language.

Surely you wouldn’t say a Spanish translation of a Harry Potter work is in the public domain while the original work is under copyright?

MuteXR2• 13 days ago

The Postgres license is already fully compatible with the AGPL. BSD/MIT is more permissive.

ahachete• 12 days ago

AGPL and copyleft licenses are not restrictive, they provide forward (open source) guarantees. The only thing they "restrict" is the ability to remove freedoms. Therefore is not a restriction, is a guarantee. A guarantee that the project will endure as open source.

I wouldn't go as far as calling permissive licensing "restrictive" because they actually allow for reducing freedoms; but copyleft is definitely not restrictive at all, it's the opposite.

Having said that, I like and appreciate both kind of licenses and I have and will continue creating open source software using ones or the others.

Chyzwar• 14 days ago

I think the best way to test this would be to put PgBouncer or a similar proxy in front of a busy production database, and mirror queries to both traditional Postgres and the Rust one at the same time. Then you can compare output and performance under real load. After running it for a while, you could diff the tables one to one against the normal Postgres instance.

ben0x539• 13 days ago

Can you control the timing of queries across two db instances well enough to expect the tables to be identical?

srdjanr• 13 days ago

Good question, I guess you can run two identical Postgress instances and check if they have a diff

lukasco2• 14 days ago

Quite a lot of projects are trying this "rewrite to a new language using LLM", both internally, or externally (like is here). For me, they confirm some (slightly controversial) takes.

1. human code reviews are dead. We don't yet know what's next. Two reasons they are dead: too much code to review, and code reviewing sucks (who wants to spend their days reviewing code?) 2. Not knowing how to review LLM code is a big barrier to adoption, but bigger regression test suites (testability/evals) is almost certainly the direction. 3. There are a lot of projects that haven't moved to more modern infra because it was too hard. Now it's much easier. Sure stuff will go wrong. Sure it all has to be tested. What's new here? 4. Programming languages for LLMs are coming. 5. Projects that don't allow AI coding will be forced to come around or fade.

Separately, bit off topic:

New projects will often have LLMs built in, so non-determinism will be inherent in the project. No amount of code review will be able to eliminate that.

vips7L2• 13 days ago

I suspect the future of open source will be to never publish your tests. Or someone will just pump them into an LLM like this.

manquer2• 13 days ago

SQLite already does this but hasn’t stopped the rust /go clones from popping up .

These are toy projects with no serious interest in maintaining the port long term. and even with things like bun where the port is merged it remains to be seen on maintainability over time.

JodieBenitez• 13 days ago

I'm glad there's a go clone for SQLite, it' easier to integrate into a Go project, especially when you have to support multiple platforms.

tcfhgj• 12 days ago

These are toy projects with no serious interest in maintaining the port long term.

source?

hkchad• 13 days ago

X written in Rust seems like the new Hello World for LLM coding agents now.

dzonga• 13 days ago

codebase full of code that wouldn't fly in production.

I ain't no Rustacean - but 'unsafe' calls all over.

sdevonoes2• 13 days ago

Don’t understand these rewrites.

- typically they are behind a single person. That’s usually bad because of spf

- typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term

- anyone that wants to contribute to the project needs to pay. Needs to pay tokens because it’s increasingly difficult to maintain these projects without AI

So, who wants to put something like this in production? Doesn’t make much sense

kirubakaran• 13 days ago

Everything has to start somewhere

rvz• 13 days ago

How is that going for Claude's C compiler [0], or Cursor's web browser? [1]

[0] https://github.com/anthropics/claudes-c-compiler

[1] https://github.com/wilsonzlin/fastrender

pyrolistical• 13 days ago

It’s open source. You take ownership of it for your deployment and stop relying on continued free work.

You can use llm to pull in updates as they are released. It’s not gpl, so you don’t need to publish your port

ahartmetz• 13 days ago

You don't even need to publish your port if it's GPLv3 as long as you don't publish the binary.

sdevonoes2• 13 days ago

The companies I have worked for before all have used open source software like postgres, mysql, go, python, k8s, etc. 99% of the time we relied on free work; never contributed to these projects nor forked them for our own needs. I don’t think this behaviour is the unusual path tbh

cyphar2• 13 days ago

1. Nobody, not even the Googles or NSAs of the world do that. No single entity has the expertise nor resources necessary to maintain a fork for every open source project they use -- forking and maintaining Linux alone takes teams of people. And no, going full psychosis mode with LLMs is not going to save you.

2. This project is AGPLv3.

yasaheblasa• 13 days ago

If you were a token burning company a project like this seems like a solution to this: https://xkcd.com/2347/

that hits your metrics without the problem that your contributions are not welcome.

pier252• 13 days ago

it’s increasingly difficult to maintain these projects without AI

It's pretty much impossible in a project of this size. IIRC Postgres has over 1M loc.

sqquima• 13 days ago

Are there modular databases with clearly differentiated components? I wouldn't be surprised if there aren't, as the trade-off with modularity is usually performance.

scottlamb• 13 days ago

I'd be interested to hear the author's answer to your question, but I see it as an interesting proof-of-concept. It's testing the viability of not only rewriting PostgreSQL in Rust (and their choice of deps) but also in switching the threading model and other architectural changes. LLMs shine at pumping out prototypes insanely fast, and a working prototype can put an end to a lot of speculation.

I likely wouldn't use a rewrite of such a huge project if it doesn't have the backing of the original team (or a significant fraction thereof) and a believable story for having matched/exceeded the original code quality and maintenance. I also think in general using an LLM for license-laundering is legally and morally hard to defend, although this case is different in that they chose a more restrictive license. Not a lawyer, but my understanding is that you can just download PostgreSQL, do s/MIT/AGPL/ and release it, legally. (The original MIT-licensed version still exists, so no reason anyone would prefer yours until you make another release with some compelling new feature.)

seb1204• 13 days ago

Not the same but it is much faster and easier to re-create a 3d model of an existing set of drawings than from scratch. This is because a lot of the decisions have already been made.

anonzzzies2• 13 days ago

It's not just a rewrite ; it has improvements. I did the same thing for fun for the same reason; I wanted to see if I can improvements on some of the legacy design stuff and, especially, the stuff PG people have told us that it cannot be done differently. It can. I would not put it in production, but it thought me a lot about the internals of databases. To keep my brain happy in the age of LLMs, I implement database things on our (also old but many times refactored/rewritten) production db without an LLM. I'm sweating through Flexible Paxos now; probably we will just keep using raft as it's old and stable and simple but it's interesting anyway.

fg1377• 13 days ago

I would not put it in production

Nobody else would either.

If this is meant for personal learning, do it that way and make it clear that others should not even consider using this project.

In fact, even for personal learning it's wasteful. You can learn so much about database without a rewrite like this.

Blahagun• 13 days ago

It's a very interesting phenomenon in recent years and most of the discussions about "why" are immediately blocked by the "memory safety" argument, as if it's a silver bullet for all things that are considered "bad" in software implementations. No matter how good the language is, and I consider Rust a very good language, it's practically impossible to replace years of experience and tested code, most of it contributed by a ton of brilliant programmers, no matter how you look at it. And if we take this as the truth, then logically there's still an unanswered question - why? Lets take an undeniable fact - rewriting an existing project give you full control over the new implementation. You can do whatever you want with it, you can't be sued. The only thing now you have to hope for is for your implementation to gather a good enough user base and from then on you can practically hijack the original project. And this is me speculating - rewriting stuff in Rust isn't about the greater good for that magical "memory safety" argument, but at the end it's an attempt to hijack popular software projects.

andai4• 13 days ago

I think we're a year or two away from the same argument being used by languages which enforce proof of correctness. The economics seem to be shifting in that direction.

Finding exploits is getting exponentially cheaper, and the cost of producing proofs is rapidly going down. For a lot of software correctness is rapidly becoming non-optional.

egorfine9• 13 days ago

impossible to replace years of experience

People with no experience don't have enough experience to realize what exactly they are missing here.

egorfine9• 13 days ago

it's an attempt to hijack popular software projects

Exactly. And this is why those projects are typically called "XXX in Rust" or "XXX-rs". Because the creators get to do their favorite thing - coding in their loved language - while skipping all the hardships of designing, accepting real feedback, involving users and getting traction - all while simultaneously hijacking the existing brand.

As of now I know of a single project that changed their name after being called and the project surprisingly got some traction.

andai4• 13 days ago

typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term

Lindy effect! The longer something has been around, the longer it probably will be.

https://en.wikipedia.org/wiki/Lindy_effect

Jean-Papoulos• 13 days ago

It's useful to show the actual team that it's possible. From there, they can make the decision of whether to go the bun route with more information.

Griffinsauce• 13 days ago

This is true but these projects are rarely presented or interpreted as a proof of concept.

ai_fry_ur_brain• 13 days ago

The bun route == spending 100k for an LLM rewrite as an advertisement for the LLM company you sold your soul to.

lucideer2• 13 days ago

I'm not sure I see the value in "showing the team it's possible". I would presume the team are intelligent enough to be well aware that it's possible, given tradeoffs. And as it's clear those tradeoffs have been "traded" in this case, it doesn't seem like having the knowledge confirmed is particularly surprising.

jorisw• 13 days ago

spf meaning...

fragmede3• 13 days ago

single point of failure

davedx• 13 days ago

This is very critical of an open source project that the maintainer didn't even post here?

"Status:

pgrust is not production-ready yet. It is not performance optimized yet."

The maintainer is not suggesting you use this for anything yourself. So why do you care about spf or (lol) his "discipline in creating the project"?

lucideer2• 13 days ago

The gp feels like less of a targeted individual criticism & more of a general musing about a trend.

Nobody is saying this author hasn't demonstrated discipline & won't maintain this project, but the statistical averages across most projects fitting this trend make it likely enough to question their worth in aggregate.

fg1377• 13 days ago

Because chances are that it's never going to be production ready, never trustworthy enough to be used by anything serious, and the project will eventually be archived and become at best a (extremely inefficient) learning experience for the author, or at worst a total waste of tokens. I could be completely wrong about this specific project, but most of these projects are like that, and statistics don't lie.

gen2brain2• 13 days ago

But this is also just silly. The maintainer here did nothing (just a little chat here and there), but is sure that only optimizations are missing for this to be production-ready. How so, based on what exactly?

wanderlust1232• 12 days ago

100%

People on HN love complaining at any given moment.

I’d wager most of these people don’t really produce much and are constantly bikeshedding.

teddyh2• 12 days ago

The author is free to ignore any and all complaints they consider unfounded. It’s not even like the author is recieving any complaints personally; they have to come here to see any. And if they come here, they will get to read the viewpoint visible from here.

(Repost of <https://news.ycombinator.com/item?id=45253509>)

itomato• 13 days ago

This year, not me.

In five? Everybody but me.

SuddsMcDuff• 12 days ago

So, who wants to put something like this in production?

I don't think anyone suggested deploying this to production - the author is quite explicit that it's an experiment.

whacked_new• 12 days ago

I'm really happy to see these rewrites. It shows what's possible, especially as the projects get more and more complex.

And maybe Remacs will get reactivated https://github.com/remacs/remacs/wiki/Progress

Maybe even I'll be able to do it when I wait for the bus!

mawadev• 12 days ago

I guess it is cool to have it around but it comes off as a popular useful case for AI which it really isn't, unless you have a very good test suite to throw the agent against, it is practically useless for rewrites of decades old badly documented code riddled with technical debt. That is where the real value and challenge would be. I see it as marketing and social clout stunt

pojzon• 13 days ago

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

Too many things tests wont catch.

nalekberov• 13 days ago

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

diziet3• 13 days ago

I love llm coding. I don't know what I am looking at here

https://github.com/malisper/pgrust/blob/main/Cargo.lock

What is happening.

No PRs? No Make files? I understand running tests and debugging is the workflow, but where do you log things? How do you orchestrate builds? Etc.

nemothekid• 13 days ago

`Cargo.lock` is a lockfile machine generated by Cargo. It's similar to package-lock.json. In any case, its machine generated the old fashioned way.

diziet3• 13 days ago

I am fully aware what Cargo.lock is. What I am surprised at is how many dependencies there are.

kaoD2• 13 days ago

I love llm coding. I don't know what I am looking at here

There might be some correlation here.

diziet3• 13 days ago

I am fully aware what Cargo.lock is. What I am surprised at is how many dependencies there are.

antonvs• 12 days ago

Like most modern languages, Rust has its own build system and package manager, Cargo. Everything you're referring to relates to that, and has nothing to do with LLM coding.

Edit: saw the clarification in another comment. But, in that case the essential point seems to be "I'm not familiar with something, therefore it's suspect."

SirHackalot4• 13 days ago

I don’t trust AI rewrites, definitely not in 2026 — possibly never.

briandw2• 13 days ago

Code is code. It either does the job or doesn't. If there is nothing that could convince you that AI generated code is trustworthy (for whatever definition of trust) then this is an article of faith, not a rational position.

SirHackalot4• 13 days ago

Disagree, it’s already a leap of faith to trust even human code (which is why we try to prove code, or at the very minimum create guardrails with tests). Human reasoning itself is under doubt. It’s even more of a leap of faith (>>) to trust code generated by AI reasoning (which I can only currently call “homunculus reasoning,” it’s not inferior but it’s just got the probabilistic aspect of reasoning). People who YOLO their work to Al are practicing a different form of faith. I like knowing what my code does, and making correct predictions about it. A mental model is very important. My position is very rational, yours is faith-based. This is a technology that has many cool uses, but this is not one of those uses (in 2026). Unless the author can convince me they have as good of a mental model of this rewrite as the makers of the original source code. Maybe they do, I’m sure they would run circles around me, but I need the confidence that this isn’t going to wake me up at 3am because of some bug. And the only way I know that about PG is because I trust the creators.

munchler• 13 days ago

Code is code. It either does the job or doesn't.

Surely that is not the only dimension that matters when evaluating software. Maintainability and readability, for example, are crucial for any long-lived project.

0xferruccio• 13 days ago

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

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

kburman• 13 days ago

`seams` is the new emdash

whartung• 13 days ago

I just want to quibble that the 100% Postgres regression tests do not test the threaded aspect of this project, and that is a pretty fundamental architecture change.

fukaiall• 13 days ago

Rust feels like the just right language to produce all those slops of AI and the language itself. Great to promote yourself as a productive engineer, but at the end of the day you’re just reinforcing the statement that AI and the language itself are great, not you.

password4321• 13 days ago

Jepsen or GTFO.

These days there's little chance for a new DB to build its community using network effect. If you want this to catch on, switch to manually grinding community building ASAP gold plating the experience for a specific niche (AI can guide your priorities but will hinder your comms). Otherwise, have fun building!

subarctic3• 13 days ago

I mean if it's actually just another Postgres, you don't have to worry about network effects as much because anyone could use it in place of Postgres. But sure, the more people you know using this, the safer it would feel to use it

krater23• 13 days ago

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

henry2023• 13 days ago

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

bigwhite• 13 days ago

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

I have a feeling that AI is rewriting everything!

gchamonlive• 13 days ago

And they'll reproduce virtually the same problems, because code was never a primary issue for output. Products reflect organizational problems, which AI can't solve.

kopirgan• 13 days ago

Where will this leave the c based driver which I believe is the basis for many others?

krupan• 13 days ago

I started my programming career by porting code from one model of TI calculator to another. It was code I could not have written from scratch myself at the time. I learned a lot about the two different versions of TI Basic that the calculators used, but I didn't learn how the program really worked. I can't even remember now if it was Tetris or the tank game that I ported. Maybe it was both? That was a boring English class...

I totally understand why porting code is fun. It's kind of like when I checked out drawing books from the library as a kid and just traced the pictures because my own attempts at drawing were so bad. It gives you a feeling of accomplishment, even though you didn't actually do anything that difficult. And you do learn some things along the way.

Doing the same with an LLM probably gives you that similar feeling of accomplishment, even though you didn't actually do that much (sorry, hate to say it that way). I wonder if you learn even less in the process. Maybe you just learn different things.

Now that I think about it, even writing some code from scratch with an LLM is not much different than doing a porting project. Someone else did the hard work of creating the original programs that the LLM was trained on, and now you (the LLM really) are just porting/restating what someone else did. I hadn't thought of that before

simonw• 13 days ago

The WebAssembly demo that runs in your browser is a really neat touch: https://pgrust.com

malisper22• 13 days ago

Thank you! I'm a big fan of your writing. I wanted to make sure there was something people could try out so I could show pgrust was real and not vaporware.

booksock6• 13 days ago

Thanks! Should work well on Mobile too :)

f311a3• 13 days ago

The code is so weird, people will have a hard time reading it when they need to check for correctness.

There are much better ways to write it in Rust: https://github.com/malisper/pgrust/blob/14ffab7d31a31e5ab667...

wavemode• 13 days ago

I mean, you've linked to a function performing md5 hashing. That's pretty much exactly what I would expect such code to look like.

Case in point: https://github.com/postgres/postgres/blob/master/src/common/...

f311a3• 13 days ago

It's not idiomatic implementation in Rust, just translation from C. A few Rust macros simplify implementation and cut the code in half.

luciana1u• 13 days ago

finally, a database that will refuse to compile your schema migration because you used an unsafe join. progress.

shevy-java• 13 days ago

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

happyweasel• 13 days ago

Porting perfectly working C code that has been in production for decades (and has a great track record wrt to security fixes) to rust is more or less an obfuscation challenge.

ak392• 13 days ago

Chuckled at the anti-climactic sentence ending! lol

sgt2• 13 days ago

An academic exercise for sure. The Postgres team won't use this and take it forward, hence it will go stale and rot within months.

literalAardvark• 13 days ago

Or someone who likes it could run codex-get -y upgrade on it once every two weeks and it'll be fine for as long as you can afford the tokens.

codingjoe• 13 days ago

Given that you reuse Postgres' tests and LLM have been clearly trained on Postgres' three decades of contributions, this may constitute a license violation. Unless you include the original license of course. From a human level I also understand how you ended up with a less permissive license.

dvhh2• 13 days ago

License for test might be subject to debate, because afaik the project is merely running them.

but yes the test files should be presented under their original licence.

up2isomorphism2• 13 days ago

It is very bad metric to measure a rewrite using the original tests. It is like to say you clone a cat by mimic 600 cat images.

PeterStuer• 13 days ago

Let's hope it did not special case (overfit) for the specific tests. One of the failiure modes that in my experience takes the most effort to mitigate for.

cjd8• 13 days ago

rewrite of already popular technology in a different language look at commit history "Claude xxx committed yyy ago"

I'm sorry, but what is this need to just vibe code a port of an existing technology to a different language/framework/etc.? If it's just a personal challenge then sure I guess, but this surely can't be used as a real product?

ak392• 13 days ago

Is the 300x performance boost attributable to the threading model vs process model?

Was the code for the threading model written by hand or was it translated from the WIP threading model the human PG team is busy with as part of the 2028 roadmap?

rlvk• 13 days ago

I'd like to know on what machine and on what testbench the supposed 300x boost is achieved so that we can independently verify it. My assembler-written fork of postgres is achieving 600x boost on SELECT 1;

Havoc• 13 days ago

Did similar with S3 and that too (eventually) did well against tests (the ceph s3 ones).

...but haven't dared use it for anything meaningful yet. Still feels like there is a real world gap in confidence when it comes to vibecoded rewrites.

Been wondering whether the answer is to insert a proxy...something that effectively splits traffic to a known S3 and the rewrite and compares outcomes over time. Do that for a couple different workloads for a month or so and if it's all identical then it's probably fine...

HackerThemAll• 13 days ago

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

manupati• 13 days ago

Database & AGPL bad combination

abbefaria27• 13 days ago

Setting aside the “why” that everyone is so focused on, I want to know, how? I can’t get Claude to do anything even a fraction of this complexity. How are people setting up their agents, Claude.md, etc to do such big projects? There are a lot of lessons to be learned.

benjiro29• 13 days ago

I can’t get Claude to do anything even a fraction of this complexity.

I remember writing a postgresql compatible DB with Opus 4.5, that used S3 as storage and local caching to make it speedy.

Ironically, Opus 4.5 is by todays standards is antique. If you have some knowledge about Databases, it goes a long way.

But you need to do it step by step. Getting the core to work, getting a Pratt parsing going. The whole pgwire protocol ... the data format ...

Step by step ...

With todays Models, your can probably get away with using /goal and telling it to make a postgresql compatible database, while having it run a few days.

Now, making a fun database test project and having it production ready! Big difference!

fg1377• 13 days ago

If you can do a Rust rewrite with AI, I can create one as well. What makes yours better than mine? Your decade long expertise in database or Rust language? Your reputation? Your proven track record to manage large, complex projects? Your time committed to the project? I don't see any of that.

I don't know why anyone would choose this over the actively (community) maintained proper Postgres project.

cmrdporcupine3• 13 days ago

Came here to the same thing. I did something similar (but bolder, it doesn't slavishly copy Postgres and is based on current DB research papers and the like, and other bits I've been exposed to over the years). It has a full TPC-C-esque benchmark suite, replication, embedded v8/JavaScript relations/stored procedures, a giant suite of regression tests, it kicks the crap out of a lot of existing OLTP DB stuff out there. And I personally do have a background in commercial DB development.

But I choose not to publish it or promote it for many of the reasons you mention above (and more)

... For one, if "I" can do it, so can a hundred other people. And all the bold claims behind it would need to be backed up and supported and it promoted, etc, which is a whole pile of time that doesn't involve writing code.

It's the organization around a project that matters, not the code. It's not the 90s anymore w/ people piling into MySQL because it was the only option. People aren't going to be trusting your software with their data, if they can't trust you.

And unless someone is going to dump a pile of money or something on [me|them], I don't have the ability to build that organization ... as I need to feed my family... Nor am I willing to put my personal reputation on the line by putting up a huge quickly written application and then someone finding something in it I can't explain.

So like probably 500 other projects I have it sitting in a private repo.

It's a very weird time right now. "Technical" excellence isn't the important part. Organizational excellence is. This was always the case but it's more so now.

... In the meantime, if anybody has angel investment to burn, I have something potentially better/more-exciting than this guy's project but... see above...

wkoszek9• 12 days ago

Author of this project is not that different than you. The only difference is that he is willing to take the risk. If you have an invention and sit on it, nothing will happen.

wanderlust1232• 12 days ago

There’s no claim being made that your rewrite cannot be better.

He has provided benchmark results which provide a dimension amongst which to measure your rewrite. If you can do better by all means post your rewrite.

Finally, these kind of projects can eventually over time become projects that are actively used. Postgres is not some entity that existed before the universe was created; it was also created by someone and then eventually adoption picked up over time.

cmrdporcupine3• 12 days ago

In terms of the software industry, Postgres actually is kind of that entity. It predates the entire commercial DB (and, er software) industry and is one of the first implementations of a viable relational database server, back into the 70s.

It has a 40ish year continuous history. (Which is also why it has technical/design warts like process-per-connection that we probably wouldn't do in 2026, but that's another story.)

Even with that I remember getting funny looks 20-ish years ago when I would advocate for using it instead of MySQL.

With databases, reputation is everything.

naasking• 12 days ago

If you can do a Rust rewrite with AI, I can create one as well.

Translations are a lot more likely to be error-free and robust, as the original data structures and algorithms have been battle tested.

wkoszek9• 12 days ago

His project is cool. Students could use it as an example of porting code. Companies could switch to it, if it works. There are hundreds of reasons why people may want it, so it's awesome he's publishing one. Something needs to be done to get interest and then adoption.

fg1377• 12 days ago

Let me just point out:

The project is not cool. This is not a new idea, and there is nothing special.

Students won't use it as an example of porting code. I am not aware "porting code" is part of standard software engineering or computer science curriculum. That's not the kind of thing being taught in schools.

Companies won't switch to it unless their CTOs are either insane or incompetent.

quantummagic2• 12 days ago

Just keep using the proper Postgres project if it makes more sense to you. But notice that this isn't just a strict translation, it actually makes changes (moving from process to thread based design, for instance). Time will tell if people find these changes beneficial or if the original remains preferable.

It's also worth noting, that while you are able to use LLM's to produce your own translation, he's actually done it. There's value in actually putting in the work.

This isn't a unique situation at all. Many Postgres extensions are developed and maintained by a single person, and may therefore be avoided by more conservative users, even if they offer some technical advantages. To each, their own.

panny• 13 days ago

use Rust plus AI-assisted programming
pgrust is licensed under AGPL-3.0

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

millerm• 12 days ago

You got me with the rewrite, you lost me with AI.

hptnrr• 12 days ago

This is a stunt for freshpaint.io that sells AI. No one will use this plagiarized monstrosity.

wkoszek9• 12 days ago

Congrats for launching this project. I think it's awesome. I did two similar projects, just to learn how to work with LLMs and it felt good--reminded me times debugging code with GDB and going through stuff in semi-manual mode.

I'm building data + AI platform. It got complex, and I'm using AI-assisted coding to move fast. One thing that helps me was property based testing. I have a traffic generator that simulates 10 users working on my platform. I run it 24/7 and if it shows that the software survives the test (I called it "fate" after ffmpeg's CI), it's good enough to roll out. If you wrote something like that, core PostgreSQL folks would like it too, unless there's something equivalent like this. It'd be: create random tables, fill with random data, then issue randomly constructed query.

xyst• 12 days ago

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

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

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

touisteur• 12 days ago

Might be a very good occasion to actually improve the test suites from our load-bearing software projects. I feel this will be the decade of a cat and mouse game between LLM PRs and finding good (as in convincing whomever is paying you and is waiting for any occasion to fire you for being anti-progress or something).

Hopefully we get: actual formal coding rules, spec rules, design rules, contribution rules, documentation and testing rules. High Integrity development processes impose that you write all this before you start and makes sure you follow your own rules.

So. I guess... welcome everyone to explicit software and systems development processes.

gulugawa2• 12 days ago

This the type of AI generated tool I'm interested in seeing more of. I'm a fan of how the quality is verified using clearly defined quantitative measurements for performance and correctness.

I'm still skeptical about LLMs and don't use them, although I can be convinced by more demonstrated examples of success.

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

Related Stories