Live data from Hacker News

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

github.com

641–650 of 756 posts

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

#641
post #626

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.

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

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.

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

#642
post #560
post #78

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

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.

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.

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

#643

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…

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

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

#644

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…

Would you like to submit to ClickBench?

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

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

#645

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…

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!

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

#646
post #626

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.

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

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

#647

Earlier quoted context omitted.

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…

> but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result. If only we had a way to solve these issues with tools capable of running Rust programs in that way.…

You misunderstand.

You could run one of these things on a mainframe, because it's a zero-downtime machine - you can swap out parts of them as they run. But fundamentally it's a singleton. It is deeply naive to believe you can trivially translate that to something running on Kubernetes just "because Rust".

Of course most companies that need distribution do manage to do that, and eventually the banks will get there too. But it isn't feasible to do that by translating their existing non-distributed COBOL code, they need a fundamental re-architecture, and that is much harder.

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

#648
post #182

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.

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.

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

#649
post #78

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

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

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

#650
post #551
post #452

Earlier quoted context omitted.

You are correct! TIL, and thank you. Connection processes get a SIGQUIT, shared buffers cleared, and WAL replayed, but postmaster stays alive. It's effectively an online restart.

I’d be very curious to hear what an online restart approach for sketchy extensions crashing a shared thread per connection process might look like. This is more a question for the author of the project but I’m curious if they have plans in that direction.

systems, upstart or even simple primitive script wrapper.

Built-in is also possible: just fork once after start, and you have parent as watchdog and restarter.

Post reply on HN