Skip to main content
株式会社オブライト
Software Development2026-07-04

Cloudflare Durable Objects Deep Dive — Stateful Serverless with Zero-Latency SQLite, GA in 2025, Free-Tier Available, Storage Billing Since January 7, 2026 The New Default for Chat, Collaborative Editing, Multiplayer, and LLM-Session Coordination at the Edge

Cloudflare Durable Objects (official docs / product page / SQLite in Durable Objects blog) is Cloudflare's stateful serverless primitive that pairs compute with persistent storage inside a globally-unique instance running on Workers. Announced in 2020, it reached GA on SQLite storage with Workers Free-tier availability in April 2025, then entered its paid-billing phase on January 7, 2026 — this is now the commercial-adoption era.

Architectural core: a DurableObjectStub derived from a name (DurableObjectNamespace::getByName) always routes to the single, globally-unique instance for that name → zero-latency SQLite access because compute and storage co-reside in the same process on the same machine. This delivers strong-consistency single-master semantics at edge latency — a class of distributed system that is famously hard to DIY, replaced with a single platform primitive.

Pricing (Paid tier):
- Requests: 1M/month included, then $0.15 / 1M (WebSocket inbound counts at 20:1)
- Duration: 400,000 GB-seconds/month included, then $12.50 / 1M GB-seconds
- SQLite row reads: 25B/month included, then $0.001 / 1M
- SQLite row writes: 50M/month included, then $1.00 / 1M
- Stored data: 5 GB-month included, then $0.20 / GB-month
- setAlarm() counts as one row write

Free tier (launched April 2025): 100,000 requests/day, 13,000 GB-seconds/day, 5M SQLite row reads/day, 100K writes/day, and 5 GB stored data — plenty for personal PoC and startup validation.

WebSocket Hibernation: idle-but-eligible instances do not accrue duration charges. Long-lived sparse-messaging sessions (chat, notifications, LLM conversation state) become dramatically cheaper to run.

Key 2025–2026 updates: April 7, 2025 SQLite GA + Workers Free; August 21, 2025 direct getByName construction; October 16, 2025 Data Studio UI editor; October 25, 2025 WebSocket message size lifted from 1 MiB to 32 MiB; January 7, 2026 SQLite storage billing goes live.

Representative use cases: collaborative editing (Google-Docs-class), real-time chat, multiplayer game room-matching, live notifications, LLM agent conversation and session state (backend for Claude Code / Cursor-style tools), financial and IoT event buffering, distributed rate limits and locks.

Positioning: where Local LLM landscape (June 2026), agmsg, and Sakana Fugu orchestration distribute AI inference, Durable Objects distribute stateful session, history, and coordination at the edge — a natural complement rather than a competitor.


TL;DR — What Are Cloudflare Durable Objects?

Cloudflare Durable Objects is a stateful-serverless primitive that runs on Workers and co-locates compute with SQLite persistence inside a single, globally-unique named instance (official docs).

Four takeaways:

1. Zero-latency built-in SQLite — DB queries in the same process bring the usual hundreds-of-µs–ms DB call down to tens of µs
2. Strong consistency + edge latency — the named DO is globally unique, retaining single-master semantics while running geographically close
3. WebSocket Hibernation — idle connections accrue zero duration cost, transforming the economics of long-lived sessions
4. Free tier available since April 7, 2025 GA + SQLite storage billing live since January 7, 2026 — the commercial-adoption phase has begun

This column joins our Local LLM June 2026 Update, agmsg, Sakana Fugu, and Apple Container coverage as the 2026 distributed-platform primitives cluster.

What Durable Objects Actually Is

Traditional serverless (AWS Lambda / vanilla Cloudflare Workers) is stateless: each invocation is a fresh instance and state must live in an external DB — which makes write-heavy or consistency-sensitive designs hard.

The essence of DO: the platform guarantees name → globally-unique instance routing. Any request for the same name, from anywhere in the world, reaches the same single instance, and that instance has zero-latency access to persistent SQLite via the storage API.

Shape of it:

ts
// On a Worker: get a DO stub by name
const stub = env.MY_DO.getByName(`chat-room-${roomId}`);

