The most trusted code on Earth is being rewritten in Rust

Key Takeaways

It was the year 2000. An application developer named D. Richard Hipp was working on damage control software for US Navy guided missile destroyers. Yes, a terrorist attack was about to change the world as we knew it, but the bigger problem was that the app Hipp was building relied on a SQL database, and whenever the database server went down, his app would, too. And so, he asked himself a simple question, "Can jet fuel melt steel beams?" Wait, no, that's not the right question. He asked himself, "Why can't I have a SQL database engine embedded inside the application itself that talks directly to the files on disk?" That would get rid of a separate server process, the ports, the configuration, and the neuro-divergent webmaster you needed to keep it all running. He liked the idea so much, he gave it a name, spent the next 25 years of his life building it, and today it may be the most important piece of software ever written. By stripping the database down to a single library that read and wrote to one file on disk, Hipp accidentally made it small and simple enough to drop almost anywhere, which is exactly what happened. And today there are billions, no, trillions of SQL lite databases in the world, and at least one on every iPhone, Android, Mac, Windows, posterior insertable, browser, and Mars rover in existence. It's easily the most trusted and resilient software out there, and in today's video, we'll look at a project that's crazy enough to think they can rewrite it from scratch in Rust. It is June 19th, 2026, and you're watching The Code Report. If someone told you they were rewriting SQLite in Rust, I think you'd have trouble figuring out if they were one of the smartest people you ever met or one of the dumbest. In this case, it's two people, and the evidence points mostly to smart. One of them wrote a book on latency, and the other was ranked by Linus himself as a top-five contributor to the Linux kernel. Their problem was never that SQLite is bad, but rather that it's not truly open source in the traditional sense. The source code is available, and you can do whatever you want with it, but it's maintained by just three people, and they don't accept outside contributions. That model is a big reason why it's trusted, but it also means that if you have opinions on how it could be better, you can remove your SQLite powered posterior insertable and gently return it back to where it came from. Or you can keep it and rewrite the library in Rust. So that's what they did and they're calling it Turso. And the first feature you won't find in SQLite is concurrency. The way SQLite works today is only one writer can touch the database at a time. With Turso, multiple writers can work on different parts of the database simultaneously and only conflict if they actually touch the same rows. Although SQLite has had this on a branch for the better part of a decade, it's never actually been shipped to main. The second feature is Turso async. SQLite blocks the thread every time it touches the disk. With Turso, that operation hands control back instead of locking everything up. So your app can actually do other things while it waits. Then the third and probably most important feature nowadays is vector search. Every AI app needs a place to store embeddings and find the nearest ones fast. Usually what you do is just bolt on a separate vector database like Pinecone. But now you're running two databases with double the complexity. But Turso comes with native vector types and indexing built directly into the database. So your embeddings live in the same file as the rest of your data and you can query them with the SQL you already know. It's the exact trick Hip pulled 25 years ago where you take the thing that's needed in its own server and cram it into a library small enough to run everywhere. Except this time, the thing is your AI's entire memory. But doing more than SQLite is the easy part. The hard part is earning the trust that took 25 years to build. And to do that, you need to be a drop-in replacement and you need to never lose someone's data. And the drop-in part is basically done because Turso is already fully backwards compatible with SQLite. So you can swap it in without rewriting anything. But the never lose data part is harder. So to get there, Turso uses a pretty interesting testing strategy called deterministic simulation. What they do is run the entire database inside a simulated universe and play God with time, the network and the the Then they inject failures like power loss, mid-write, a corrupted page, or a disk that lies about whether it saved your data, and then replay the exact same scenario from the same random seed until they squash the bug. And because Turso is actually open source, anyone can contribute as you traditionally would. So, is rewriting the most trusted database on planet Earth actually a good idea? Probably not, but you're only viewed as an idiot until it works. And speaking of ideas that sound dumb until they work, what if your AI coding agent didn't set your money on fire? And that's why you need to know about JetBrains, the sponsor of today's video. Their Juni coding agent just graduated out of beta and is based on a very relatable idea. AI tokens cost too damn much, and so they made Juni completely model-agnostic and created a lever to decide what each task should cost. You can choose a cheaper model for routine work and a more expensive model for harder jobs. I used the Juni CLI to add role-based permissions to an existing admin dashboard, and I liked how the advanced plan mode creates a full stack in the Juni plans directory with your full project requirements, technical design, delivery stages, and tests. I used a stronger model for this planning phase, then switched to a much cheaper model to implement everything, and save myself a bunch of tokens. Juni just beat out every other coding agent in the most recent SWE rebench, and you can get 20 free AI credits when you use the code Fireship 20 at the link below. This has been the code report. Thanks for watching, and I will see you in the next one.