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 |
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.
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.
-
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. ↩
-
Durable Objects both bills and measures storage based on a gigabyte
(1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB).
↩ ↩2 -
Will be raised to 10 GB for general availability. ↩
-
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. ↩ ↩2