SQLite Was Never Built for Agents

10 min read

Addo Smajic avatar

Addo Smajic

Aug 24, 2026

SQLite Was Never Built for Agents

AI is leaving the cloud. It is showing up under a dozen names — Edge AI on gateways and device fleets, Local First applications on laptops running their own models, Physical AI in robots that perceive and act, embedded intelligence in firmware small enough to forget is there. The labels describe the hardware. Underneath them is a single pattern: an agent, running where the data is created, making decisions without asking a data center for permission first.

Every one of those agents has to keep its state on the device it lives on. For twenty years, that problem had a one-word answer: SQLite. It earned the spot honestly. It runs everywhere, needs no setup, and stores an entire database in a single file you can copy like any other. For the apps, browsers, and firmware it was built for, it was not just a good answer. It was the correct one.

Agents are not that software. And the teams shoehorning SQLite into agentic work at the edge keep discovering that the fit fails in the same places every time. This is not a bug or a missing feature. SQLite is the strongest case ever made for the embedded database — and it is also a precise map of exactly where the single-file design ends.

The most deployed database on Earth earned its reputation

SQLite runs on billions of devices: phones, browsers, cars, firmware. Most of the world used it today without knowing. Its design is a masterclass in restraint — the whole engine fits in a few hundred kilobytes, and there is nothing to install, nothing to operate, nothing standing between the application and its data.

For AI outside the cloud, those properties are not luxuries. An agent cannot wait on a network round trip, cannot assume a connection exists, and cannot carry a database administrator in its firmware. Edge AI runs on exactly the kind of hardware SQLite has owned for two decades, which is why reaching for it feels so natural.

The reach is the right instinct, pointed at the wrong decade.

A world that had one of everything

SQLite's architecture is a portrait of the world it was designed for: one application process, opening one file, on behalf of one user. Every mechanism follows from that portrait. Writes are serialized through a single lock, because two writers at once was the exception. Access control is whatever the filesystem says, because the operating system already knew who was logged in. Updates overwrite the past in place, because the file is the state and history had no job to do. And the database lives at a fixed path, because the data was never expected to leave the machine.

None of that was wrong. It was exact engineering for the software of its era — a settings store, a browser cache, a mobile app's local data. One process, one machine, one user, and SQLite fit the shape perfectly.

An agent breaks that portrait piece by piece. It is many models, tools, and memory routines writing at the same time. It acts under its own identity, often beside other agents with different permissions on the same hardware. And its state cannot live at a single path, because the same knowledge has to exist on the robot, the gateway, and the operator's tablet at once — and stay coherent across all three, with no referee in a data center.

Where agents collide with the file

The failures arrive in a predictable order.

Concurrency. SQLite permits one writer at a time. An agent is a concurrency generator — a planner updates state while a tool logs a result while a memory routine consolidates context. On a single-file database, that parallelism becomes a queue with retry logic bolted around it.

Identity. SQLite has no users, no roles, no per-record permissions. Any process that can open the file owns every row in it. There is no way to say the navigation agent may read the sensor log but never touch the credential store. Whoever holds the file is everyone.

Merge. The moment a file is copied, the copies begin to diverge with no path back. For agents, that divergence is not an accident to prevent — it is the normal operating condition of devices working offline and rejoining. The file's only answer is to pick a winner and discard the loser.

History. SQLite updates in place. Once the past is overwritten, an agent cannot later prove what it knew, when it knew it, or that nothing changed afterward. In clinics, construction sites, and orbital systems, that is an audit hole exactly where accountability is supposed to live.

The server that reappears. SQLite calls itself serverless, and on one device it is. But the moment state has to exist on two devices, the answer is a sync service bolted on top — and that service needs a home. The home is a server that decides which writes win and what the real state is. The serverless database gets a server after all, and it gets the most powerful kind: the one that owns the truth.

The unit of data agents actually need

Invert those five collisions and the requirements write themselves. This is what a genuinely edge-first database has to carry inside the data itself:

  • Writes that merge on their own. With conflict free data types, every field knows how to reconcile concurrent changes, so any two devices converge to the same state in any order. Divergence becomes rhythm, not conflict.
  • Access rules that travel with the data. Each record carries its own policy, bound to a cryptographic identity, and every write is signed. An agent's scope holds on its own device, on a peer's device, and offline.
  • History that is structural. With content addressable storage, every version of a record is addressed by the hash of its contents. The past has an address, and tampering would change it — so an agent can prove exactly what it saw.
  • Replication that is peer to peer. Devices exchange updates directly and converge by the merge rules the data already carries. No mediating server, no arbiter of truth in someone else's building.

This is edge data management on a local first foundation — a different unit of data, not a better file. SQLite perfected the file, and nothing here takes that away. But the agents arriving on that hardware are concurrent where the file assumes one writer, plural where it assumes one user, mobile where it assumes one disk, and accountable where it assumes the past can be overwritten.

At Source, we are building DefraDB, the distributed database built for the agentic edge.


Share

Start Building the Future

We built Source to help you build the next generation of intelligent software, from Earth to orbit. It’s time to break free from cloud constraints.