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

111–120 of 756 posts

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

#111

Post by rixed »

arka2147483647 wrote: post #79
ottavio wrote: 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!

> the biggest blocker on moving to a new programming language, is the cost of re-writing everything

In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?

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

#112

Post by dxdm »

satvikpendem wrote: post #8

We had one for SQLite (which is SQL-ite btw, not SQ-Lite which doesn't make any sense) via Turso, no wonder we see the same for Postgres. Personally I do want to see libraries be in as much memory safe languages as possible.

How do you know it's not SQL-lite with the single L serving a double role?

Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.

AFAIK there is no official word on how the name is intended to be read or said.

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

#113

Post by xlii »

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.

As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.

The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.

And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.

Now the new, test-based implementation, has to prove it can handle remaining 99%.

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

#114

Post by sneak »

Now do Freetype and libtiff/libpng/etc.

I have privately wondered for years, pre-AI, why Apple hadn’t paid some engineers to go off and write some comprehensive test suites and then port these to Swift. It would shut down entire swaths of memory safety bugs they have been coping with for literally decades. SO MANY of the zeroclick iOS exploits can be traced to a few fragile and vulnerable foss libraries, xkcd 2347 style.

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

#117

Post by rhogan »

orphea wrote: post #100
eu-tech-tak wrote: post #72

How is the performance compared to regular PostgreSQL? I know it says it is not performance optimized yet, but if this succeeds, will it only bring more "memory safety" or is there a serious performance gain as well?

will it only bring more "memory safety" or is there a serious performance gain as well? The project will die in a couple of days or weeks. You're making a mistake if you're seriously consider using this in any capacity.

I also suspect this will die very shortly, which is a real shame, not because it will be beneficial but because of the time and tokens needlessly spent on something that will be thrown out.

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

#119

Post by coldtea »

bakugo wrote: post #104
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…

Vibe code was never meant to be reviewed. These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done. In practice, this is never true for any…

And run them in test setups to try to find bugs.

If you find some, fix them.

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

#120

Post by byzantinegene »

sshine wrote: post #14
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.

> not mostly the test, but the real world production scars Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour. SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some gua…

a code written to pass a test can surface unintended new bugs.
Post reply on HN