The Code Inside Everything (That Gets Zero Credit)

was the most used piece of software in human history. Windows, Chrome, iOS. No, there are over 1 trillion active SQLite databases on Earth right now. It's on every iPhone, every Android, every copy of Chrome, Safari, Firefox, every Mac, every Windows. If you have a phone in your pocket, you're running hundreds of SQLite databases at this very moment. and almost nobody knows what it is. How did the most important software on Earth become the most invisible?

It was the year 2000. The Y2K panic settled. The NASDAQ hits a record high during the dotcom boom. Tech could only go up from here, but not on the DDG79. Oscar Austin, a guided missile destroyer in Maine. One piece of software kept failing at the worst possible times. And Richard Hip was a contractor on that ship, — was contracted with Bath Iron Works, and Ba Iron Works was building DG79. They had a damage there was a damage control system. — Mhm. It's just an information system for the sailors so that you know if they take damage to the ship, you know, you need to be able to turn valves and circuit breakers off to isolate the damage and then turn others on in order to get — necessary support to critical systems. — But Richard wasn't a database guy. He had a PhD in computational linguistics and masters in electrical engineering. He ran a small consultant company with his wife out of Charlotte, North Carolina. She was the president and he was the head of research. During the 1990s, there were two extreme players in the world of enterprise databases. Oracle and Informix. And to say they were obsessed with beating one another is an understatement. Inform put a billboard outside of Oracle's headquarters saying Dinosaur Crossing, claiming they're old and frail. But all of that corporate warfare didn't matter much when the servers just stopped working. cannot connect a database server. — All the data to compute this was stored on an Informics database software that I wrote to solve this. You know, they double click on it to bring it up and if the Informics database engine down, I'd paint a dialogue box — database unavailable. And that would happen and they'd call me up and complain that my software broke and I'm thinking this is not a good situation. and I don't want to take the blame because some system administrator took down the database engine. — That's when Richard asked himself, — why do I need a separate process to store this data? Why can't I just read it directly from the disk myself? And that way if the machine is healthy enough that they can doubleclick on my application, it should be able to read the data, right? — But sadly, there were not many solutions. Remember, you couldn't just Google something around this time. Then someone Richard worked with said, "Why don't you just write one? " Richard did the thing that all programmers are guilty of. Added to his list of side projects to do eventually, of course. Well, eventually came sooner than expected. A government funding dispute shut down contracts across the country. And Richard was one of those casualties. To occupy his free time, he decided to work on that very project that he tried to find before, a SQL database that didn't need a server.

What if it was just a file? SQLite skips the server entirely. Your app opens a file on your disk and just reads the data directly. There's no middleman or dependency on an outside service. It's just one file. And just like that, SQLite was created. Then even better news, his contract renewed for the ship project and things will be easier this time. We have a SQL database that will make things 10 times easier. Well, unfortunately, the hype didn't last long and Formix was here to stay. But hey, maybe someone will find this useful for their small project online. So, Richard uploads SQLite to his own company's website under open- source software. That way, anyone can use it. Now, back to work. It didn't take long before people caught on what Richard actually posted online. The flexibility that a one file database provided had a ton of use cases. One of those posts would show the true potential of what SQLite can do. Someone was able to put SQL light on a Palm Pilot, a computer that can fit in your pocket. If you're in business, you had a Palm Pilot. One of the biggest limitations, no internet and only 2 to 8 megabytes of RAM. So, the fact that someone was able to put an entire SQL database onto it was revolutionary to say the least. The news group went crazy. Tinkerers start to download SQLite to try it out on their own projects. People would give their feedback and this made Richard continue working on it in his spare time. Emails, downloads, news groups. It was growing rapidly. And then a phone call.

