> 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 guarantee of equivalent diligence.)

And yes, years and years of running.

> 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 though. If there is, just give it to Claude so they will incorporate it in their development loop

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

I agree. I also agree with the sibling reply that -

> every time you have a bug or a regression, you write a test that confirms correct behaviour.

What I fail to see in these rewrites however is - what about new bugs introduced by virtue of this rewrite? I mean it'll have to go through its own challenges in real-world scenarios, right?

And also the amount of people running it in thousands of scenarios. Not sure if these areas can be even tested for, but I guess time will tell (can observe Bun if it breaks somewhere as that’s afaik the first big AI rewrite which got into prod for masses).

The test suite is the result of these years of years of running in production. Every time you fix a bug, you add a non-regression test to ensure you don’t break it again.

In a project like PostgreSQL, those scars are reflected in unit tests demonstrating that they’re fixed. It’d be hard to pass its test suite and not be as robust as the original.

Completely agree with this.

The biggest lie of software engineering is that everything can be testable with tests. That a 100% test coverage is an indicator of quality software.

That's precisely what a regression test suite is for. There is a bug, you fix the bug, you add a regression test. So if the test suite is well maintained these real world production scars are reflected in the tests.

I hope you are not true at all.

Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.

I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.

What is this even for logic?

I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.

And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.

Wait - does the AI rewrite the tests too? If so, lol.

This is great! Those analytical workloads numbers are mad - I'd love to see the benches, and I'm happy to contribute to some of the profiling.

How does your thread-per-connection model compare to Heikki's proposal[0][1] from back in 2023?

[0]: https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5... [1]: https://www.youtube.com/watch?v=xLLakMmVtbY

  - Use thread local variables
  - Move everything from shared memory to process memory
  - Use threads instead of processes

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

That sounds like you are storing the data in a columnar format? Or do you do both row and columnar?

In a somewhat similar (yet also quite different) effort, I've been working on δx, a Postgres extension that compresses the data in a columnar format stored in normal Postgres tables (so replication, crash recovery, pg_dump, etc. still work normally). https://github.com/xataio/deltax

It is currently about 30-40% slower than ClickHouse (single node, ofc). The PR to add it to clickbench was just accepted, so you can see the comparison here: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

What was your methodology and structure in making the prompts for the rewrite? Did you let the LLM roam in all of the codebase and tests from the beginning, or revealed things to it gradually in some way?

"Is 50% faster than Postgres on transaction workloads" - That is a very big claim! 50% faster on everything? Is it a strict improvement across the board or are there tradeoffs that make some workloads slower?

  [0] https://github.com/Percona-Lab/sysbench-tpcc

Is it being used in production anywhere, even if only a toy app?

I know you say it's not production ready and not optimized yet, but in the same breath - in your comment here - you say it's already faster.

The github cli has a command to query commits with a sorting asc/desc flag

https://cli.github.com/manual/gh_search_commits

here's the docs with more syntax using the "before x date"

https://docs.github.com/en/search-github/searching-on-github...

there's also an advanced search page, but it does not support commits when filtering with dates

https://github.com/search/advanced

or you can bisect the date in the search widget, this is the first day with a commit

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

first commit:

https://github.com/malisper/pgrust/commit/22113dc36b02973060...

> How do you easily get to the first commit in a repo on GitHub?

You can use the syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 (-1 for the latest and -1 for the last)

ex : https://github.com/malisper/pgrust/commits/?after=3646a73515...

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 codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.

> How would one go about reviewing a piece of code like this?

That's a wrong question. The right question is "why would one go about rewriting a piece of code in X". Once and if you find a good answer to that question, you will see the answer to your's.

Note that most of the unsafes are confined to the parser which was generated by running c2rust over the Postgres parser. The Postgres parser is itself generated from yacc/bison, so I decided to port it over mechanically rather than idiomatically.

If there's particular unsafes that you think are egregious, let me know.

I set all my Rust LLM written projects to 'unsafe=deny'. Not sure why not everyone is anticipating your comment.