// Fetch / RPC to it — always the one true chat-room-42
const response = await stub.fetch(request);

That "one globally-unique named instance" is exactly the shape needed for collaborative editing, chat, multiplayer games, distributed counters, rate limits, and LLM conversation state — anywhere you want single-master consistency without standing up a full DB.

Why SQLite Inside Matters

The SQLite backend — GA on April 7, 2025 — is what pushed Durable Objects into practical territory (Cloudflare Blog: Zero-latency SQLite storage).

What this technically means:

- SQLite runs in the same process as the DO — zero network round-trips, single syscall
- Ordinary SaaS DB queries (hundreds of µs to ms) become tens of µs
- Up to 10 GB per object of storage
- Full SQL flexibility (JOINs, indexes, transactions)
- The legacy Key-Value storage backend remains supported (Paid-only)

Design consequence: "per-tenant DB," "per-room DB," "per-session DB" become nearly free. You can give each user, each chat room, or each LLM session its own dedicated DB. Multi-tenant tenant isolation collapses into a structural property of the platform.

2025–2026 Release Timeline

DateRelease
2025-02-11Internal error exceptions include reference IDs (better debugging)
2025-02-19SQLite supports PRAGMA optimize
2025-04-07SQLite GA + Workers Free-tier support; storage per object raised to 10 GB
2025-08-21DurableObjectNamespace::getByName allows direct stub construction (simpler code)
2025-10-16Data Studio UI on the Cloudflare dashboard for viewing / editing SQLite
2025-10-25WebSocket message limit raised from 1 MiB to 32 MiB (large-message support)
2026-01-07SQLite storage billing goes live — over-free-tier usage begins to bill; commercial-adoption phase begins

April 7, 2025 and January 7, 2026 are the two anchor dates: the first opened technical readiness + free tier; the second closed the economic loop.

Pricing (as of July 2026)

Workers Paid plan ($5/mo and up) subscribers (official pricing):

Compute:

MetricIncludedOverage
Requests1M/month$0.15 / 1M (WebSocket inbound at 20:1)
Duration400K GB-seconds/month$12.50 / 1M GB-seconds

SQLite Storage (recommended backend):

MetricIncludedOverage
Row reads25B/month$0.001 / 1M
Row writes50M/month$1.00 / 1M
Stored data5 GB-month$0.20 / GB-month

Key-Value Storage (Paid only, legacy):

MetricIncludedOverage
Read units1M$0.20 / 1M
Write units1M$1.00 / 1M
Delete requests1M$1.00 / 1M
Stored data1 GB$0.20 / GB-month

Free plan (since April 7, 2025):

- 100,000 requests/day
- 13,000 GB-seconds/day
- 5M SQLite row reads/day / 100K writes/day / 5 GB stored
- SQLite backend only (KV backend is Paid-only)

Special considerations:

- setAlarm() counts as one row write
- An empty database still consumes about 12 KB minimum storage
- Internal SQLite metadata also counts toward storage limits
- WebSocket Hibernation — idle instances do not accrue duration charges

WebSocket Hibernation — Cheap Long-Lived Sessions

The Hibernation API is what makes Durable Objects economically compelling. Ordinary WebSocket servers accrue duration for the whole connection lifetime; with Hibernation, duration billing stops while no messages flow and resumes automatically when a message arrives.

Practical shapes:

- Chat: a user who doesn't type for an hour costs nothing; typing wakes the object immediately
- LLM conversation history: DO wakes on session start, hibernates while the user thinks, wakes on the next message
- Live notifications: for sparse event streams, effectively "pay only when events fire"

Combined with the October 25, 2025 lift of WebSocket message size from 1 MiB to 32 MiB, you can now do large streaming + hibernation in the same object (LLM long-form output, video chunks).

Architecture — Single-Master Semantics, Explained

The Rules of Durable Objects capture the important invariants:

1. A named DO is globally unique — no parallel running of the same name in multiple processes
2. Order is preserved — sequential requests to the same DO are processed in order
3. Strong consistency — a write is visible to subsequent reads immediately
4. Geographic locality — the DO runs near the region of first access (and tends to stay put)
5. Failure re-hosting — if the machine dies, the DO is rescheduled elsewhere with its storage attached

