Postgres rewritten in Rust, now passing 100% of the Postgres regression tests • Hacker News Board

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

#701

Post by FreakLegion » Fri, Jul 10, 2026, 6:18 PM UTC

tudorg wrote: post #611

FreakLegion wrote: post #414

Earlier quoted context omitted.

pg_mooncake (now effectively abandoned due to being acquired by Databricks, but still up at https://github.com/Mooncake-Labs/pg_mooncake ) pulled the DuckDB engine into Postgres wholesale, if I remember right. pg_lake also uses DuckDB but keeps it external, routing through Postgres and managing Iceberg tables (but not the data itself) there ( https://github.com/Snowflake-Labs/pg_lake ). Both of these were neck and ne…

Actually δx is faster than the "duckdb embedded in postgres" options: https://benchmark.clickhouse.com/#system=+_etx|_b|_i )|dula|pnc&type=-&machine=-6t|ca2|6ax|g4e|6ale|3al&cluster_size=-&opensource=-&hardware=+c&tuned=+n&metric=combined&queries=- Plus all the normal Postgres features work as expected: physical/logical replication, crash recovery, pg_dump/pg_restore, etc.

That isn't what the data shows, but we don't need to discuss it further. My reply was to the person interested in learning from other Postgres OLAP designs. This stuff is all pretty immature though and I wouldn't actually build on it outside of some very narrow, well-understood workloads.

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

#702

Post by NohatCoder » Fri, Jul 10, 2026, 6:25 PM UTC

ramijames wrote: post #651

Keyframe wrote: post #632

Earlier quoted context omitted.

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…

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?

There is no such thing as a complete test suite, there will always be some possible bug that it doesn't catch.

In particular, if you put an LLM in an automated loop of "this test fails, please fix it", there is a pretty good chance that it will simply special case all of the tests, possibly in some contrived way that makes it not at all obvious when you read the code.

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

#703

Post by otterley » Fri, Jul 10, 2026, 6:31 PM UTC

cestith wrote: post #699

otterley wrote: post #677

Earlier quoted context omitted.

I would agree with you but for the author’s attempt to publish it under a new license. I think they can either claim it’s a new work (in which case it’s public domain) or claim it’s a derivative work (in which case I don’t think they can change the license). I imagine a court would call it a derivative work if tested.

Things get released as GPL or AGPL that were originally BSD or MIT license all the time. The terms of the copyleft license include all the terms of the attribution licenses. Whether this is a valid thing legally I’m not sure but it doesn’t seem anyone’s challenged it. BSD code is often found in closed-source proprietary products as long as the required attributions are met and the original contributors are understood…

The BSD license (which is the one at issue here) does not explicitly permit the licensee to change the license terms of covered software upon redistribution. Perhaps it would be permitted under an expansive interpretation, but under a narrow reading, it might not be. The default rule, however, is that all rights not granted by license remain with the owner.

As you said, the question has never been litigated or settled.

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

#704

Post by jiggawatts » Fri, Jul 10, 2026, 6:43 PM UTC

CamouflagedKiwi wrote: post #687

jiggawatts wrote: post #153

Earlier quoted context omitted.

> while you could ask your LLM to do that you aren't going to run your bank on the result. Why not? I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences. The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them! So if you sketch a design for the AI to foll…

Because you know that the current one works. If you have a bank running on COBOL (or whatever), you've had that for 30+ years now, so while it might have bugs, you know what they are. You don't know what the LLM output is. Hence back to my original point: writing the code is not the hard bit. Making yourself (and your CEO etc) comfortable to put that into production is one of the hard bits.

> Because you know that the current one works.

What do you even mean by "works", specifically?

> it might have bugs, you know what they are.

Okay, so it doesn't work, you know it doesn't work, it's just that you accept the specific ways in which it doesn't work.

I've lost track of all the myriad stupid ways in which these ancient systems are hugely ineffectual without even being outright faulty.

Like airline tickets where your name is printed as "LASTFIRSTMR" in all caps and no spaces because their systems are ancient beyond belief.

Similarly, my bank statements are security-critical, because anyone with a copy of my credit card details can pull money out of my account without my express authorization. But...

... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!

I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.

If you look at it from the perspective of someone used to modern web security, then you realise that banking is a raging tyre in comparison. Banks literally just accept a certain rate of criminal activity and "price that in", reversing transactions when asked -- which itself can also be a criminal activity. They just shrug their shoulders.

"What can we do about this?" -- says the people that have tried nothing and are all out of ideas.

Rewrite it. The whole thing.

Use an actual database, something made in the last three decades instead of half a century ago.

Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.

Etc.

I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.

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

#705

Post by wkoszek » Fri, Jul 10, 2026, 7:27 PM UTC

fg137 wrote: post #682

wkoszek wrote: post #662

Earlier quoted context omitted.

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.

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.

If someone did this before with PG, provide links. Practical pragmatic example where I think this project is cool: process vs thread. There were members of the PG core team that wanted to explore it, and members who said it'd tank a project. pgrust is an amazing experimentation ground for it.

I published similar project here: www.emuko.dev - emulator for RISC-V. This one turned out to be 3x as slow as QEMU for example.

re: CTOs - if the improvement is 3% nobody of course will look at it. If the improvement is 30%, it'll be too big for big players to ignore, so as a CTO you'll be tasked with trying it out. It's really a matter of whether this thing is safe and secure, losing data or has a trojan. If the authors can prove it's all valid working code etc., it'll be a viable project.

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

#706

Post by kvuj » Fri, Jul 10, 2026, 7:31 PM UTC

esjeon wrote: post #393

josefrichter wrote: post #47

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

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-te…

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.

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

#707

Post by wkoszek » Fri, Jul 10, 2026, 7:37 PM UTC

cmrdporcupine wrote: post #680

wkoszek wrote: post #665

Earlier quoted context omitted.

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.

That's not it works anymore. Inventing is cheap.

Don't give up. Just publish it, if you know your invention is better. Devtool VCs will give you money based on the growth of your GitHub stars, popularity and the size of community. I can even intro you to some - but it can't be to "burn angel money". You'd just have to commit to build a DB company for 10yrs. Devtool community building is low effort: Discord channel and you can write code in 1 window, and talk in another as your thing is testing/compiling.

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

#708

Post by alemanek » Fri, Jul 10, 2026, 7:45 PM UTC

LtWorf wrote: post #601

alemanek wrote: post #340

Earlier quoted context omitted.

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…

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

Yeah I know. That is their moat. I was more responding to the assertion from OP that running in prod is what makes a product stable instead of tests.

I was trying to call out that SQLite often credits their massive test suite for their stability but likely didn’t communicate that well.

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

#709

Post by rjh29 » Fri, Jul 10, 2026, 8:24 PM UTC

27183 wrote: post #583

cyphar wrote: post #518

Earlier quoted context omitted.

I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?

The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long…

Ladybird's Rust port of the JS engine was a good example. Compare the output byte-for-byte, run both in production (with the new code disabled but checked) before releasing. It was LLM-translated but done carefully.

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

#710

Post by solid_fuel » Fri, Jul 10, 2026, 8:29 PM UTC

rjh29 wrote: post #622

solid_fuel wrote: post #574

Earlier quoted context omitted.

If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.

I'm not interested in a technical conversation with you; I was answering someone else. The top voted comment thread of this page, which dominates discussion, already covers everything you'd want to know.

Ah yeah, what I figured. You clearly have no idea what you're talking about. Don't get all mad when someone calls you out on it.

By the way, just so you have some concept of what the actual problem is despite your resistance to education:

Simply switching from processes to threads will not yield the claimed performance increases. A 300x improvement on analytic workflows? From a direct transliteration? Your BS alarms should be going off. They should be screaming "5 Alarm Fire".

The only way they got that increase was by breaking the synchronization mechanisms that provide ACID guarantees in Postgres, otherwise a direct rewrite would expect very similar performance.