SQLite, three developers, and a trillion databases

Source: The Code Inside Everything (That Gets Zero Credit), Coding with Lewis, 29:06, uploaded 2026-04-30, playlist index 52.

Coding with Lewis opens with a scale problem. The video puts the number of active SQLite databases above one trillion, spread across phones, browsers, operating systems, planes, and the applications that sit on top of them. A phone may run hundreds of SQLite databases at once. The software remains almost invisible because it has no consumer-facing product and rarely asks its users to notice it.

The story begins on a guided missile destroyer in Maine and ends with a question about who gets to maintain software that the rest of the world has quietly built into everything.

A database for a ship that had to keep working

In 2000, Richard Hipp worked as a contractor for Bath Iron Works, which was building the USS Oscar Austin, the DDG-79. The ship’s damage-control system gave sailors the information they needed to isolate damaged parts of the vessel by switching valves and circuit breakers. Hipp had a PhD in computational linguistics and a master’s degree in electrical engineering. He ran a small consultancy in Charlotte, North Carolina, with his wife, who served as president whilst he led research. Database administration was not his field.

The consultancy used Informix, one of the large enterprise databases competing with Oracle during the 1990s. The rivalry had the usual corporate theatre, including an Informix billboard outside Oracle’s headquarters that read “dinosaur crossing”. The joke stopped working when the database server stopped working. Hipp’s application would open a dialogue box saying that the database was unavailable, and the users would call to say that his software had broken. The actual failure sat in the separate Informix process, yet the application on their screen received the blame.

Hipp wanted the application to read its data from disk without relying on a separate database server. If the computer could run the application, it should be able to read the file that contained its data. In 2000, finding a ready-made answer meant more than entering a search into Google. Someone suggested that Hipp write the database himself, and he placed the project on the side-project list that programmers keep acquiring.

A dispute over government funding shut down contracts across the country and left Hipp with time to work on it. He built a SQL database that needed no server. SQLite would open a file on the local disk and read the data directly. The application had no database process to contact and no outside service to fail. The first version was a response to a damaged control system and a frustrating error message.

The Navy contract returned, and the ship project kept Informix. Hipp uploaded SQLite to his company’s website under an open-source label so that other people could use it. The first useful surprise came from the PalmPilot. A PalmPilot had no internet connection and only two to eight megabytes of RAM, yet someone managed to put an entire SQL database on the small device. People began downloading SQLite, trying it in their own projects, and sending feedback. That feedback kept the side project alive.

Free software becomes a commercial service

Motorola called after seeing what SQLite could do on small devices. The company wanted to put it into a new mobile-phone operating system and asked Hipp for a budget. The question exposed an awkward business model. A free, open-source database had no obvious licence price, so Hipp priced the work that would integrate it into the phone. He brought in three people he had worked with and received, by his account, the largest payment of his life for making free software.

AOL followed. At the time, AOL’s installation discs reached homes across the United States, and the company wanted SQLite on all of them. SQLite supplied database functions whilst taking very little space. During negotiations, Hipp demonstrated temporary indexes, which help a database find rows without scanning the entire table. He realised as he explained the feature that it was broken. If one user created a temporary index whilst another user changed the table, the index could become stale. Nobody in the room appeared to notice the problem, and the feature survived the demonstration.

The next call came from London. Symbian, then the operating system behind Nokia’s phones, had run a bake-off between ten database engines and SQLite had won. Hipp had not known that the test was happening. Symbian’s concern was the bus factor: how many people could disappear before the project stopped functioning. SQLite’s answer was too small for comfort.

Hipp tried to form a consortium with voting rights, corporate governance, and a formal structure for funding future development. Mitchell Baker, then head of the Mozilla Foundation, told him that the companies should supply money whilst the developers kept control of the code. Mozilla, Symbian, and Adobe became founding members of the SQLite consortium. The consortium gave the project financial backing without opening the code to public contributions.

A small team inside every phone

By the middle of the 2000s, major smartphones ran SQLite. In 2005, Google showed Hipp a phone prototype with a full keyboard and a small screen. The engineers were debugging SQLite on the phone from a workstation when the prototype received a real call over the public cellular network. Motorola and Nokia were still working with prototypes that could not make calls. The phone became an early version of Android, and SQLite shipped with Android when it launched.

