durable-objects

Extend the DurableObject class from cloudflare:workers and configure new_sqlite_classes in your wrangler migrations. Initialize tables inside the constructor using ctx.blockConcurrencyWhile and access storage synchronously via this.ctx.storage.sql.exec.

Use @cloudflare/vitest-pool-workers with defineWorkersConfig pointing at your wrangler config. Access stubs via env from cloudflare:test, inspect internals with runInDurableObject, and trigger alarms instantly with runDurableObjectAlarm.

Use Durable Objects when you need coordination, strong consistency, per-entity storage, persistent WebSocket connections, or scheduled per-entity work. Plain Workers are better for stateless request handling and maximum global distribution.

No, PRAGMA user_version is not supported in Durable Objects SQLite storage. Track schema versions in a dedicated _sql_schema_migrations table and apply incremental migrations during constructor initialization.

A single global DO becomes a throughput bottleneck because all requests serialize through one instance. Model around coordination atoms instead, creating one DO per chat room, game, or user with getByName for deterministic routing.

No, each Durable Object supports only one alarm at a time, and calling setAlarm replaces any existing alarm. Reschedule the next alarm inside the alarm handler after processing due work.