Cloudflare made a SQL storage engine generally available inside Durable Objects on Saturday, giving each object a full SQLite-compatible database that persists to durable storage and replicates asynchronously to nearby regions. Durable Objects have offered key-value storage since 2021, which worked for counters and session state and forced anything relational back to a central database. The new engine changes what belongs at the edge. A multiplayer document, a game session, a chat room, or a per-tenant application shard can now hold structured state with queries, indexes, and transactions, located in the data center nearest to whoever is using it.
The architecture
Each Durable Object is a single-threaded actor with a globally unique identity, and Cloudflare guarantees exactly one instance runs at a time. That property makes a local database straightforward, because there is no concurrent writer to coordinate with. The SQL engine runs in the same isolate as the object's code, so a query is a function call rather than a network request, and latency for a simple read measured 0.3 milliseconds in testing against roughly 30 milliseconds to a regional Postgres from the same location.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}Durability comes from a write-ahead log streamed to Cloudflare's storage layer, with acknowledgment before a transaction returns. Replication to additional regions is asynchronous and configurable, providing read replicas that lag by tens of milliseconds and a recovery point objective measured in single-digit milliseconds if the primary location fails. The object migrates on failure, replaying the log, with a recovery time Cloudflare states as under a second in typical cases.
What this is good for
The pattern that fits best is per-entity state where the entity has a natural owner. A collaborative document with twelve editors is one Durable Object holding one database, located near wherever most editors are, with all reads and writes local. A game match. A support conversation. A per-customer application shard in a business-to-business product where tenants never share data. In all of these the single-writer constraint is a feature rather than a limitation.
It fits badly for anything requiring queries across entities. There is no join across Durable Objects and no global secondary index. Reporting, search, and analytics all need data replicated somewhere else, which Cloudflare addresses with a change data capture stream into R2 or into an external warehouse. Teams that treat this as a general-purpose database will build something painful. Teams that treat it as state colocated with computation will find it fits a specific shape of application well.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
Pricing and the cost model
Storage costs $0.20 per gigabyte-month. Reads are $0.001 per million rows read and writes $0.001 per hundred thousand rows written, which is a metering model borrowed from D1 and which rewards efficient queries and punishes table scans. There is no per-object minimum, which means an application with a million mostly-idle objects pays only for storage. That matters enormously for the per-tenant pattern, where a conventional database per tenant is economically absurd.
The cost surprise most teams will hit is rows read rather than rows returned. A query without an index scans, and a scan on a hundred thousand row table costs a hundred thousand row reads whether it returns one row or all of them. Cloudflare surfaces the count in query metadata and has a warning in the dashboard. Anyone coming from a managed Postgres where an unindexed query merely takes longer will need to adjust their instincts.
How it compares
Turso built a business on distributed SQLite with a similar per-tenant pitch and a different architecture, replicating databases rather than colocating them with compute. Fly.io offers LiteFS for SQLite replication. Neither has Cloudflare's network footprint, and neither offers the single-writer guarantee that removes the coordination problem entirely. Cloudflare's advantage is that Durable Objects already solved the hard part.
The comparison against a conventional regional database is more interesting. A Postgres in one region serving a global audience gives 150 milliseconds of latency to distant users and unlimited query flexibility. Durable Objects give sub-millisecond local latency and severely constrained queries. The right answer depends on the application, and the realistic architecture for most products is both, with hot per-entity state at the edge and a system of record in a region.
The lock-in question
Durable Objects have no equivalent anywhere else. The programming model, the identity system, and the guarantees are Cloudflare-specific, and an application built around them cannot be moved without a rewrite of its state layer. Cloudflare's counter is that the SQL is standard SQLite and the data is exportable, which is true about the data and irrelevant about the architecture.
That is a real consideration and it is not automatically disqualifying. Every serverless platform involves lock-in and the question is whether the capability justifies it. For applications where colocated state genuinely changes what is possible, and there are more of these than the industry has explored, the trade may be worth making deliberately. For applications that would work fine on Postgres, adopting a proprietary actor model to save latency nobody notices is a decision to regret in three years.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Edge Computing