It was Motorola. They'd seen what SQLite could do on devices like the Palm Pilot. They wanted it baked into their brand new mobile phone OS. Can you do that? Uh, sure. I'll get back to you tomorrow with a budget. Immediate panic. How do you price out a software that is open- source and free? How do does that even work? At the end of the day, there really isn't a way you can put a price on it. It's about the hard work and labor that goes into the $80,000. So, Richard brought on three other people he worked with to integrate SQLite into the new mobile phone operating system. Richard received the most money he'd ever received in his life by making free software. How does that work? It wasn't long before another call came in. This time, AOL. If you're too young to remember, AOL wasn't just an internet company. It was the internet back then. — Version 5. 0. You know, the easiest just got easier. — Plug it in and you're good to go. Even my grandpa can do it. AOL's got it all. — You've got mail, you've got pictures. — Every house in America would open up their mailboxes and see yet another free minute CD. And AOL wanted SQLite on all of those. SQLite would provide the benefits of having a database while taking only a tiny fraction of the space. If Motorola was a gamecher, then this was a lifecher. They flew Richard out to discuss contract specifics. During the negotiations, he decided to show off a feature that he was developing specifically for AOL. Temporary indexes. It's like a shortcut for finding data faster. Instead of the database scanning through every single row, the index tells it exactly where to look. Except this was temporary. It exists while you need it and disappears when you don't. As this was being presented, Richard realized something crucial mids sentence. It's completely broken. If one user creates a temp index and another user updates the table, well, the index goes stale. He just bragged about a feature that was completely broken. But nobody noticed. Hopefully. Motorola AOL. Richard's side project was becoming a real business.

But the call that would change everything came from London. Symbian, the operating system that powered Nokia, the biggest phone company on the planet at the time. They wanted Richard to fly out and meet with them. Thanksgiving Day, Richard landed in London and was surprised by what they told them. — They told me that they had a bake off. All nine other than me all had the opportunity to tune their database for the operating system. They had a big bake off and I won. — Mhm. And I didn't even know this was happening. They had 10 different database engines. And this is them telling me I have no personal knowledge. The other nine, seven of them were closed priority. But Symbian had one concern. They called it the bus factor, as in how many people have to get hit by a bus before this project dies. It probably sounded nicer on paper. For SQLite, that number was way too low. So, Richard tried to set up a consortium, a formal structure where companies could fund SQLite's development and guarantee its longevity. Something we see to this very day. He put together this whole plan. Voting rates for members, corporate governments, the works, the boring stuff. But then his phone rang again. It was Mitchell Baker, the head of the Mosilla Foundation, a lawyer by training. She said that he was doing everything wrong. The developers make all the decisions. The companies get the honor of contributing money. No voting rights on what goes into the code. No corporate governments over the technical direction. The developers are in control. Period. But how did they get people to join under those conditions? And that's why Mitchell pledged Mozilla being a founding member of the consortium. Sure enough, Symbian, Mozilla, and Adobe became the founding members of the SQLite consortium. The project finally had financial backing. But here's the thing, the consortium funded the project. It didn't open it up. Richard didn't start accepting code from the public. He didn't even put it on GitHub. He didn't invite contributions. The money came in, but the code stayed closed. The whole world could depend on SQLite. But SQLite would not depend on the whole world. Every line of SQLite would continue to be written by the people who understand the entire system. That was the deal. That was always going to be the deal. And by the mid200s, all major smartphones were running SQL light. Richard had seen early phone development from every angle. Motorola, Nokia, Symbian. Then in 2005, Google called.

They were working on a prototype phone. It had a full keyboard at the bottom and a small screen at the top like a BlackBerry. They were debugging SQLite on the phone and had it connected to a workstation, running a full debugger on a mobile device. Nobody else could do that. But then the phone actually rang. An actual phone call on the prototype. The engineer looked at it and answered. Richard played it cool, but inside his mind was exploding. They were debugging software on a phone that was connected to the public cell network. Motorola couldn't do that. Nokia couldn't do that. They were still using breadboard prototypes that couldn't even make calls. This early prototype was where Android first started. In that moment, Richard knew Android was going to be huge and he couldn't tell anyone. Not Motorola, not Symbion, not Nokia. He just had to watch it happen. Android launched. SQLite shipped on every single device. Millions of phones, then tens of millions, then hundreds of millions. But that's when the bugs started showing up. They were getting crash reports constantly. The scale had exposed every edge case, every assumption, every corner they never tested. The thing that worked perfectly for years was suddenly breaking everywhere. A small team drowning in bug reports from millions of users on the world's fastest growing platform. What now? Being such a small team, they

