Live data from Hacker News

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

github.com

361–370 of 756 posts

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

#361

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.

> Code is code. It either does the job or doesn't.

Surely that is not the only dimension that matters when evaluating software. Maintainability and readability, for example, are crucial for any long-lived project.

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

#362
post #283

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…

The PostgreSQL License is a variant of the BSD license and is therefore compatible with the (A)GPL. Comprehend it this way: You create a blank (A)GPL project and incorporate the upstream BSD codebase into it. While those original upstream files remain under their original permissive license, the project as a whole is governed by the (A)GPL (plus the attribution requirements of the upstream license, which the GPL perm…

Yes, BSD licenses are compatible with AGPL meaning BSD licensed code can be combined with AGPL licensed code while complying with both licenses. However, it does not give you permission to relicense the BSD code (or derivative works) as AGPL. The author is free to license any new code they write as AGPL, however the license for the machine translated code is another question. If it is considered a derivative work (which I think it should be) then it must remain under the Postgres license.

If it is not a derivative work, then for copyright to apply at all then it must be an "original work" which has "at least a modicum" of creativity applied by malisper in the translation. If this is satisfied then malisper could choose any license for the translated code they want, compatible with Postgres or not. If it isn't satisfied then no license applies, because it isn't eligible for copyright - essentially it is public domain.

The safe and polite thing to do is to keep the same license when performing machine translation.

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

#363
post #315

Earlier quoted context omitted.

Hardware engineers call them errata ;-)

How many engineers does it take to fix a bug? Hardware Engineers: "None. We'll fix it in firmware." Firmware Engineers: "None. We'll fix it in software." Software Engineers: "None. We'll document it in the manual." Technical Writers: "None. The user can figure it out." etc.

While I get the joke, as a technical writer, you might be surprised how often I've found myself as a defacto QA engineer:

Me: This is what you said it does, and this is what it actually seems to do. Which one is right?

Engineer: Shit.

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

#364
post #323

Earlier quoted context omitted.

Ok ... you know PostgreSQL supports hash tables in shared memory, right? PostgreSQL could in theory share those if we wanted to. The issue is just that coding anything which uses shared memory is a lot of work. Additionally the reasons PostgreSQL does not offer Clickhouse performance has very little to do with parallelism. PostgreSQL plans to move to threading but the efforts around imporving OLAP performance are alm…

i may be missing context, but shared memory across processes, without ipc?

Being really pedantic here, shared memory is considered IPC, but not the kind you're thinking of. Shared address space, no overhead.

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

#366
post #242

Earlier quoted context omitted.

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.

Can you elaborate on the use case for query multiplexing? Is it so your client would only need to establish one connection with Postgres and then could run as many queries as it wanted?

Microsoft SQL Server has had a similar feature for a while -- Multiple Active Result Sets aka MARS. I don't have a good read on whether it actually helps any workloads. I've seen adapters that don't support it because of the extra complication.

https://learn.microsoft.com/en-us/sql/relational-databases/n...

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

#367

Jepsen or GTFO. These days there's little chance for a new DB to build its community using network effect. If you want this to catch on, switch to manually grinding community building ASAP gold plating the experience for a specific niche (AI can guide your priorities but will hinder your comms). Otherwise, have fun building!

I mean if it's actually just another Postgres, you don't have to worry about network effects as much because anyone could use it in place of Postgres. But sure, the more people you know using this, the safer it would feel to use it

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

#368

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…

Pro: Database is perfectly secure.

Con: The database no longer exists.

Also, there is more to security than memory errors. SQL injection, authentication, and access rules matter. It doesn’t matter if Rust database is secure to bad data if it lets anyone in to do anything. Or if it is crashing all the time or corrupting your data.

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

#369

Earlier quoted context omitted.

What about human written software makes it more reliable than LLM written software? is it the craftsmanship, or the deliberate decision making of industry veterans?

It's the notably poor quality of LLM-generated code

As opposed to the incredible code that humans are known to write...

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

#370

Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?

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

I mean you can learn a lot. You can learn what's possible with less effort to build a proof of concept. It's kind of like you had another engineer do it for you, you don't completely learn how to do it yourself but you can still learn a lot with much less effort
Post reply on HN