Limits

Durable Objects are a special kind of Worker, so Workers Limits apply according to your Workers plan. In addition, Durable Objects have specific limits as listed in this page.

SQLite-backed Durable Objects general limits

Feature	Limit
Number of Objects	Unlimited (within an account or of a given class)
Maximum Durable Object classes (per account)	500 (Workers Paid) / 100 (Free) 1
Storage per account	Unlimited (Workers Paid) / 5GB (Free) 2
Storage per class	Unlimited 3
Storage per Durable Object	10 GB 3
Key size	Key and value combined cannot exceed 2 MB
Value size	Key and value combined cannot exceed 2 MB
WebSocket message size	32 MiB (only for received messages)
CPU per request	30 seconds (default) / configurable to 5 minutes of active CPU time 4

SQL storage limits

For Durable Object classes with SQLite storage 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

Key-value backed Durable Objects general limits

Note

Durable Objects are available both on Workers Free and Workers Paid plans.

• Workers Free plan: Only Durable Objects with SQLite storage backend are available.
• Workers Paid plan: Durable Objects with either SQLite storage backend or key-value storage backend are available.

If you wish to downgrade from a Workers Paid plan to a Workers Free plan, you must first ensure that you have deleted all Durable Object namespaces with the key-value storage backend.

Feature	Limit for class with key-value storage backend
Number of Objects	Unlimited (within an account or of a given class)
Maximum Durable Object classes (per account)	500 (Workers Paid) / 100 (Free) 5
Storage per account	50 GB (can be raised by contacting Cloudflare) 6
Storage per class	Unlimited
Storage per Durable Object	Unlimited
Key size	2 KiB (2048 bytes)
Value size	128 KiB (131072 bytes)
WebSocket message size	32 MiB (only for received messages)
CPU per request	30s (including WebSocket messages) 7

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.

Frequently Asked Questions

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.
• There are no limits for storage per account when using SQLite-backed Durable Objects on a Workers Paid plan.
• Each SQLite-backed Durable Object has a storage limit of 10 GB on a Workers Paid plan.
• Refer to Durable Object limits for more information.

Can I increase Durable Objects' CPU limit?

Durable Objects are Worker scripts, and have the same per invocation CPU limits as any Workers do. Note that CPU time is active processing time: not time spent waiting on network requests, storage calls, or other general I/O, which don't count towards your CPU time or Durable Objects compute consumption.

By default, the maximum CPU time per Durable Objects invocation (HTTP request, WebSocket message, or Alarm) is set to 30 seconds, but can be increased for all Durable Objects associated with a Durable Object definition by setting limits.cpu_ms in your Wrangler configuration:

wrangler.jsonc

{
  // ...rest of your configuration...
  "limits": {
    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
  },
  // ...rest of your configuration...
}

wrangler.toml

[limits]
cpu_ms = 300_000

Wall time limits by invocation type

Wall time (also called wall-clock time) is the total elapsed time from the start to end of an invocation, including time spent waiting on network requests, I/O, and other asynchronous operations. This is distinct from CPU time, which only measures time the CPU spends actively executing your code.

The following table summarizes the wall time limits for different types of Worker invocations across the developer platform:

Invocation type	Wall time limit	Details
Incoming HTTP request	Unlimited	No hard limit while the client remains connected. When the client disconnects, tasks are canceled unless you call waitUntil() to extend execution by up to 30 seconds.
Cron Triggers	15 minutes	Scheduled Workers have a maximum wall time of 15 minutes per invocation.
Queue consumers	15 minutes	Each consumer invocation has a maximum wall time of 15 minutes.
Durable Object alarm handlers	15 minutes	Alarm handler invocations have a maximum wall time of 15 minutes.
Durable Objects (RPC / HTTP)	Unlimited	No hard limit while the caller stays connected to the Durable Object.
Workflows (per step)	Unlimited	Each step can run for an unlimited wall time. Individual steps are subject to the configured CPU time limit.

Footnotes

1. Identical to the Workers script limit. ↩

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. Accounts on the Workers Free plan are limited to 5 GB total Durable Objects storage. ↩ ↩²

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. CPU time per request invocation can be increased. ↩

5. Identical to the Workers script limit. ↩

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

7. 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. CPU time per request invocation can be increased. ↩