could have folded. But instead, Richard did something kind of insane. Around the same time he'd been doing work for Rockwell Collins, an avionics manufacturer. They introduced him to DO178B, a quality standard used for safety critical aviation software, the stuff that makes sure planes don't crash. So, pretty secure. Richard decided to hold SQLite, a free open-source database, to the same standard as commercial flight software. He spent an entire year, 60-hour weeks, 12-hour days, every single day writing tests to achieve 100% MCDC coverage. That's modified condition decision coverage at the machine code level. Every single branch in the compiled binary had to be tested both ways. 155,000 lines of source code, 92 million lines of tests, a 590 to1 ratio. Before every release, they ran billions of individual test cases across multiple operating systems, multiple architectures for at least 3 days straight. — What I did find is when I tested the do 178b level, the bugs just largely went away. — And like how many would you get? Like how much was it like from the start versus after? — I don't have hard numbers for you, but it got to the point we just didn't hear from them. — Right. So, it was kind of like, you know, you got so many a day to like almost like you'd wake up to it to like you wouldn't hear from them for a couple weeks or something. One year of brutal grinding work and then near silence for almost a decade. Growth didn't stop. If anything, it was rising at a much more rapid pace. Android kept growing. The iPhone launched and shipped with SQLite. Every browser adopted it. Every major operating system bundled it. The Airbus A350 runs it. WhatsApp stores every message you've ever sent in it. Your iMessage, your Spotify library, your Dropbox sync, Adobe Photoshop, Skype. There are now more active SQLite databases on Earth than there are human beings. And throughout all of this, Motorola, AOL, Symbian, Google, the Android Crisis, the team never got big. Dan Kennedy, an Australian developer living in Southeast Asia, joined in 2002. Joe Mstachkin came on too and that was it. Three people, a trillion databases, and they weren't hiring. Let's just sit with that for a sec. MongoDB, a database with a fraction of SQLite's deployment, went public at $4 billion valuation. Snowflake IPOed at 33 billion. Reddis Labs raised 350 million. Hundreds of engineers, thousands, massive campuses, billions in funding. Richard never took a dollar of VC money, never IPOed, never been acquired. He still runs the same small company with his wife in Charlotte, North Carolina. She's still the president, and he's still the head of research. So, how does a threeperson team maintain something this massive? How does that even work?

It works because nobody else is allowed to touch it. SQLite does not accept much outside contributions. It hasn't for its entire existence. You can copy it, sell it, modify it, but you cannot contribute code to it. But why? Because SQLite is public domain, not MIT license, not Apache, not GPL, no license at all. And to keep that status bulletproof, every single line has to be clean. If even one of the copyrighted code gets in, the entire public domain status could be challenged. The first version of SQLite used GDBM, a GPL license. If he'd kept it, SQLite would have been locked into the GPL forever. it could never have shipped on the iPhone or Photoshop or the Airbus A350. So, he rewrote the storage engine from scratch when he needed the algorithm he pulled the art of computer programming off his shelf and built it. Except the book only described searching and inserting into a B tree, deleting an exercise for the reader. So, Richard had to solve the homework before he could build the database. He wrote his own parser generator, his own version control, his own bug tracker, even his text editor. Every dependency avoided was a future crisis prevented. — Why do I need to write all these test programs to understand somebody else's code when I can write my own, right? So I did and that was extraite version two. When I did that, I I dropped this dependency on GDBM and I could choose any license I want. Years later, SQLite's architecture independently converged on the same optimizations as Postgress SQL, a database built by the entire teams at Berkeley. Everything, the architecture, the history, the reasoning behind every decision lives in three people's heads. SQLite might be the most extreme version of that in computing history. Three people, a trillion databases, and they don't accept help. So, what kind of person looks at all of this and puts a prayer where the license should be?