The scale turned old assumptions into crash reports. Millions of phones became tens and then hundreds of millions, exposing edge cases that had stayed hidden during years of smaller deployments. Hipp was also working with Rockwell Collins, which introduced him to DO-178B, a standard for safety-critical aviation software. He decided to test SQLite to the same level.

Hipp describes a year of twelve-hour days and sixty-hour weeks spent writing tests for 100% modified condition and decision coverage at the machine-code level. The version of the figures used in the video gives SQLite about 155,000 lines of source code and 92 million lines of tests, a ratio of roughly 590 to one. Before a release, the team ran billions of test cases across operating systems and hardware architectures for at least three days. Hipp says that the bugs largely disappeared after they adopted this testing discipline. He cannot give the interview a before-and-after count, though he remembers the regular stream of reports falling close to silent for almost a decade.

SQLite continued to spread. The video names the iPhone, web browsers, operating systems, the Airbus A350, WhatsApp, iMessage, Spotify, Dropbox, Photoshop, and Skype as users or products that rely on it. Lewis presents the resulting scale as more active SQLite databases than human beings. The team stayed small. Dan Kennedy joined in 2002, Joe Mistachkin followed, and the three developers maintained the project from the same small company in Charlotte. They did not take venture capital, go public, or sell the company.

The comparison with other database companies makes the choice look strange. Lewis gives MongoDB’s public valuation as four billion dollars, Snowflake’s IPO as thirty-three billion dollars, and Redis Labs’ funding as 350 million dollars. Those numbers are figures reported in the video, not a current market comparison. The point is the difference in organisational shape: SQLite reached an enormous deployment without the large team, campus, or funding round that usually accompanies a widely used software product.

Public domain and the cost of outside code

The video attributes the three-person team partly to a strict rule about who can change SQLite. People can copy it, sell it, and modify their own versions, while the core project accepts very little outside code. Hipp describes SQLite as public domain rather than MIT-, Apache-, or GPL-licensed. To protect that status, every line must have a clean provenance. A dependency with an incompatible copyright or licence could create a legal problem for software that ships inside phones, browsers, and aircraft.

The first SQLite used GDBM, a GPL-licensed library. Hipp replaced it with a storage engine that he wrote himself so that SQLite could have a different licence. He needed a B-tree with deletion as well as search and insertion, whilst the reference he consulted, Donald Knuth’s The Art of Computer Programming, left deletion as an exercise. He wrote the missing algorithm, then went on to write his own parser generator, version-control system, bug tracker, and text editor. Each dependency removed a future testing and maintenance obligation. His reasoning was simple: if he had to test somebody else’s code, he could write the code himself and test it directly.

This approach produced an unusual concentration of knowledge. The architecture, the history behind it, and the reasons for its decisions remain with the three developers. The video says that SQLite eventually arrived at some of the same optimisations as PostgreSQL, whose development involved a much larger community. A small team can preserve a complete view of a system when it controls every line. It also creates a single place where history and judgement can be lost.

In 2018, the open-source world expected projects to publish codes of conduct. Hipp answered with the Rule of Saint Benedict, a roughly 1,500-year-old set of rules for monks that includes guidance about wine and the love of Christ. The choice provoked the predictable internet response: confusion, outrage, and arguments about why a prayer had taken the place of a software document. Hipp later used Mozilla’s community participation guidelines for external interactions and called the Benedictine text his developers’ code of ethics.

The same impulse appears in SQLite’s source files. Where another project might place a copyright notice or licence, SQLite carries a short blessing asking that its users do good, forgive one another, and share freely. Hipp says he needed something for the header comment after deciding that a plain public-domain statement was enough. He calls the blessing “cheesy” in retrospect and says that it has worked.

The fortress and its cracks

The closed contribution model also limits how quickly SQLite can respond to demands that arrived after its original design. In December 2018, a security team at Tencent found a remote-code-execution vulnerability in SQLite’s FTS3 extension. The video calls it Megalin and says that it theoretically affected every Chromium-based browser, which would have put billions of devices in its reach. Hipp’s team fixed it before Tencent made the discovery public. Hipp then described the reports as greatly exaggerated. The video adds that it has found no evidence that the vulnerability was exploited in the wild, whilst showing why his public response made researchers uneasy.

