Live data from Hacker News

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

github.com

241–250 of 756 posts

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

#241

Earlier quoted context omitted.

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…

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

None of those concerns approach the level of priority that must be assigned to security. On defense, your security must be perfect forever or you are absolutely defeated. None of us are on the red team. It's not a rash decision, it's the only decision that logic allows. If you are not secure, you are NOTHING.

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

#242

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…

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.

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

#243

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…

(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

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

#244
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-thousands-of-po...

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

#245
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/

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

#247

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…

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

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

#248
post #33

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.

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!

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

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

#250
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/

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?

Post reply on HN