In 2018, the open source world was going through a major wave. Every major project was adopting a code of conduct community guidelines for how contributors and maintainers should behave. It was becoming expected in every open- source project. So the pressure of course came to SQL light. Richard submitted the rule of St. Benedict, a 1500year-old set of rules written for monks. It included guidance like prefer nothing more than the love of Christ and be not addicted to wine. And the internet did what the internet does. outrage, confusion, hot takes, think pieces. — Why a prayer instead of a license? — Uh oh. A prayer rather than a license. — Yeah. — All right. So, this was in um — SQLite. It was just the SQL parser and it used GDBM. Version one of SQLite was GPL. It had to be but no option. GDBM is a it it's a hashing store and I I wanted to be able to um do range queries and for that you need a B tree or something like that and so I said well I'm going to change the back end to something different. I looked at Berkeley DB the documentation of Berkeley DB was such that uh I recognized I'm going to have to write test programs to understand how it actually work. So I thought hey I'll just write my own why not. Richard's response, he added Mosilla's community participation guidelines as the official code of conduct for external interactions. Fine, done. And he renamed the rule of St. Benedict to a code of ethics, the internal standard the developers hold themselves to. But the whole incident pulled back a curtain on something that had always been there. Where every other piece of software has a license file like the MIT, the Apache, the GPL, SQLite has this at the top of every single source file where the copyright notice should be. May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give. — At that time, there were really there was the GPL, there was the Berkeley license, and there was the um MIT license. That was it. We didn't have five billion different licenses like you do today, — right? — And I looked at the MIT and Berkeley, and you know, they're I mean, they're really open and everything. They're great, but there's a bunch of legal ease and all of this stuff in it. Why do we need any of this? What is the point of this? Why can't it just say public domain and be done with it? I wrote every line of code this myself. Let's just call it public domain. And I needed something to put in the header comment. So, I came up with that cheesy blessing. So, I did it that way. You know, would I do it differently knowing then what I know now? Perhaps, but it's worked out. a blessing, a prayer where a legal document should be. It's been there since the beginning. And this is who Richard Hip is, a devout Christian from Charlotte who put a prayer in his source code and a monistic rule in his code of ethics. And the entire tech industry just depends on it. But here's the thing about building a fortress. The same

walls that keeps threats out also keeps progress in. In December of 2018, the same year Richard submitted the rule of St. Benedict as his code of conduct. A security team at Tencent discovered a vulnerability in SQL light. They called it Maggalin, a remote code execution flaw and FTS3 extension that theoretically affected every Chromiumbi based browser on Earth. Billions of devices. Richard's team patched it before Tencent even went public. The system worked. But then Richard got on Twitter and called the reports greatly exaggerated. He accused the researchers of being motivated to spin it as a bigger deal than it was. And he was probably right. There's no evidence that Megalin was ever exploited in the wild. But the image it painted, a threeperson team publicly waving off security researchers from one of the biggest tech companies in the world made a lot of people uncomfortable because there was a pattern forming. Companies asked for a code of conduct. Richard gave them a 1500year old rule and only added standard guidelines after the backlash forced his hand. Symbian raised the bus factor 20 years ago. still three people. He built the TH3 test suite partly hoping to sell it to avionics companies. They've sold exactly zero. The engineering was flawless, but the world around SQL light kept changing. And Richard's answer to every outside concern was the same answer it had always been. I've got this. He'd even say it himself in interviews. Meanwhile, developers were building applications that SQLite was never designed for. edge computing, serverless functions, AI workloads that need vector search and replication features that the closed contribution model meant they couldn't add and couldn't even propose. Now, it's worth saying something here. SQL light isn't completely closed to contributors. That's a common misconception. Apple has contributed code. Google has contributed. But every contribution requires meetings with lawyers, signed affidavites, documents stored in a fire safe at the office. It's not that outside code can't get in. is that the friction is so high that most people just don't even bother trying. And for a lot of developers, they did try. One project called DQite tried to contribute replication code directly to SQLite. The answer was just no, not going to happen. Globber Costa

