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

Join the discussion

• Hacker News
• 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.
  by gingersnap
• I feel like we need to heavily differentiate between a rewrite and an AI rewrite.
  by juliangmp
• 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 more ethical by choosing the AGPL - I just wonder, safer with no change at all?

  [0] https://www.postgresql.org/about/licence/

  [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

  by vintagedave
• 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.
  by cyber1
• I think the best way to test this would be to put PgBouncer or a similar proxy in front of a busy production database, and mirror queries to both traditional Postgres and the Rust one at the same time. Then you can compare output and performance under real load. After running it for a while, you could diff the tables one to one against the normal Postgres instance.
  by Chyzwar
• 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 much anyway.

  ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious

  [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

  by dirkc
• 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 because it’s increasingly difficult to maintain these projects without AI

  So, who wants to put something like this in production? Doesn’t make much sense

  by sdevonoes
• 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 incorporates a lot of techniques. Currently the new version:

    - Passes 100% of Postgres regression suite
    - Implements a thread per connection model instead of the process per connection model Postgres does
    - Is 50% faster than Postgres on transaction workloads
    - Is ~300x faster than Postgres on analytical workloads. Right now it's 2x slower than Clickhouse on clickbench and I think it's possible to get faster than Clickhouse
  

  If you have any questions, I'm happy to answer them.
  by malisper