Turso is a platform built around SQLite-compatible databases, edge deployment, and high-density multi-database architecture. In 2023, it set out to solve one problem: network latency. They replicated SQLite to edge nodes, placing it closer to the code. But SQLite is extremely lightweight, and developers quickly realized this enabled more than just lower latency. You could use code to provision a physically isolated database for each tenant. Later, the deployment boundary shrank even further — down to a single task. Whenever an agent invokes a tool, the system clones a temporary database branch for it. If the task fails, the database is simply destroyed, achieving zero-fragment rollback. In 2026, Turso named this evolutionary trajectory “Database for Agents.”
This evolution reveals an important insight. An “agent database” is not an entirely new database category. It introduces no new SQL syntax and restructures no underlying storage model. What has truly changed is the physical deployment boundary of databases. Agents, sessions, and tasks have become the core unit of physical deployment and permission boundaries. Previously, we shared one large database and partitioned data through logical policies. Now, each agent has an independently controlled, freely movable state container.
This shift in physical boundaries solves the progress-synchronization bottleneck in AI systems. We spend enormous effort teaching AI how to “remember.” We use vector retrieval and long-term memory to perform “memory recall.” But we often forget to teach it how to “remember the current execution progress” — that is, managing its “execution state.” In a previous article exploring agent filesystems, we noted a phenomenon. When an AI calls various tools, it generates a large number of temporary files and execution paths. If progress isn’t managed properly, the system quickly becomes chaotic.
Without a stable foundation capable of isolating and synchronizing task state, AI tasks are highly prone to getting stuck. Even with perfect memory retrieval, a crash leaves no safe path to recover progress. As AI lifecycles lengthen and behavioral boundaries widen, traditional frameworks fall far short.
To grasp the underlying pattern behind this development, it helps to step back and survey the evolution of this space.
In the beginning, large models could only read a very limited number of tokens at a time — a few exchanges into a conversation and they’d forget what came earlier. The most pressing headache was how to feed more conversation context into the model. The well-known MemGPT virtual context management mechanism from 2023, for instance, mimicked the virtual memory of an operating system, enabling a large model to manage its own memory by calling functions. While this approach made context management more flexible for the model, it still relied on traditional databases underneath. It addressed how to help AI retrieve memories, but had no bearing on tracking where an AI task had advanced to.
Later, as people began building complex AI workflows and multi-agent collaboration, the AI lifecycle grew longer — no longer just one question, one answer. At this stage, various development frameworks started introducing designs akin to “game save points.” For example, LangGraph’s persistence design splits data into two categories: “checkpoints” and “cross-thread storage.” Checkpoints are like auto-saves in a game, recording each step of an AI task’s execution so that the system can help it recover progress after a failure — or wait for human approval. Cross-thread storage, on the other hand, holds data that rarely changes, such as a user’s personal preferences. At this point, the design was already somewhat database-like, but its primary function was to help AI resume progress; it still couldn’t co-locate the temporary files and sandbox state generated during local execution.
Because AI is busy when running tasks. It doesn’t just query database tables and record ephemeral key-values — it’s constantly modifying local files in sandboxes and writing tool-call logs. If storing a file requires calling cloud object storage, saving state demands Redis, and persisting data needs Postgres, a single AI tool call ends up bouncing across the network multiple times. Not only is it slow, the system architecture becomes painfully complex. To avoid these unnecessary costs, people began packaging all this state into a lightweight, portable file that travels with the AI. Wherever the AI runs, this file goes — carrying file paths, key-value state, and audit logs together. AgentFS’s file/key-value/tool-tracking design, which emerged in 2025, epitomizes this approach, bundling all these abstractions into a single physical container.
If we map out AI persistence solutions, we can’t just summarize them with the word “memory.” The entire structure can be broken down into four layers:
The top layer is the memory strategy layer (e.g., Letta, Zep, Mem0), which decides what to remember, what to forget, and how to organize long-term memory.
The second layer is the execution semantics layer (e.g., LangGraph), responsible for placing save points into AI workflows so that programs can resume execution.
The third layer is the retrieval index layer (e.g., pgvector), handling vector search and hybrid retrieval so AI can quickly rummage through materials.
The bottom layer is the state foundation layer (e.g., SQLite, Postgres, Durable Objects, and locally-syncing solutions like Electric/PGlite), providing the lowest-level physical storage and data isolation.
Among these four layers, Turso’s primary bet is on the bottom state foundation layer. It also aims to manage the filesystem and key-value state above via AgentFS. So, the so-called “agent database” is not about inventing a brand-new SQL query language — it’s about shrinking the physical deployment unit and lifecycle of databases so that every agent has its own independent database.
Turso as a company did not initially set out to build an AI database. It went through several pivots, progressively pushing the database design philosophy from “one database per tenant” toward “one database per agent — or even per task.”
At the beginning, Turso’s predecessor was a backend-as-a-service company called ChiselStrike. The edge database platform they launched was primarily aimed at solving network latency caused by physical distance. For example, your code runs on an edge node close to the user, but your database sits in a distant primary server — the round trip is still slow. To solve this, they initiated and led the open-source libSQL database fork. libSQL is highly compatible with SQLite but comes with native replication. At the time, Turso Cloud was all about bringing the database closer to the code, reducing remote read latency to the microsecond level.
Later, they discovered just how lightweight SQLite files are. Traditional multi-tenant approaches use various strategies within a single large database to isolate different users’ data — but one code vulnerability could easily leak other tenants’ data. Since SQLite files are so small, why not provision a physically fully isolated database for every user, every tenant, even every transient task? So Turso adjusted its commercial direction, allowing users to dynamically create tens of thousands of independent databases through code. They shifted the database mindset from “one application paired with one large database” to “each tenant gets its own small database.”
Developers building AI platforms immediately got excited when they saw this approach. They started using this architecture to isolate agent progress. For example, in Turso-hosted customer cases, the Adaptive Computer team, when having AI execute code generation and software build tasks, would clone a temporary branch database for the AI every time it invoked a tool or entered a sandbox. If the AI completed successfully and without issues, the data was merged back; if it failed, the database was simply deleted. This use-it-and-toss-it approach provided clean isolation and enabled zero-fragment fault rollback. However, this method had a major limitation at the time, constrained by libSQL’s Embedded Replicas mechanism. Under this model, while AI could read data locally at high speed, any write still had to be sent back over the network to the cloud primary node — achieving fully offline local writes was impossible.
To bridge this last mile of local read-and-write capability, the
Turso team rewrote the code from scratch, launching a new Rust-based
engine called Turso Database. This engine supports asynchronous I/O and
offers more efficient write concurrency, serving as the core of many new
features in Turso’s
new-generation cloud platform (currently in private beta, announced
2026-04-08). Within this new architecture, they simultaneously
introduced AgentFS and an
incremental log-based sync mechanism. AgentFS encapsulates the
filesystem, key-value store, and AI tool audit log into a single locally
readable and writable SQLite file. The sync layer allows this file to
synchronize progress between AI execution sandboxes, the browser, and
the cloud through explicit push() and pull()
calls. In their sync
benchmark protocol explanation, they also stated that new projects
should no longer use the old libSQL Embedded Replicas and should adopt
this next-generation sync architecture instead, addressing issues that
arise during physical page synchronization.
When you connect the dots along this path, the trajectory is remarkably clear: start with geographic proximity to reduce latency; then use multiple databases for tenant isolation; next, leverage branching technology to shrink the lifecycle down to each individual task; and finally, through the new Rust engine, offline sync, and the AgentFS interface, turn the database into a state container that can move with the AI, execute locally, and synchronize state bidirectionally.
That said, we need to draw a sober line around product maturity. As of today, the libSQL engine and the existing Turso Cloud have been running in production for many customers for a long time and are mature, proven products. However, the brand-new Turso Database engine, the Turso Sync protocol, the AgentFS interface, and the next-generation cloud platform — all of which embody the agent-centric vision — remain in beta or private beta. They may still encounter file corruption, unresolved system permission issues, or incompatibilities with other libraries. It would be highly imprecise to project the track record of the mature cloud services onto these still-in-testing new technologies.
There’s no need to compare against every AI tool that can do vector retrieval or store chat history. The crucial distinction here is this: an agent database shrinks the physical deployment unit of a database directly down to each agent’s own private container. Following this line of thinking, the market actually features four distinct competitive approaches.
The first approach is the Cloudflare Durable Objects architecture. It bundles edge compute and strongly consistent private SQLite storage into a single object. Each AI can have its own object ID, through which it dynamically creates and manages private state, with no limit on the number of objects. This colocation of compute and storage is the closest to Turso’s “one database per agent” vision. Its limitation, however, is deep coupling with the Cloudflare Workers runtime. You can’t download the database file to a local device or drop it into an unmanaged third-party sandbox to run — it lacks the sort of portable, offline, bidirectional sync capability.
The second approach is Neon’s cloud multi-tenant Postgres solution. Neon uses a compute-storage separation architecture, allowing you to dynamically provision isolated Postgres databases in the cloud through code, with support for auto-suspension and rapid data cloning (branching). If your AI system needs to handle high concurrency, complex cross-table queries, or relies heavily on Postgres’s mature plugin ecosystem, Neon is an exceptionally powerful cloud backend. Yet its limitations are equally apparent: it runs entirely in the cloud. If the AI runs locally, there is no local database replica to obtain, and the branching technology is merely cloud-side resource orchestration.
The third approach is the local-first paradigm combining Electric with PGlite. PGlite lets you run a Postgres instance inside a browser or sandbox directly via WASM. Electric acts like a sync faucet, streaming a subset of cloud database data to the client according to rules you configure. This design delivers fast local reads without requiring each AI to download the entire table. However, according to the latest PGlite sync plugin known limitations, the official sync plugin does not yet support pushing locally written changes back to the cloud primary in real time, and lacks a reliable conflict resolution mechanism. So the closed loop of bidirectional offline sync remains incomplete here.
The fourth approach is using the most basic, vanilla plain SQLite. If your AI only runs on a single machine or within a single sandbox, has no need to sync with other devices, and doesn’t require remote APIs or centralized backups, then using a local SQLite file directly is the cheapest and cleanest solution. In such cases, adopting any managed cloud service only adds unnecessary network latency and operational overhead.
When evaluating these technologies, it’s worth keeping a watchful eye on the tuition the mobile sync domain has already paid. The Realm mobile sync service (later deprecated — you can see the discussions at the time), which deeply coupled client-side storage with a cloud sync service, taught everyone a lesson. Achieving bidirectional real-time sync across multiple heterogeneous endpoints entails enormous long-term maintenance costs, multi-language SDK adaptation, and extremely complex data conflict handling. These pitfalls are something no polished product demo video can ever convey.
So, when making a technical selection, the core question really comes down to one: how deeply does your system depend on bidirectional real-time sync? If your AI runs overwhelmingly in cloud Workers, Cloudflare Durable Objects can provide a remarkably clean and complete architecture. If you need to handle highly complex SQL relational queries or integrate with mature backend systems, Neon paired with cloud-side security isolation is the more reliable engineering choice. Turso’s real sweet spot lies in scenarios where you need to drop a private SQLite file into any arbitrary sandbox, perform fast local reads and writes under intermittent connectivity, and then manually push incremental changes back to the cloud once reconnected. In this market, there is still no silver-bullet solution, and everyone’s competitive boundaries are constantly shifting.
Assigning a separate database to each AI genuinely solves the pain points of physical isolation and local computation. But in real-world system architecture, every benefit comes at a cost. In fact, for the vast majority of cloud-based AI, the traditional approach — logical isolation via tenant IDs within a single Postgres database, combined with a mature workflow system like Temporal — is already effective and stable enough. If you force hundreds of thousands of fully physically isolated small databases into your system, you can easily turn a straightforward runtime problem into a vexing management headache.
Imagine the moment when the number of databases explodes from a handful to hundreds of thousands or even millions. Previously simple operational tasks become a nightmare of distributed governance. With a single Postgres instance, altering a table schema is one command, one transaction. But now you have hundreds of thousands of independent SQLite files. Any schema change — adding or removing a field, updating an index — forces you to confront the challenges of canary rollouts, consistency guarantees, and rollback strategies across this fleet of files. Moreover, the existing SQLite tooling ecosystem is not yet ready for this “carrier battle group” scale of databases. For instance, the tursogo driver migration incompatibility issue encountered by developers exposes the lag and fragility of open-source migration libraries in the face of underlying driver changes.
More importantly, business-level conflicts arising from bidirectional sync cannot be automatically resolved by the underlying network sync protocol. Turso’s incremental sync protocol can cleverly sidestep data-block conflicts at the network layer by letting you control the timing of push and pull, but it has no understanding of your business logic. If two AI agents independently modify the same order in their local databases within separate sandboxes, when you push both to the cloud for merging, the cloud server still faces a conflict at the business-logic level. This requires your application layer to write its own data-ownership partitioning, optimistic locking, or merge rules; the lower-level sync protocol cannot help here.
That said, the benefits of giving each AI an independent physical database are very real. From a security standpoint, if your AI needs to execute untrusted third-party code, physically isolating databases at the file level provides an extremely low-cost way to prevent malicious code from cross-account peeking or tampering with other data. Data bounded purely by the file-as-physical-unit boundary is remarkably easy to package for archival, hibernate for cold start, or relocate across different compute nodes. Moreover, when AI performs local SQL queries, they can be invoked directly through the local process, with no network round trip at all — enabling extremely fast reads and writes, which is particularly well-suited to scenarios where AI frequently reads and writes data during high-frequency tool invocation.
Thus, when making a selection, we need to be clear about the actual constraints we face. If your AI has a short lifecycle, runs at the edge or in sandboxes, requires high-frequency local tool invocation, and needs isolated compute permissions, then the Turso approach — using physical file isolation combined with local sync — is a very good fit. But if you’re building a centralized multi-agent collaboration network where everyone needs to share and modify a single global truth with high concurrency and relies heavily on strong database consistency transactions, then the traditional shared-Postgres approach remains the more reliable choice.
What is called an “agent database” is defined not by an evolution in query language, but by a comprehensive contraction of data’s physical boundaries, lifecycles, and security trust boundaries. Among current engineering options, the multi-database isolation scheme built on the libSQL engine and traditional Turso Cloud has already proven mature. But in scenarios demanding greater fluidity — offline sandboxes, bidirectional sync, and so on — the new Turso Database engine, the Turso Sync protocol, and AgentFS, all still in early-stage testing, must yet overcome the practical challenges of bidirectional sync’s business-level conflicts and the complexity of distributed governance.
Faced with the transition between old and new paradigms, the fundamental choices in architecture design have not been shaken. For centralized collaboration networks that require high-concurrency global sharing and strongly consistent transactions, a shared relational database with logical isolation remains the most prudent technical choice. For edge scenarios that demand physical isolation, high-frequency local tool invocation, and portable state, these portable state containers are expanding the capability boundaries of agent systems at ever-higher deployment densities.