Richard Hipp Wanted a Database With No Server to Go Down. SQLite Now Runs Almost Everywhere.

In 2000, D. Richard Hipp was writing damage-control software for a U.S. Navy guided-missile destroyer, the DDG-79 Oscar Austin, as a contractor on a Bath Iron Works project. The application stored its data in an Informix database that ran as a separate server. When that server was unavailable, the software could not work. Users saw an error dialog saying it could not connect, and the application team took the blame.

Hipp’s reaction became one of the most consequential design questions in modern software: why does a program like this need a database server at all?

A database that is just a library

Most databases of the era followed the client-server model. A database engine ran as its own process, often on its own machine, and applications talked to it over a connection. That architecture is excellent for many shared, multi-user systems. It also creates a dependency. If the server, the network, or the configuration fails, the application fails with it.

Hipp’s alternative was to put the SQL engine inside the application. There would be no server process to install, start, administer, or lose contact with. The program would read and write an ordinary file on disk, using a library linked directly into its own code.

A gap in government funding left Hipp without contract work for a few months, and a colleague suggested he simply write the engine he kept describing. According to Hipp, the first code was checked in on 29 May 2000. The first public release followed in August 2000. That early version stored its data with GDBM, the GNU database manager. SQLite 2.0, released in 2001, replaced GDBM with Hipp’s own B-tree storage layer and added transactions.

Why public domain mattered

Because version 1.0 depended on GDBM, it effectively came under the GPL. When Hipp wrote the replacement storage engine, he chose not to use any open-source license at all. SQLite’s code and documentation were dedicated to the public domain.

That decision lowered the barrier for companies to an unusual degree. A manufacturer could ship SQLite inside a phone, a browser, or a car system without negotiating a license or tracking attribution clauses. For organisations whose lawyers want a formal document anyway, Hipp’s company, Hwaci, sells a “Warranty of Title,” a legal assurance that the authors had the right to dedicate the code to the public domain. The money supports development. The code itself stays free.

From a side project to phones

The first serious commercial interest came from the mobile industry. Hipp has recalled that Motorola called around 2001 or 2002 about using SQLite in a phone operating system, and that he quoted roughly 80,000 dollars, a figure that felt like everything to him at the time. AOL wanted it as well. Symbian later compared a group of database engines for its mobile platform and chose SQLite.

Symbian then raised a serious concern: a project maintained by so few people had a low “bus factor.” The answer was the SQLite Consortium. On advice from Mitchell Baker of Mozilla, it was structured so that members fund development while the developers keep control of the code. Mozilla, Symbian, and Adobe were among the founding members.

Around 2005, Hipp saw an early prototype of Android during a debugging session. He later said he knew the platform would be huge. Android went on to put SQLite on every device it ran on.

Learning to test like an airplane

Widespread deployment exposed a different problem: bugs reached millions of devices. The turning point came through Rockwell Collins, which introduced Hipp to DO-178B, a standard used for safety-critical aviation software. Among other things, it demands 100 percent MC/DC test coverage, meaning every condition in every decision is shown to independently affect the outcome.

Hipp spent about a year of long weeks bringing SQLite’s tests to that level. He has said that afterwards, the bug reports from Android essentially stopped.

The testing culture remains SQLite’s most striking feature. The project’s own documentation says that, as of version 3.42.0, the library was about 155,800 lines of C, while the tests and test scripts amounted to roughly 590 times as much code. The suites deliberately simulate out-of-memory errors, I/O failures, crashes, and power loss in the middle of writes, then check that the database file was not corrupted.

How far a small idea travelled

The SQLite project describes itself, with careful hedging, as likely the most widely deployed database engine. Its documentation lists every Android and iOS device, every Mac and Windows 10/11 installation, and the major web browsers among its users. It estimates that there are probably over one trillion SQLite databases in active use. That number is an inference from the number of smartphones, not a measurement, but even as a rough estimate it puts SQLite among the most widely used software components in the world.

The engine is not a replacement for client-server databases in every case. Large, highly concurrent, multi-user systems still have good reasons to run a dedicated server. SQLite’s own documentation makes that point. Its strength is different: for the enormous number of applications that need reliable structured storage on a single device, the most robust server turned out to be no server.

The design lesson

Hipp did not set out to build the world’s most common database. He set out to remove one failure mode from one shipboard application. The lasting idea was to treat a dependency as a liability before treating it as a feature.

Many software problems are solved by adding a component: a cache, a service, a queue, a server. The SQLite story is a reminder that sometimes the more durable move is to ask which component can be taken away, and then to test what remains as if lives depended on it.

Explore

Stay connected