Check Durable Object Storage Before Your Next Cloudflare Worker Deploy

Cloudflare has changed the default path for new Durable Object namespaces. Confidence level: confirmed. Accounts without an existing key-value backed Durable Object namespace can no longer create new KV-backed namespaces and must use the SQLite storage backend instead.

What changed

Cloudflare says that, as of its July 9, 2026 changelog entry, affected accounts must create new Durable Object namespaces with the SQLite storage backend. The change applies to accounts that do not already have a key-value backed Durable Object namespace.

Existing accounts with at least one KV-backed namespace can still create new KV-backed namespaces for now. Cloudflare frames the move as part of a broader shift toward SQLite as the single Durable Objects storage backend, ahead of a future migration path for existing KV-backed objects.

Key takeaways

• New Durable Object namespaces on affected accounts must use SQLite-backed storage.
• The deployment failure appears when a new KV-backed class migration is attempted on an affected account.
• SQLite-backed Durable Objects keep the key-value storage API and add SQL queries plus point-in-time recovery.
• Existing KV-backed namespaces are not automatically migrated by this announcement.
• Teams should review Wrangler migrations before shipping new Worker environments.

Availability and access

This is already in effect for accounts that do not have an existing KV-backed Durable Object namespace. Cloudflare's changelog says those accounts should use a new_sqlite_classes migration instead of a new_classes migration.

Cloudflare also says SQLite-backed Durable Objects support the key-value storage API, relational SQL queries, and point-in-time recovery for restoring an object's storage to any point in the previous 30 days. Pricing and account-specific limits should still be checked against the current Cloudflare Workers documentation before a production rollout.

Practical LinkLoot angle

The deployment risk sits in templates, starter projects, CI jobs, and environment bootstrap scripts that still assume KV-backed Durable Object creation. That can break a fresh staging account or a new customer environment even when the same Worker deploys successfully in an older account.

For teams building AI agents, queues, collaborative apps, multiplayer state, or workflow coordinators on Workers, the safer move is to treat SQLite-backed Durable Objects as the default baseline. Keep storage assumptions explicit in your setup notes, Terraform modules, and Wrangler migrations.

Use LinkLoot's AI workflow automation guide if you are mapping where persistent agent state, retries, and audit logs should live before moving more work into Workers.

What to verify before you act

• Check whether the target Cloudflare account already has a KV-backed Durable Object namespace.
• Inspect wrangler.jsonc, wrangler.toml, and migrations for new_classes versus new_sqlite_classes.
• Test a fresh environment deploy as well as updates to older accounts.
• Review whether your code depends only on the key-value API or should use SQL and point-in-time recovery.
• Watch Cloudflare's Durable Objects docs for the promised migration path for existing KV-backed objects.

Source check

Confirmed by:

• Cloudflare's July 9, 2026 changelog states that affected accounts can no longer create new KV-backed Durable Object namespaces and must use SQLite-backed namespaces.
• Cloudflare's Durable Objects migrations documentation describes the SQLite-backed class migration path.
• Cloudflare's SQLite storage API documentation explains the storage backend model and supported APIs.

Early signal / context:

• The changelog says this is part of a broader move toward SQLite as the single Durable Objects storage backend, but Cloudflare has not yet published the full migration path for existing KV-backed objects in the checked sources.