Other concerns accumulated. Symbian had raised the bus-factor problem years earlier, and SQLite still had three developers. Hipp’s extensive testing framework had partly been built with avionics companies in mind, yet the team sold none of it. At the same time, developers were using SQLite in edge computing, serverless functions, and AI systems that wanted replication and vector search. A project that controls its own boundaries can keep the system coherent, though it also makes new features difficult to propose.

The boundary has exceptions. Apple and Google have contributed code, according to the video, though each contribution requires meetings with lawyers, signed affidavits, and documents kept in a fire safe. Outside code can enter SQLite through a long process. The process itself discourages most people from starting it.

Turso’s fork and clean-room rewrite

Glauber Costa, the CEO of Turso, had spent years in Linux kernel development with his co-founder Pekka Enberg. Their work depended on SQLite, yet their product needed replication and a server mode that SQLite had never been built to provide. In October 2022, they forked SQLite. They began by writing zero new lines of code. Instead, they published a manifesto saying that SQLite was open source whilst declining contributions, which meant that community improvements could not reach the main project.

The manifesto gained 1,500 GitHub stars in two weeks. Costa’s previous product had taken a year of engineering work to reach 1,000 stars. The response suggested that many developers had been waiting for a project to make the first move. Within a year, the fork had more than 80 contributors, a code of conduct, an MIT licence, native replication, and vector search inside its SQL engine. Those are the features the video associates with the limits of Hipp’s model.

Turso then chose a harder break. In 2024, the company announced a complete rewrite of SQLite in Rust, a language with memory-safety guarantees. A fork remains tied to the original architecture. A clean-room rewrite lets its authors control the new system without depending on Hipp’s code. The video presents this as a second answer to the same maintenance problem rather than as a personal quarrel. Costa is clear that he does not want to take SQLite away from Hipp. He wants a project whose future does not depend on one small team.

The two positions have real force. Hipp spent twenty-five years building a system that survived because he kept its boundaries firm. He pledged to support it until 2050, when he would be 89. Costa and Enberg looked at the same success and saw dependence as the risk. Hipp has not publicly answered the manifesto, the fork, or the rewrite. His silence fits the permission already built into the public-domain decision: the work can be shared, modified, and replaced.

Hipp says he wakes up expecting someone to build something better than SQLite and end its run. He keeps working because that day has not arrived. He also rejects the idea that software development must follow the GitHub model. A pull request brings code together with a long-term obligation to maintain, document, test, and support it for the next twenty-five years. He describes each unsolicited contribution as a free puppy that eventually fills the kennel and still needs care.

Limits of the account

The video is a documentary reconstruction built from Lewis’s narration and an interview with Hipp. Its figures for SQLite’s deployment, test volume, code-to-test ratio, corporate valuations, funding, contributor counts, and the Megalin vulnerability remain claims made in the source. The captions and description provide no underlying reports, release data, legal analysis, or market records for those claims.

The testing account comes from Hipp’s memory, and the video does not show the test suite or independently establish its coverage. The Megalin section gives a clear qualification: the vulnerability was patched before public disclosure, and the video reports no evidence of exploitation in the wild. The account also leaves the legal status of the public-domain blessing at the level of Hipp’s explanation. It describes why he avoids dependencies and outside code without settling the wider legal questions around software provenance.

The closing image remains deliberately unresolved. SQLite’s discipline made it dependable enough to disappear into a trillion deployments. The same discipline made the project hard to extend and left its future concentrated in three people. Turso’s fork and rewrite show that public-domain permission allows a community to build a different answer. They do not show yet whether that answer will earn the same quiet reach.

Further reading / references

• Full interview with Richard Hipp, linked in the video’s description.
• Donald Knuth, The Art of Computer Programming, cited by Hipp when he rebuilt SQLite’s storage engine.
• DO-178B, the aviation software standard Hipp names as the model for SQLite’s testing discipline.