workerd error: durable object storage limit exceeded, writes rejected

Fix durable object storage limit exceeded, writes rejected

TL;DR

Each Durable Object instance is limited to 128 MB of storage. List the stored keys, delete what is stale, and move large blobs to R2, keeping only pointers in the object. Then add a TTL or alarm-based cleanup so the storage does not fill up again.

Verbatim error

workerd error: durable object storage limit exceeded, writes rejected

Steps

1. Inside the Durable Object, list keys with await this.state.storage.list() and tally counts and sizes. Expected: you see which keys hold the bulk of the data.
2. Delete stale keys: await this.state.storage.deleteAll() for a full reset, or delete by key prefix for targeted cleanup. Expected: storage usage drops well under the limit.
3. Move large values (files, payloads, histories) to R2 and store only the R2 keys in the Durable Object. Expected: the object's storage stays small.
4. Add a cleanup path in the object code: TTL on writes or a periodic alarm that sweeps old keys. Expected: growth is bounded going forward.
5. Add a log line reporting storage size on writes so you catch growth early. Expected: you see the trend before the limit is hit.

Use this when

• A Durable Object throws "storage limit exceeded, writes rejected"
• A per-user or per-room object that accumulates history stops accepting writes
• Storage grows without bound and never gets cleaned up

Not for this skill when

• The error is a CPU time or memory limit (different limits, different fixes)
• The quota problem is in R2 or KV, not the object
• Writes fail with transaction abort errors (concurrency, not capacity)

Variant phrasings

• durable object 128mb limit
• DO storage full
• "writes rejected" durable object
• durable object out of storage

Why it happens

Durable Object storage is a per-instance SQLite database capped at 128 MB. Append-only patterns - event logs, caches that never expire, ever-growing session state - eventually hit the cap, and from that point every write is rejected until space is freed.

Edge cases

• deleteAll() frees the quota immediately even though the underlying file shrinks lazily.
• Alarm-based cleanup only works if the alarm actually fires; test the alarm path explicitly.
• Many small keys carry per-key overhead, so batch related data into fewer, larger values where it makes sense.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gn83hclJuYlWJ7CN1XcXwQ