SQLite as the Unit of Trust
The most deployed database in the world isn't Postgres or MySQL. It's a single file on disk — and that turns out to matter a lot.
The first thing I do when I want to trust a piece of software with my real data is find out where it stores things. Not the marketing answer. The actual answer.
With most apps, the answer is: somewhere in our cloud, in a format you can't read, accessible through an API that may or may not exist in five years. SQLite gives a different answer. One file. On disk. Readable by any SQLite client. Queryable by any programmer with fifteen minutes to spare.
That sounds like a footnote. I've come to think it's the main point.
The most deployed database in the world
Richard Hipp wrote the first version of SQLite in 2000 while consulting for Bath Iron Works on software for a US Navy destroyer, the USS Oscar Austin. The ship ran Informix as its database, and Informix had a habit of going down whenever the server did. Hipp's idea was to build something that talked directly to disk, had no server, required no configuration, and didn't particularly care about data types. His colleagues suggested he write it himself.
That small tool is now the most widely deployed software module of any kind in the world. There are more than a trillion SQLite databases in active use. Every iPhone. Every Android phone. Every Chrome browser. Most desktop apps. Many automobiles. A fair number of aircraft. The US Library of Congress recommends it as a long-term preservation format for digital content — the only database format on that list, alongside XML, JSON, and CSV.
The whole story of SQLite is that something very simple turned out to be exactly right for a very large category of problem.
What complexity costs you
When I was deciding how to store user data in Harbor, the default architectural instinct was Postgres. Postgres is powerful, well-understood, and maps naturally onto the mental model most engineers carry: a central server, multiple connected clients, separate tables for separate concerns.
The problem with that model for a personal knowledge base is subtle but real. Your data is no longer yours in any tactile sense. It exists somewhere in a database cluster, owned by a connection string you can't email to yourself. If you want a backup, you run a process. If you want to inspect it, you open a client. If you want to hand it to someone else, you write an export function and hope it covers everything.
With per-user SQLite, the model is different. Every Harbor workspace is a file. Everything in that workspace — notes, people, tasks, preferences, search indexes, audit history, every structured entity — lives in that one file. To back it up, you copy it. To inspect it, you open it in DB Browser for SQLite, a free tool that has existed for over a decade and will likely exist for another. To move it somewhere else, you take it with you.
What inspection actually gives you
There's a specific kind of trust that comes from being able to look.
I don't need to open the SQLite file every day. I probably won't. But the ability to do it — to open a terminal, run sqlite3 workspace.sqlite .tables, and see the actual schema — changes something about how I relate to the system. It's the same reason I'd rather keep notes in Markdown than in a proprietary format. The inspectability is the trust.
This matters most for AI-modified data. When an AI agent updates a preference, adds a task, or modifies a person record in Harbor, that write lands in the SQLite file. It's in a concrete row, with a timestamp, under a schema I can read. The audit table exists in the same file. I can query it and see exactly what changed, and when.
Contrast that with AI memory as most assistants implement it: opaque, cloud-hosted, updated silently, retrievable only through the same interface that wrote it. That's not memory. That's a black box with a friendly name.
Hipp's original insight was that sometimes what you want is the absence of infrastructure. No server means no server to go down. No config means no config to lose. One file means one thing to worry about.
Twenty-five years later, that philosophy describes something more than a database choice. It describes an approach to trust: build systems where you can see the thing. Hold the workspace in your hand. Know where your data sleeps at night.
A .sqlite file isn't glamorous. But you can back it up in one command, move it between machines without a migration plan, and open it in any SQL client ever made. That's worth more than it sounds.
Asgeir Albretsen is the founder of Harbor.