Limits

Durable Objects are only available on the Workers Paid plan. Durable Objects limits are the same as Workers Limits, as well as the following limits that are specific to Durable Objects:

Feature	Limit for class with key-value storage backend	Limit for class with SQLite storage backend 1
Number of Objects	Unlimited (within an account or of a given class)	Unlimited (within an account or of a given class)
Maximum Durable Object namespaces	500 (identical to the script limit)	500 (identical to the script limit)
Storage per account	50 GB (can be raised by contacting Cloudflare) 2	50 GB (can be raised by contacting Cloudflare) 2
Storage per class	Unlimited	Unlimited
Storage per Durable Object	Unlimited	1 GB 3
Key size	2 KiB (2048 bytes)	Key and value combined cannot exceed 2 MB
Value size	128 KiB (131072 bytes)	Key and value combined cannot exceed 2 MB
WebSocket message size	1 MiB (only for received messages)	1 MiB (only for received messages)
CPU per request	30s (including WebSocket messages) 4	30s (including WebSocket messages) 4

For Durable Object classes with SQLite storage backend these SQL limits apply:

SQL	Limit
Maximum number of columns per table	100
Maximum number of rows per table	Unlimited (excluding per-object storage limits)
Maximum string, BLOB or table row size	2 MB
Maximum SQL statement length	100 KB
Maximum bound parameters per query	100
Maximum arguments per SQL function	32
Maximum characters (bytes) in a LIKE or GLOB pattern	50 bytes

Need a higher limit?

To request an adjustment to a limit, complete the Limit Increase Request Form ↗. If the limit can be increased, Cloudflare will contact you with next steps.

How much work can a single Durable Object do?

Durable Objects can scale horizontally across many Durable Objects. Each individual Object is inherently single-threaded.

• An individual Object has a soft limit of 1,000 requests per second. You can have an unlimited number of individual objects per namespace.
• A simple storage get() on a small value that directly returns the response may realize a higher request throughput compared to a Durable Object that (for example) serializes and/or deserializes large JSON values.
• Similarly, a Durable Object that performs multiple list() operations may be more limited in terms of request throughput.

A Durable Object that receives too many requests will, after attempting to queue them, return an overloaded error to the caller.

How many Durable Objects can I create?

Durable Objects are designed such that the number of individual objects in the system do not need to be limited, and can scale horizontally.

• You can create and run as many separate Durable Objects as you want within a given Durable Object namespace.
• The main limit to your usage of Durable Objects is the total storage limit per account.
• If you need more storage, contact your account team or complete the Limit Increase Request Form ↗ and we will contact you with next steps.

Footnotes

1. The new beta version of Durable Objects is available where each Durable Object has a private, embedded SQLite database. When creating a Durable Object class, users can opt-in to using SQL storage. ↩

2. Durable Objects both bills and measures storage based on a gigabyte
   (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB).
   ↩ ↩²

3. Will be raised to 10 GB for general availability. ↩

4. Each incoming HTTP request or WebSocket message resets the remaining available CPU time to 30 seconds. This allows the Durable Object to consume up to 30 seconds of compute after each incoming network request, with each new network request resetting the timer. If you consume more than 30 seconds of compute between incoming network requests, there is a heightened chance that the individual Durable Object is evicted and reset. ↩ ↩²