Because of these invariants, distributed locks, counters, rate limiters, and event sourcing turn into a few dozen lines of code — replacing what used to be Zookeeper / etcd / Redis Cluster territory with a single primitive.

Representative Use Cases

(1) LLM agents and conversation history: model each session as a DO, log messages to SQLite, hibernate between messages. This is essentially the backend shape of Claude Code and Cursor iOS.

(2) Collaborative editing: one DO per document, OT/CRDT state in SQLite, single-master consistency for tens to hundreds of concurrent editors. Notion / Figma-class.

(3) Real-time chat: one DO per room, message history in SQLite, WebSocket Hibernation to hold cost down. Discord / Slack-shaped applications.

(4) Multiplayer games: one DO per room, player state and score in SQLite, single-master by construction. Cloudflare has published case studies.

(5) IoT / financial event buffering: one DO per device or account, buffered event stream in SQLite, deterministic order and single-master semantics.

(6) Distributed counters / rate limiters: one DO per user or API key, atomic counter updates. What used to require Zookeeper / Redis Cluster becomes dozens of lines.

(7) Per-tenant SaaS databases: one DO per tenant with full data isolation and SQL, up to 10 GB per object. Multi-tenant design becomes structurally simpler.

Position Inside Cloudflare Workers

Cloudflare's platform primitives:

ProductRoleConsistency
WorkersStateless compute (HTTP handler)N/A
KVEventually-consistent key-valueDelayed propagation (read-heavy)
D1SQLite (global or regional)Read-replica-based
R2Object storage (S3-compatible)S3-class
QueuesMessage queueAt-least-once
Durable ObjectsStateful, single-master, strongly consistentStrong consistency

Durable Objects owns the "strong consistency + single master + low latency" corner. D1 can be eventually stale on read replicas; DO's uniqueness removes that ambiguity.

Comparison Against Other Platforms

PlatformEquivalentGap vs DO
AWSActor framework + DynamoDB / EFSYou build the routing and replication
AzureDurable Functions (Entity Function).NET / language limits, worse cold-start
Google CloudFirestore + Cloud FunctionsSingle-master is opt-in; higher latency
Deno DeployNone (Deno KV is eventually consistent)
Vercel Edge FunctionsNone (stateless)
Fly.ioRegional VMs + LiteFSVM cold-start cost

What makes DO unique: "name-addressed compute co-located with SQLite" simply doesn't exist as a primitive on other platforms. Azure Durable Functions is the closest, but is limited by language, cold-start, and non-co-located storage.

Sample Code — Skeleton of a Chat Room

ts
export class ChatRoom {
  sql: SqlStorage;
  sockets: Set<WebSocket> = new Set();

  constructor(state: DurableObjectState) {
    this.sql = state.storage.sql;
    this.sql.exec(`CREATE TABLE IF NOT EXISTS messages (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      user TEXT, body TEXT, ts INTEGER
    )`);
  }

  async fetch(req: Request): Promise<Response> {
    if (req.headers.get('upgrade') === 'websocket') {
      const pair = new WebSocketPair();
      // Hibernation API — low-cost long connections
      this.state.acceptWebSocket(pair[1]);
      return new Response(null, { status: 101, webSocket: pair[0] });
    }
    const rows = this.sql.exec('SELECT * FROM messages ORDER BY id DESC LIMIT 50').toArray();
    return Response.json(rows);
  }

  webSocketMessage(ws: WebSocket, msg: string) {
    const { user, body } = JSON.parse(msg);
    this.sql.exec('INSERT INTO messages (user, body, ts) VALUES (?, ?, ?)',
      user, body, Date.now());
    for (const s of this.sockets) s.send(msg);
  }
}

// The Worker
export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const roomId = new URL(req.url).pathname.slice(1);
    const stub = env.CHAT_ROOM.getByName(roomId);
    return stub.fetch(req);
  }
};

What this code gets you:

