The unlikely dominance of SQLite
Created by D. Richard Hipp in 2000, SQLite has grown into a massive embedded library with over one trillion databases in use, powering everything from iPhones to the Airbus A350.
D. Richard Hipp created SQLite in 2000 because Informix failed on the USS Oscar Austin. He worked as a contractor for Bath Iron Works on the guided-missile destroyer. When a pipe ruptured on a battleship, the crew needed to isolate damage by closing specific valves. They could not rely on a database server that might lose connection during combat. Hipp wanted to pull data directly from a disk to avoid these dependencies.
In 2000, broadband internet only reached 1% of US households. He coded the B-tree storage engine on a plane. He wrote a byte code engine and a compiler to translate SQL into that code. Motorola eventually paid him $80,000 to include SQLite in their cell phone operating system. Later, America Online wanted to use SQLite on their CD-ROMs to save space.
SQLite is everywhere.
Today, billions of copies exist. It powers every iPhone and Android device, every Mac, and every Windows 10 or 11 installation. It resides in every Chrome, Firefox, and Safari browser. Even the Airbus A350 uses it for flight-critical software that meets DO-178B safety standards. WhatsApp uses it to store local messages for its 2.5 billion users. The United States Library of Congress even recommends SQLite as a long-term storage format for digital preservation. There are likely over one trillion SQLite databases in active use.
The Architecture of Simplicity
SQLite is an embedded library. It lives inside the application rather than running as a separate server process. This architecture removes the need for network round-trips and complex configuration. The binary is small, measuring only 2 MiB.
The entire database sits in a single file on a disk.
I find that SQLite handles most applications easily. It works well for read-heavy workloads like blogs or documentation sites. Because SQLite eliminates the need for network round-trips between the application and a server, it can be five to ten times faster than PostgreSQL for simple key-value reads on the same local machine for most users. It avoids the N+1 problem that plagues other databases.
It is fast.
Testing drives its reliability. The project uses 100 million lines of test code to ensure it survives I/O failures and memory errors. This testing includes power loss simulation and crash testing. A full coverage run uses 2.4 million test cases. There are 600 lines of code per production line.
A major drawback remains. SQLite serializes all writes through a single writer lock. If your app requires thousands of concurrent writes from different processes, you will hit a bottleneck. It lacks a built-in user management system. SQLite also uses dynamic typing, meaning you can insert a string where an integer is expected.
| Feature | SQLite | PostgreSQL |
|---|---|---|
| Architecture | Embedded | Client-server |
| Deployment | Single file | Managed service |
| Write Concurrency | Single writer | MVCC (Concurrent) |
| Network Access | Local only | TCP/IP |
The Modern Edge
New technologies changed the perception of SQLite in 2025 and 2026. Platforms like Turso and Cloudflare D1 brought SQLite to the edge. LibSQL, a fork of SQLite, added native replication and server mode to solve the single-machine limitation. This fork also provides vector search for AI use cases and server mode via HTTP or WebSockets. It includes a BEGIN CONCURRENT extension to allow multiple writers to proceed as long as they do not modify the same pages.
The ability to use a database-per-tenant pattern provides real isolation. You can give every user their own database file to prevent data leaks and simplify compliance. This approach allows for independent backups and independent scaling for every user. LiteFS enables distributed SQLite using FUSE filesystem interception. Turso provides edge replication in over 30 locations.
I recommend SQLite for solo developers and indie hackers shipping fast. It costs nothing to run and has zero operational overhead for deployment. You just copy the file to back it up. You should use SQLite if you want to avoid managing a server.
The team consists of only three people: D. Richard Hipp, Dan Kennedy, and Joe Mistachkin. They do not accept outside contributions to keep the code in the public domain.
Does the single-writer lock still prevent its use in high-frequency event logging?