Why even use rust...

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

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!

> software talibans

I will note that, very funny

> Why should a developer use this for anything beyond a pet project?

If it _is_ 50% faster, then that's the reason

Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?

How exactly are rewriting something the equivalent of being the taliban?

I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs.

You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.

rewrites feel like an area where LLMs are better suited than humans imo

It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)

It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.

I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!

It’s just a build step now.

I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.

It's not that... It's a rewrite by project maintainers vs a fork.

We already have a well established term for AI rewrites.

Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?

AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.

A human rewrite without maintenance is just a hobby project. An AI rewrite is just wasting tokens for god knows what?

People feel threatened by LLMs doing things well that they feel should require their skills and talent.

That's understandable but it's still a bit of a negative emotion that probably isn't very productive. Or very rational. This thread is full of people trying to argue that this can't be any good, shouldn't be any good, and is clearly going to end in tears. And obviously this thing passing tens of thousands of carefully curated tests that accumulated over decades suggests otherwise. It's hard to argue against that.

This probably is going to have some new issues. But it's an impressive achievement.

Because it’s uncomfortable to see decades of work copied so trivially.

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

I am concerned about the quality. Even a cursory skim of the code makes the code appear asinine. Unless the genius aspects of the code elude me.

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

I don't really understand how "written by AI" and "for learning purposes" can ever be compatible. What exactly does one learn from typing "Rewrite this in Rust, make no mistakes" into a terminal?

I think a business case for a "look I let an LLM rewrite a large codebase" does not exist.

It's pure virtue signaling.

Software raidership?

Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.

  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.

The version in the GitHub repo is ~8x slower than Postgres. I have a new unpublished version that is 50% faster than Postgres on transactional workloads and ~300x faster on analytical workloads.

I would expect Postgres to be heavily tested with things like Valgrind and various sanitizers. I'd be surprised if there were low-hanging fruit. But also, if there is code that does something fishy with pointers, wouldn't the AI likely paper over it by adding an unsafe block in the Rust version, preserving the same fishiness? It's hard to know how hard it would try to prove that the original is broken.

You are exactly right. There is no freaking way there was no unsafe behavior in a code case of the size of Postgres.

In fact from a porting effort this is the first blog post I would expect. Not that the hey we successfully did it.

As long as tokens are cheap

When the software consists entirely of ~$1000 worth of Claude credits and ~40 hours of developer time prompting and curating it, literally what does it matter what license the resulting 100k LoC artifact is provided under?

Copyleft and the whole software licensing ecosystem only matter when producing that software actually requires serious human effort and dedication.

[dead]

It is theoretically possible to have a Rust port of Postgres support extensions. If you make all the relevant functions and structures ABI compatible with Postgres, extensions should work. The issue is the moment you're dealing with C pointers and C strings, pretty much all the code you have to write is unsafe.

They would need rewriting (a few are included)

> why is the parser unsafe at all?!?

The parser was generated by c2rust. The Postgres parser is generated from yacc/bison itself so I didn't bother making it idiomatic.

It's not just unsafe, it's this:

    let r = unsafe { &*p };

It looks as if it's building structs out of information in (mutable pointers) to other structs without an Rc in sight. Which makes sense for a C parser: you've got a table with data, so you just link to it. It's fast, and when you know you're not going to touch it, it's safe. But this doesn't make the Rust code any better than the C code.

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.

Also, are they calling it Postgrust?

I make no claim as to whether the change makes sense given that I didn't look at the callers of this function, but Result<bool> is an entirely reasonable pattern in Rust. If you want the callers to be able to distinguish between "has the subclass", "doesn't have the subclass", and "something went wrong" this is idiomatic Rust.

It is a feature in Rust, not a bug :-) (I know you didn't say it is a bug.)

The error-tagged union is PgResult<bool> - which means it contains bool as the result if things go well. (The other part in the union is of course the error.)

In the original function also, it is returning a boolean: "bool has_subclass".

So anyway you have to check for the boolean as part of the logic. That is what it is doing.

From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function?

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...