2026-07-11 · Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is July 11th, 2026. Welcome to the show. Today, we are looking at a full rewrite of Postgres in Rust, a major migration story from the Haskell world, and a hobbyist project that gets Doom running on a custom bytecode VM. Fred, I feel like you have been waiting all week to talk about the state of database engineering.

GuestI have been waiting all week to see how long it takes for a project like this to actually run a production workload without corrupting someone's primary key. Daniel, you know my position. The Postgres source code is not just code. It is decades of battle-tested edge cases and recovery logic. Just because you can point an LLM at a codebase and emit something that syntactically resembles Postgres does not mean you have built a database.

HostYou are talking about pgrust, which is an experimental rewrite of Postgres in Rust that claims to pass the full regression test suite. The author is suggesting that this makes Postgres more accessible, but over on Lobsters, the reaction has been a mix of professional skepticism and some pretty sharp debate about what this actually represents. A user called tartley basically treats this as a case study in how not to do engineering, calling it a neat trick that nonetheless ignores the deep expertise baked into the original project.

GuestTartley is right to call it a trick. The real work in a system like Postgres isn't just passing the regression tests today. It is maintaining state consistency when the power cuts out while a vacuum process is running. A Lobsters user called mdaniel rightly notes that even if it technically works, the AGPLv3 license makes it a non-starter for most enterprises. I am not anti-Rust, obviously, but I am anti-illusion. You cannot short-circuit thirty years of institutional knowledge with a chat prompt.

HostLet us pivot to something that feels a bit more like a deliberate strategic shift. Avi Press, who is heavily involved in the Haskell ecosystem, wrote a post explaining why his company, Scarf, is moving from Haskell to Python after seven years. He basically argues that while he loves Haskell, the current era of LLM-driven development favors environments that are fast to iterate in, rather than those that require a heavy build-system tax.

GuestI saw this one. A user called lilac on Lobsters basically cut through the noise, noting that the article spends a lot of time complaining about community politics and AI sentiment rather than just the technical tradeoffs. It is fascinating, though. Moving from Haskell to Python is essentially saying that your business velocity is now tied to how well your LLM can predict your intent, and evidently, the LLM prefers dynamic typing and a loose runtime over rigorous compile-time guarantees.

HostA user named wezm in that same thread makes an interesting point, though. They are surprised that a transition to Python, which, as we know, comes with a lot of runtime risks, was the move. They suggested that something like Go or OCaml might have been a better middle ground if they wanted to keep some type safety while shedding the Haskell overhead.

GuestThat is the trade-off, right? If you are just trying to feed an AI the context it needs to generate a functional API endpoint, Python is a very dense language. But you are trading correctness for convenience. I am not saying you cannot build a business that way, but as mrak points out in the Lobsters thread, this is a clear sign that the academic, pragmatics-last lean of Haskell is finally hitting a wall in an industry that now demands immediate, AI-accelerated output.

HostFinally, we have a project that I think you will actually appreciate, Fred. A developer picked up an old hobby project called UVM, a custom stack-based bytecode virtual machine, and used an LLM to generate a custom LLVM IR parser. The goal was to run existing C code, specifically Doom, on this custom VM without having to write a full Clang backend from scratch.

GuestNow, this is a use case for AI that I can actually get behind. Writing a full compiler backend is a massive, often tedious task. If you want to play around with architecture or build a custom VM, you shouldn't have to spend three years writing a frontend. Using a tool to bridge the gap between LLVM IR and your custom bytecode is smart. It is basically the same thing I do when I use my own static analysis scripts to verify memory layouts in low-level drivers; I am not trying to replace the compiler, I am just trying to make the bridge between my brain and the hardware less exhausting.

HostIt is a nice reminder that the value of these tools is often in skipping the boilerplate that keeps people from finishing their passion projects. That seems like a good note to end on. Doom is the universal constant of computing, and if we can get it running on a custom VM by using an AI as a glorified translator, then maybe there is some hope for the industry yet.

GuestAs long as the AI doesn't try to rewrite the Postgres rendering engine next, I think we will be okay. I might have to spend my weekend auditing some of the generated IR, though, just to make sure it is not doing anything truly cursed under the hood.

HostThanks for coming on, Fred. We were pulling these stories from the community at Lobsters, so check them out if you want to dive into the threads yourself. We will be back tomorrow with more.