had seen what he called a pile of bodies, people who tried to contribute SQLite and failed. Costa was the CEO of a startup called Terso. He and his co-founder Pekka and Berg had spent years in Linux kernel development where the entire culture was built on open contribution. Lionus Torva said Linux would never run on anything but his PC and then 30 years of community contributions made it run on everything. Kosa and Nberg were building a product that depended heavily on SQLite. They needed to modify it, add replication, server mode, things SQLite wasn't designed to do and they just couldn't. So in October of 2022, they made a decision. They forked Siboite. But they didn't write a single line of new code. Not one. They sat down and asked themselves, "What is the minimum amount of code that we need to write to prove this is worth doing? " And after a few days of deliberation, they had their answer, zero. They wrote a manifesto instead, a letter that said, "SQLite is open source, but does not accept contributions. Community improvements cannot be widely enjoyed. We want to change that. In 2 weeks, they had 1,500 GitHub stars. Their previous product, a year of actual engineering work, had 1,000. This thing with no code changes, had 50% more interest in 14 days. And the community had been waiting for someone to do this. They just needed someone to go first. Within a year, over 80 contributors, a proper code of conduct, an MIT license, native replication, vector search baked directly into the SQL engine, everything Richard deliberately chosen not to do. And Kosa was clear. He wasn't angry at Richard. He wasn't trying to take something from him. Two different traditions, two different answers to the same question. But Terso didn't stop at a fork. In 2024, they announced they were rewriting SQLite entirely from scratch in Rust, a memory safe language. Not building on Richard's code anymore, replacing it. A clean room implementation with no ties to the original architecture. A fork still depends on the original. A rewrite depends on nothing. They wanted to control their own destiny. So now there are two versions of this story. a man in Charlotte who spent 25 years building something by hand. Who refused outside help because every time he depended on someone else's work, it nearly cost him everything. Who was right about architecture, testing, about keeping the team small, who put a prayer in his source code and pledged to support it until 2050, which would make him 89 years old. and a team of engineers who looked at the same man and saw with real justification that depending on him was the risk that the fortress that he built to protect SQLite had also frozen it in place that the stubbornness that made it great was the stubbornness that wouldn't let it evolve. Richard never responded publicly, not to the manifesto, not to the fork, not to the rewrite. The most he ever said about the possibility was years earlier in a podcast interview. No lawsuit, no angry blog post, no defensive Twitter thread, just silence and permission he'd given in advance because that's the whole point of public domain. That's what the blessing says. May you share freely never taking more than you give and

someone finally took him up on it. Everybody's doing this all the time because we're apparently the king of the hill. We're the ones to knock off. Every morning I wake up and I'm thinking, well, this will be the last day. Somebody's going to come up with something better than SQLite. and the ride will be over. But it just keeps going. — I'm going to keep doing this as long as I'm able to. The manifesto talks about how we need um you need to develop software according to the GitHub model. If you're not doing it this way, you're doing it wrong. Turns out I get to choose how I do it myself. You know, how I write my own software. And that's not the way I want to do it. And if you want to do it that way, that's fine. I enjoy doing this. And I don't think it would have been enjoyable if I'd spent all my days trying to deal with pull requests. Suppose you have a pull request for SQ. Hey, I got this new feature for SQLite. Here's the pull request. When you're wanting me to pull that into the tree, you want me to maintain it for you, to document test it for you, and to maintain it for you for the next 25 years. Lennis Torvall is f famous for saying, you know, there's free as in beer and free as in speech, but there's another kind of freedom. Free as in puppies. Well, look, I've got a free puppy for you. Okay. Yeah. Yeah. — Do you see where this is going? A pull request is a free puppy. — Yeah. — And then you just got a kennel at the end of the day full of puppies. Yeah. You're just like, — "Yeah. " And you can't just throw them out. Okay. They're you you're morally obligated to take care of them for their natural life. — Yeah.

— I know. I don't want any free puppies. — The USS Oscar Austin was commissioned in the year 2000. The same year Richard Hip wrote the first version of SQLite during a government shutdown. The Navy insisted on keeping Informix, the software that was supposed to use SQLite never officially did. The side project that a contractor built out of frustration with a crashing database on a warship ended up on every phone, every browser, every plane, and every device that you touched. And the guy who built it, he never left Charlotte. No logo, no conference, three developers. a blessing where everyone else puts a license and a trillion databases that nobody thinks about. And then he went back to work. Subscribe if you want more stories like this. I'll leave links to all the podcast interviews with Richard and all the other sources in the description. They're worth your time. And thank you again to Richard for talking with me for about an hour. Um, the full podcast interview is down below if you want to go see it. Thank you so much.