- One globally-unique instance per room (getByName)
- WebSocket connections managed via Hibernation API — zero duration cost while idle
- Persistent message history in SQLite — last 50 messages returned on reconnect
- Single-master by construction — no ordering, consistency, or race issues

The equivalent in Node.js + Redis + Postgres would be hundreds of lines of infrastructure code plus operational overhead.

Operational Caveats

(1) Single-master scalability ceiling: one DO is one instance. Very high per-DO throughput (tens of thousands req/s) is not the design point. Shard across multiple DOs when needed.

(2) Geographic tradeoff: a DO runs near its first-access region, so remote traffic sees higher latency. Pair with KV or D1 read replicas for globally-distributed reads.

(3) Storage billing (from January 7, 2026): SQLite storage that was previously free now bills over the free tier. Budget against the 5 GB/day free tier and the 5 GB-month included Paid tier.

(4) Vendor lock-in: DO is a Cloudflare-specific primitive. Porting to other clouds is hard. You're making a strategic bet on Cloudflare's platform.

(5) Cold start: first-touch access takes a few hundred ms. Frequently accessed DOs stay warm, but sparse-access DOs may cold-start each time.

(6) setAlarm() billing: each alarm counts as one write, so many alarms drive costs up. Batch or coalesce.

Strategic Context — 2026 Edge Distributed-Platform Market

In 2026, edge computing has moved from "CDN plus" to "full distributed application platform". Cloudflare's portfolio (Workers, D1, R2, KV, Queues, Durable Objects) is a legitimate alternative to AWS-style distributed backends.

Where DO sits in 2026:

1. The default session store for the LLM era — natural backend for local LLMs, Claude Sonnet 5, Cursor iOS, Grok Build
2. Per-tenant DB for multi-tenant SaaS — collapses the tenant-isolation problem
3. Differentiator against pure-stateless edge (Vercel / Netlify) — enables use cases they can't touch
4. AWS Lambda + DynamoDB + API Gateway WebSockets + ElastiCache collapsed into a single primitive

Related services from us — software development, AI consulting, and OpenClaw setup. For help designing Cloudflare-Workers-based edge apps, LLM-session management, or multi-tenant SaaS implementations using Durable Objects, get in touch.

Bottom Line

Cloudflare Durable Objects is, as of 2026, the platform primitive that most completely folds "distributed-system complexity" into a single API. SQLite co-location for zero-latency access, name-based global-unique routing, WebSocket Hibernation economics, Workers Free-tier availability, and January-7-2026 storage-billing closure of the economic loop — the five pieces are now all in place. The commercial-adoption phase is here.

Three enduring impacts:

1. Democratization of distributed-system design — Zookeeper / etcd / Redis Cluster–class complexity in dozens of lines
2. Default session backend for the LLM era — sits under Claude Code, Cursor iOS, agmsg naturally
3. Per-tenant DB pattern for multi-tenant SaaS — tenant isolation as a structural property, not a design chore

Caveats: single-master scalability ceilings, geographic tradeoffs, Cloudflare-specific vendor lock-in, cold-start on sparse access, and the need to design around setAlarm() billing.

References

Official docs:
- Durable Objects Overview
- What are Durable Objects?
- Product Page
- Pricing
- SQLite Storage API
- Access Durable Objects Storage
- Rules of Durable Objects
- FAQ
- Release Notes

Cloudflare blog:
- Zero-latency SQLite storage in every Durable Object

Third-party:
- FlareCalc — Durable Objects Pricing Calculator (2026)
- Oreate AI — Demystifying Durable Objects Pricing
- Callsphere — Workers + Durable Objects at 10k Concurrent
- Alphonso Labs — 12 Edge Computing Trends in 2026

Related columns:
- Local LLM June 2026 Update
- agmsg — cross-vendor CLI agent messaging
- Sakana Fugu — orchestration model
- Apple Container — Linux container runtime
- Claude Code Agent View — parallel orchestration
- Cursor iOS — mobile coding agent
- Claude Sonnet 5 release
- Grok Build — xAI CLI coding agent
- Open GENAI — Digital Agency OSS

Feel free to contact us

Contact Us