Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

341–350 of 756 posts

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

#341

Post by waterTanuki »

CamouflagedKiwi wrote: post #133
arka2147483647 wrote: post #79

Earlier quoted context omitted.

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!

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. I guess every company that needs distribution / failover has a mainframe sitting in their office nowadays huh?

https://k3s.io/

https://kubernetes.io/

https://aws.amazon.com/

https://www.erlang.org/

etc.

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

#342

Post by erichocean »

booksock wrote: post #245
dirkc wrote: 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'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/

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

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

#343

Post by queenkjuul »

Suzuran wrote: post #222
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.

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

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

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

#344

Post by waterTanuki »

colechristensen wrote: post #143
egorfine wrote: post #124

Earlier quoted context omitted.

> significant part of the rust community consists of software talibans I seriously don't get it though. Rust is a nice language, but so is X. However we don't see X people brigading existing projects with constant bombardment with "rewritten in X". What is that about Rust that prompts this behavior?

Rust attracts zealots because of the various kinds of safety guarantees. The speed means it can replace more or less anything. People see the safety as a moral superiority so it attracts obnoxious zealots. Other languages' features and syntax aren't nearly so easy for zealots to form behind. The perception of absolute safety it puts in some people makes them crazy.

A more plausible explanation:

People were told for years they can't use Rust for their new projects because it hasn't been "proven" in industry yet. So the option was to sit back and wait (chicken and egg) or move to rewrite a bunch of projects so that it could actually be "proven". Not saying this is the only reason why it happens (every language has its Zealots) but it certainly makes more sense.

Due to the explosion of new programming languages over the past few decades your options are to either aggressively expand wherever possible or die out because you're not "proven".

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

#345

Post by philipbjorge »

0x000xca0xfe wrote: post #185
mechazawa wrote: post #94

Earlier quoted context omitted.

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.

I'm too young but I imagine assembly programmers were feeling the same when automatic code generation by compilers took over. Very weird.

Wow, I would love to read an interview series based on this!!

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

#346

Post by tremon »

fpgaminer wrote: post #292
film42 wrote: post #262

Earlier quoted context omitted.

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.

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

Do you mean that you don't run sketchy extensions and therefore this doesn't affect you, or that you're ok with data loss due to extension failures?

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

#347

Post by toast0 »

film42 wrote: post #262
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…

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.

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?

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

#348

Post by robotic »

cyber1 wrote: 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.

Let me just copy this review comment into my prompt.

a few hours later

Fixed!

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

#349

Post by SirHackalot »

briandw wrote: post #336
SirHackalot wrote: post #293

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

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.

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.

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

#350

Post by fukaiall »

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.
Post reply on HN