The Untold Story of SQLite | CoRecursive Podcast
CoRecursive #066<br>The Untold Story of SQLite<br>With Richard Hipp<br>Listen Now<br>Podcast Player
On today’s show, I’m talking to Richard Hipp about surviving becoming core infrastructure for the world. SQLite is everywhere. It’s in your web browser, it’s in your phone, it’s probably in your car, and it’s definitely in commercial planes. It’s where your iMessages and WhatsApp messages are stored, and if you do a find on your computer for *.db, you’ll be amazed at how many SQLite databases you find.<br>Today, Richard is going to share his story. It’s the story of creating a small open source project and having it grow beyond your wildest ambitions. It’s the story of following that success wherever it leads: From relationships with tech-giants to interesting testing procedures and more.
Guest<br>Richard Hipp<br>Homepage
Table Of Contents
Transcript<br>Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that's not on the pageWhen Your Side Project Powers the World<br>Adam: Hello and welcome to CoRecursive. I’m Adam Gordon Bell. Each episode of CoRecursive, someone shares the fascinating story behind some piece of software being built. On April 1st, 2014, an open source maintainer got an email from Google about a security issue, and this was not an April Fool’s joke. This was HeartBleed and the project was OpenSSL. 17% of the world’s web servers were affected, and by the time the dust settled, people started asking questions like, “Why was this open source maintainer who received only $2,000 in donations a year responsible for 17% of the world’s encrypted web traffic?”<br>Ever since then, I’ve been curious about these critical pieces of infrastructure. What happens if your fun side project ended up powering the world? Do you try to monetize it? Do you focus on it full time? Does the weight of the maintenance crush you and you just leave computers and go to focus on building furniture? I have a purpose guest for discussing this topic.<br>Richard: I’m Richard Hipp and I work on SQLite.<br>Adam: Today’s show, I’m talking to Richard about how to survive becoming core infrastructure for the world. SQLite is everywhere. It’s in your web browser, it’s in your phone, it’s probably in your car, and it’s definitely in commercial planes. It’s where your iMessages and WhatsApp messages are stored, and if you just do a find on your computer for *.db, you’ll be amazed at how many SQLite databases you find. Today, Richard is going to share his story. The idea for SQLite actually came out of his frustrations with an existing database called Informix that was installed on a literal battleship.<br>When the Database Goes Down at Sea<br>Adam: Richard was a contractor for Bath Iron Works working on software for the DDG-79 Oscar Austin. That is a battleship, the type that protects a fleet by being armed to the hilt.<br>Richard: There’s a big, complex ship, and stuff’s always breaking. Suppose a pipe ruptures. You need to isolate that damage by closing valves on either side of the pipe, but then you also need to open valves elsewhere to restore the working fluid to other systems that are downstream so that they don’t go offline, and locating all those valves and whether you open them or close them can get very complicated, and so Automated Common Diagrams is a program that says, “Oh, here’s the problem. Here’s the valves you close. Here’s the valves you open. Here’s where they’re located.”<br>That was the original problem, and all the data for where all the pipes are running and all the valves are located, that was in the database. The computer was already installed on the ship. We didn’t have any control over that. The database was already installed on the ship. We didn’t have any control over that. We just had to use what was there.<br>Adam: Richard was brought in because the solution to this problem was computationally complex and Richard was known for solving hard problems.<br>Richard: Really, when you come right down to it, the types of systems that are designed by humans tend to be solvable in polynomial time. It’s just, the general description of the problem, where you have an arbitrary directed graph, is NP-complete, so, they were trying to write code that would solve this, and they hadn’t analyzed it and they didn’t realize this. They were, “You know, we’re not getting a solution. It’s just running forever and chewing up CPU cycles. What’s going on?” Well, that’s because it’s in NP-complete, and so you have to use heuristics that will find fast approximate solutions and put lots of things in there to verify that it’s not stuck in a loop somehow, and...