SQLite is a database engine that is also a file. One file. Not a file and a server. Not a file and a daemon. Not a file and a configuration directory and a port and a connection string and a monthly bill and a 3 AM PagerDuty alert. A file.
You copy it. You have a backup. You delete it. It’s gone. You open it. You have a database. There is no step two.
This is either the most profound or the most boring sentence in the history of data management. The Yagnipedia notes, with some reverence, that it is both.
“The best database is one file.”
— The Lifelog Manifesto, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
The Numbers
SQLite is the most widely deployed database engine in the history of computing. The exact number is difficult to calculate, but conservative estimates place it at over one trillion active databases worldwide. It ships in:
- Every iPhone
- Every Android phone
- Every Mac
- Every Windows 10+ machine
- Every copy of Chrome, Firefox, and Safari
- Every copy of Skype, iTunes, and Dropbox
- Most television sets
- Most automotive infotainment systems
- Airbus A350 flight software
- The US Library of Congress recommended storage format
This is not a database that needs a Medium article. This is a database that needs a geological survey.
And yet — at conferences, at meetups, at the specific kind of dinner party where developers argue about databases over wine they can’t afford — nobody discusses SQLite. There is nothing to discuss. There are no war stories. There are no incident postmortems. There are no blog posts titled “How We Survived Our SQLite Outage” because SQLite does not have outages. It is a file. Files do not have outages. Files sit there. Files wait. Files do not page you at 3 AM because they decided to reorganize their keys.
The Squirrel finds this deeply unsatisfying. A technology that requires no blog post to justify is a technology the Squirrel cannot propose migrating away from, which is the Squirrel’s primary recreational activity.
The Origin
In the year 2000, D. Richard Hipp was working on a contract for the United States Navy. The project involved software for guided missile destroyers. The existing database — Informix — required a DBA to be present when the system started.
Hipp asked the obvious question: what happens if the destroyer is in the middle of a battle and the database won’t start because the DBA is not on duty?
The Navy did not have a good answer.
Hipp wrote SQLite.
The guided missile destroyer got a database that starts when you open the file. No DBA. No configuration. No port. No connection string. No ceremony. The missiles presumably continued to be guided. The DBA presumably found other employment.
The Yagnipedia observes that the entire history of SQLite — the most deployed piece of software in human history after perhaps only the C library — began because one person asked “but what if there is no DBA?” and, upon receiving no satisfactory answer, wrote the solution over a weekend.
The Lizard has never commented on this origin story. The Lizard has never needed to. The origin story IS a Lizard scroll.
The Lifelog Connection
The lg project — a filesystem-first notes indexer built in three days from markdown and stubbornness — uses SQLite as its sole database. One file: ~/.local/share/lg/index.db. The file is not the truth. The markdown files are the truth. The file is a lens.
THE FILE IS THE TRUTH
EVERYTHING ELSE IS A LENS— The Lizard, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
SQLite provides the lens. FTS5 — SQLite’s full-text search extension — indexes every word in every note. Wiki-links become a queryable graph. Frontmatter becomes a queryable key-value store. Two hundred and fifty-three notes indexed in under two hundred milliseconds.
The Squirrel proposed Elasticsearch.
The Squirrel was not given Elasticsearch.
The Squirrel was given one file and told to be grateful. The Squirrel has not recovered. The Squirrel will never recover. The Squirrel is still, somewhere, drafting a proposal for an ElasticsearchMigrationPipelineWithGracefulFallback. The file does not care. The file responds in twelve milliseconds. Twelve milliseconds does not require a cache. Twelve milliseconds does not require Redis. Twelve milliseconds is the speed of boring.
The Databases We Didn’t Build
On January 25, 2026, the Squirrel arrived with blueprints for SolidMemDB. Three-layer storage. Custom indexes. A QueryPlannerWithCostEstimation. A TemporalIndexWithVersioning. A HybridStorageAbstractionLayer.
The response was concise:
“SQLite has been in production since 2000. It runs on literally every phone on Earth. It will outlive every JavaScript framework. It will outlive US.”
— riclib, The Databases We Didn’t Build
The custom database was not built. SQLite was opened. A for loop was written. The conversations persisted. Three thousand lines of composition replaced thirty thousand lines of invention.
The Squirrel’s QueryPlannerWithCostEstimation — the one that would have been three thousand lines by itself — was rendered unnecessary by the observation that SQLite already has a query planner, written by people who have spent twenty-four years on it, tested by every phone on the planet, and available for the price of opening a file.
IF A DATABASE EXISTS, USE IT. DON’T BUILD ONE.
— The Boring Technology Manifesto, The Databases We Didn’t Build
WAL Mode
WAL — Write-Ahead Logging — is SQLite’s concurrency mode. It allows multiple readers and one writer simultaneously, which sounds modest until you remember that the alternative — the database that locks entirely on write — is what SQLite did before, and nobody complained then either.
WAL mode is enabled with one line:
PRAGMA journal_mode=WAL;
That’s it. No configuration file. No YAML. No twelve-page document explaining replication topology. One pragma. One line. The database is now concurrent.
The lg indexer uses WAL mode. The watcher writes. The CLI reads. They do not conflict. They do not coordinate. They do not know about each other. They share a file. The file handles it.
The Yagnipedia notes that “the file handles it” is the most SQLite sentence ever constructed.
FTS5
FTS5 — Full-Text Search 5 — is SQLite’s built-in full-text search engine. It supports tokenization, stemming, phrase queries, boolean operators, and ranking by BM25. It stores its index in the same file as everything else.
The alternative is Elasticsearch: a Java application that requires its own cluster, its own configuration, its own monitoring, its own monthly bill, and its own blog post explaining why you need it (you don’t, unless you have more data than fits in a terabyte, and if you do, you probably don’t need the Yagnipedia to tell you what database to use).
FTS5 is not Elasticsearch. FTS5 does not cluster. FTS5 does not shard. FTS5 does not require a JVM. FTS5 requires a file. The file is already there. The search is already fast.
The lg project indexes 253 notes into FTS5 using an external content table with three triggers — insert, update, delete — that keep the search index synchronized with the content table automatically. The entire search infrastructure is a schema definition and a MATCH query.
“Modern development is a mass hallucination. SQLite is modern. It’s actively developed. It just doesn’t need a Medium article every week.”
— riclib, The Databases We Didn’t Build
The Conference Problem
SQLite is not discussed at conferences. This is not because SQLite is irrelevant. It is because SQLite is solved.
Conferences exist to discuss problems. PostgreSQL has problems — interesting, challenging, fascinating problems involving replication, partitioning, vacuum strategies, and connection pooling. MongoDB has problems — different problems, mostly involving the moment a developer discovers they need a JOIN. Redis has problems — specifically, the problem of being added to systems that don’t need it.
SQLite does not have these problems. SQLite has a file. The file works. There is no thirty-minute talk to be given about a file that works. There is no panel discussion. There is no “birds of a feather” session. There is no afterparty where engineers bond over shared trauma, because there is no shared trauma.
The Squirrel finds this absence suspicious. Surely a technology this quiet must be hiding something. Surely there is a scaling cliff, a concurrency nightmare, a configuration footgun waiting in the shadows.
There isn’t. The shadows are empty. The file is fine.
The Squirrel’s Objections
The Squirrel has raised the following objections to SQLite. The Lizard has responded to none of them, which is the Lizard’s way of responding to all of them.
| Squirrel’s Objection | Reality |
|---|---|
| “It doesn’t scale” | It handles terabytes. Your app has 400 megabytes. |
| “It’s not concurrent” | WAL mode. One pragma. Done. |
| “It’s not a real database” | It is literally the most deployed database in existence. |
| “It doesn’t have a server” | Correct. That is the feature. |
| “What about distributed systems?” | You don’t have a distributed system. You have one server at 3% CPU. |
| “But what if we NEED distributed—” | You won’t. |
| “What about—” | No. |
Pure Go
The lg project accesses SQLite through modernc.org/sqlite — a pure Go translation of the SQLite C source code. No CGO. No shared libraries. No brew install. No PKG_CONFIG_PATH. No dynamic linking. The database compiles into the binary.
One binary. One file. One go build.
This is the same principle that rejected ImageMagick in favor of CatmullRom splines: if the tool compiles with go build, it is the right tool. If the tool requires a C compiler, a shared library, and a prayer, it is the wrong tool.
The Squirrel proposed linking against the C SQLite library “for performance.” The C library is approximately 7% faster. The Go translation responds in twelve milliseconds. Seven percent of twelve milliseconds is 0.84 milliseconds. The Squirrel was proposing to add CGO — cross-compilation complexity, build-time dependencies, platform-specific linking — to save less than one millisecond.
The Lizard did not blink. The Lizard was already gone.
The Highest Compliment
The Squirrel finds SQLite boring.
In the Yagnipedia, this is the highest compliment a technology can receive. Boring means understood. Boring means debugged. Boring means there is no blog post because there is nothing to blog about. Boring means the developer sleeps through the night. Boring means the server runs at 3% CPU. Boring means the deployment is scp and the restart is systemctl and the monitoring is /health and the database is one file that has never — not once, not ever — reorganized its keys at 3 AM.
The The Lizard approves. The Lizard has always approved. The Lizard approved before SQLite existed, because the Lizard approved of the principle — that the best technology is the technology you forget is there, the technology that works so reliably it becomes invisible, the technology that earns its place by never demanding attention.
THE BEST DATABASE
IS SOMEONE ELSE’STHE BEST ORCHESTRATION
IS A FOR LOOP— The Lizard, The Databases We Didn’t Build
D. Richard Hipp wrote SQLite so a guided missile destroyer could start without a DBA. Twenty-six years later, it runs on every phone, every browser, every airplane, and one notes indexer in Riga that was built in three days by half an engineer and a hallucination.
It is one file. It works. There is nothing else to say.
The Squirrel will think of something.
