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

#271

Post by LastTrain » Thu, Jul 09, 2026, 9:59 PM UTC

vintagedave wrote: post #195

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…

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.

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

#272

Post by quadrature » Thu, Jul 09, 2026, 10:00 PM UTC

malisper wrote: post #147

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

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

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

#273

Post by 27183 » Thu, Jul 09, 2026, 10:01 PM UTC

nextaccountic wrote: post #151

gingersnap wrote: post #3

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.

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

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

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

#274

Post by [deleted] » Thu, Jul 09, 2026, 10:02 PM UTC

quadrature wrote: post #272

malisper wrote: post #147

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

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

[deleted]

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

#275

Post by jeltz » Thu, Jul 09, 2026, 10:02 PM UTC

surajrmal wrote: post #226

kstrauser wrote: post #7

Earlier quoted context omitted.

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.

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)

PostgreSQL's tests are mostly integration tests.

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

#276

Post by jeltz » Thu, Jul 09, 2026, 10:03 PM UTC

joshka wrote: post #67

guenthert wrote: post #45

Earlier quoted context omitted.

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

It would be reasonably easy to audit and automate this...

It is not a requirement the PostgreSQL project wants to have. It would be a heavy burden and mostly pointless.

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

#277

Post by solid_fuel » Thu, Jul 09, 2026, 10:03 PM UTC

josefrichter wrote: post #232

byzantinegene wrote: post #146

Earlier quoted context omitted.

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

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

It's a very fair and generous way to frame the question, considering you like seeing these rewrites for "learning".

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

#278

Post by malisper » Thu, Jul 09, 2026, 10:04 PM UTC

quadrature wrote: post #272

malisper wrote: post #147

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

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

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.

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

#279

Post by tudorg » Thu, Jul 09, 2026, 10:04 PM UTC

malisper wrote: post #204

tudorg wrote: post #172

Earlier quoted context omitted.

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

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.

Yeah, spent a lot of time on parallelism, vectorizing, pipelining, filter push-downs, bloom filters, all the tricks out there. It's really fun to make pretty steady progress on this.

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

#280

Post by solid_fuel » Thu, Jul 09, 2026, 10:07 PM UTC

booksock wrote: post #244

pknerd wrote: post #44

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

(I'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-th…

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