SQLite 1.0 — An SQL Database With No Server

On 17 August 2000, D. Richard Hipp released version 1.0 of a small library called SQLite. The project's change log marks 1.0 with a single entry: the sqlite shell program could now read databases for which it lacked write permission. There was no launch. A quarter of a century later, sqlite.org's estimate is that over one trillion SQLite databases are in active use.

The idea behind it ran against everything else on this timeline up to that point. From System R and Oracle to MySQL and PostgreSQL, an SQL database was typically a server: a dedicated process that applications connected to. SQLite put the whole engine inside the application.

A Destroyer and an Informix Server

Hipp has told the origin story himself, in an interview on the CoRecursive podcast. He was a contractor for Bath Iron Works, working on software for the guided-missile destroyer DDG-79, Oscar Austin. The software dealt with damage control — when a pipe ruptures, working out which valves to close to isolate it and which to open to keep the ship running — and it read its data from an Informix database server.

When Informix was working, it worked well. But sometimes the server went down, and then the application could not run. The operators saw a dialog that said "Can't connect to database server," and, as Hipp put it, the team got the blame all the same because they were the ones painting the dialog box.

The application was not doing transactions; it was pulling a body of data into memory to solve a problem. That raised the question Hipp says he asked: "Why do we even need a server? Why can’t I pull this directly off the disk drive?" He looked for an SQL engine that worked that way and found none. A colleague suggested he write one.

The 2022 VLDB paper on SQLite, co-written by Hipp, gives the same origin in one sentence: SQLite "was born out of the frustration of debugging a database server running in a separate process."

How It Was Built

Hipp did not start right away. By his account, a hiatus in the project's government funding in 2000 left him out of work for a few months, and he used them to write the engine. He approached it as a compiler problem, drawing on earlier experience building compilers: treat each SQL statement as a program, write a bytecode engine that can execute a query, and write a compiler that translates SQL into that bytecode.

The change log shows how quickly it came together:

SQLite 1.0 was not quite the SQLite of today. It was originally packaged as an extension to the Tcl language, and it stored its data through GDBM, the GNU database manager — the change log has VACUUM calling gdbm_reorganize().

The SQLus Detour and Version 2.0

The change log also preserves a plan that did not happen. Version 1.0.32, on 23 July 2001, removed a pager and B-tree subsystem from SQLite with the note that they would be used in "a follow-on SQL server library named 'SQLus'." Two months later the plan was reversed. The entry for 2.0-alpha-2, on 20 September 2001, says the idea of renaming the library to SQLus was abandoned in favor of keeping the SQLite name and bumping the major version number.

That release changed three things at once. The pager and B-tree became the only storage backend; the GDBM and in-memory drivers were removed; and — in the change log's words — "Copyright on all code was disclaimed. The library is now in the public domain." Version 2.0.0 followed on 28 September 2001. For the B-tree, Hipp says he took Donald Knuth's The Art of Computer Programming down from his bookshelf and worked from its description of the algorithm.

Version 3.0.0 arrived on 18 June 2004. At the time of writing, sqlite.org's release history lists 372 releases, the latest being 3.53.4 of 24 July 2026.

Phones Before Smartphones

SQLite's spread began on devices that were not yet called smartphones. Hipp recalls a newsgroup post from someone running an SQL database on a Palm Pilot, then a call from Motorola — "2002, 2001," he says, with the hedge — asking him to support SQLite in a new phone operating system. AOL followed with a contract for enhancements. Symbian, the operating system on Nokia phones, flew him to London after running a bake-off of ten database engines, two other open-source entrants and seven proprietary ones, which SQLite had won. Around 2005, by his account, he was meeting with the Android team at Google while their prototype still had a BlackBerry-style keyboard.

Two of the platforms in this part of the story have their own entries on this site: Symbian and the iPhone.

What "Most Widely Deployed" Rests On

sqlite.org states that SQLite is found in every Android device, every iPhone and iOS device, every Mac, every Windows 10 and 11 installation, the Firefox, Chrome and Safari browsers, and PHP and Python. Its arithmetic for the trillion figure is explicit: more than 4.0 billion smartphones in active use, each holding hundreds of SQLite database files.

The claim is hedged on its own page. sqlite.org's "best guess" is that SQLite is the second most widely deployed software library, after libz, and it says that exact rankings are impossible. The VLDB paper says SQLite "is estimated" to be one of the most widely deployed libraries of any type.

A Database File as an Archive Format

Two later facts show how far the library's role shifted from its Navy origins. The US Library of Congress lists SQLite as a Recommended Storage Format for datasets; when sqlite.org wrote that page in 2018, the only other recommended formats for datasets were XML, JSON and CSV. And the project states that it intends to support SQLite through the year 2050, keeping the file format stable and the files identical across 32-bit, 64-bit, big-endian and little-endian machines.

The code remains in the public domain. Every contributor, according to sqlite.org, has signed an affidavit dedicating their contributions, and the originals are kept in a firesafe at the main offices of Hwaci.

The design that came out of a ship's damage-control software — no server process, the engine linked into the program — turned the SQL database from something an application connects to into something it simply contains.