[DO] Updating limits to be accurate (#21786)

Oxyjun · marciocloudflare · RebeccaTamachiro · commit d421c75acf11 · 2025-04-21T11:07:05.000+01:00
* Updating Storage products mentioned in Workers
docs to be accurate.

* Apply suggestions from code review

Co-authored-by: marciocloudflare &lt;83226960+marciocloudflare@users.noreply.github.com&gt;

---------

Co-authored-by: marciocloudflare &lt;83226960+marciocloudflare@users.noreply.github.com&gt;
diff --git a/src/content/docs/d1/platform/limits.mdx b/src/content/docs/d1/platform/limits.mdx
@@ -6,16 +6,16 @@ sidebar:
 
 ---
 
-import { Render } from "~/components";
+import { Render, Details } from "~/components";
 
 | Feature                                                                                                             | Limit                                             |
 | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
-| Databases                                                                                                           | 50,000 (Workers Paid)[^1] / 10 (Free)                 |
+| Databases                                                                                                           | 50,000 (Workers Paid)[^1] / 10 (Free)             |
 | Maximum database size                                                                                               | 10 GB (Workers Paid) / 500 MB (Free)              |
 | Maximum storage per account                                                                                         | 250 GB (Workers Paid)[^1] / 5 GB (Free)           |
 | [Time Travel](/d1/reference/time-travel/) duration (point-in-time recovery)                                         | 30 days (Workers Paid) / 7 days (Free)            |
 | Maximum Time Travel restore operations                                                                              | 10 restores per 10 minute (per database)          |
-| Queries per Worker invocation (read [subrequest limits](/workers/platform/limits/#how-many-subrequests-can-i-make)) | 50 (Free) / 1000 (Paid)                     |
+| Queries per Worker invocation (read [subrequest limits](/workers/platform/limits/#how-many-subrequests-can-i-make)) | 50 (Free) / 1000 (Paid)                           |
 | Maximum number of columns per table                                                                                 | 100                                               |
 | Maximum number of rows per table                                                                                    | Unlimited (excluding per-database storage limits) |
 | Maximum string, `BLOB` or table row size                                                                            | 2,000,000 bytes (2 MB)                            |
@@ -25,20 +25,27 @@ import { Render } from "~/components";
 | Maximum characters (bytes) in a `LIKE` or `GLOB` pattern                                                            | 50 bytes                                          |
 | Maximum bindings per Workers script                                                                                 | Approximately 5,000 [^2]                          |
 | Maximum SQL query duration                                                                                          | 30 seconds [^3]                                   |
-| Maximum file import (`d1 execute`) size                                                                             | 5 GB [^4]                                        |
+| Maximum file import (`d1 execute`) size                                                                             | 5 GB [^4]                                         |
 
 :::note[Batch limits]
 Limits for individual queries (listed above) apply to each individual statement contained within a batch statement. For example, the maximum SQL statement length of 100 KB applies to each statement inside a `db.batch()`.
 :::
 
 [^1]: The maximum storage per account can be increased by request on Workers Paid and Enterprise plans. See the guidance on limit increases on this page to request an increase.
-
 [^2]: A single Worker script can have up to 1 MB of script metadata. A binding is defined as a binding to a resource, such as a D1 database, KV namespace, environmental variable or secret. Each resource binding is approximately 150-bytes, however environmental variables and secrets are controlled by the size of the value you provide. Excluding environmental variables, you can bind up to \~5,000 D1 databases to a single Worker script.
-
 [^3]: Requests to Cloudflare API must resolve in 30 seconds. Therefore, this duration limit also applies to the entire batch call.
-
 [^4]: The imported file is uploaded to R2. See [R2 upload limit](/r2/platform/limits).
 
+<Details header = "Footnotes" open={true}>
+1: The maximum storage per account can be increased by request on Workers Paid and Enterprise plans. See the guidance on limit increases on this page to request an increase.
+
+2: A single Worker script can have up to 1 MB of script metadata. A binding is defined as a binding to a resource, such as a D1 database, KV namespace, environmental variable or secret. Each resource binding is approximately 150 bytes, however environmental variables and secrets are controlled by the size of the value you provide. Excluding environmental variables, you can bind up to \~5,000 D1 databases to a single Worker script.
+
+3: Requests to Cloudflare API must resolve in 30 seconds. Therefore, this duration limit also applies to the entire batch call.
+
+4: The imported file is uploaded to R2. See [R2 upload limit](/r2/platform/limits).
+</Details>
+
 Cloudflare also offers other storage solutions such as [Workers KV](/kv/api/), [Durable Objects](/durable-objects/), and [R2](/r2/get-started/). Each product has different advantages and limits. Refer to [Choose a data or storage product](/workers/platform/storage-options/) to review which storage option is right for your use case.
 
 <Render file="limits_increase" product="workers" />
diff --git a/src/content/docs/durable-objects/platform/limits.mdx b/src/content/docs/durable-objects/platform/limits.mdx
@@ -24,14 +24,19 @@ Durable Objects are a special kind of Worker, so [Workers Limits](/workers/platf
 | WebSocket message size                   | 1 MiB (only for received messages)                          |
 | CPU per request                          | 30 seconds (default) / configurable to 5 minutes of [active CPU time](/workers/platform/limits/#cpu-time) [^4] |
 
+[^1]: Identical to the Workers [script limit](/workers/platform/limits/).
+[^2]: Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
+[^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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
+
 <Details header="Footnotes" open={true}>
-1: Identical to the Workers [script limit](/workers/platform/limits/)
+1. Identical to the Workers [script limit](/workers/platform/limits/).
 
-2: Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
+2. Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
 
-3: Accounts on the Workers Free plan are limited to 5GB total Durable Objects storage.
+3. Accounts on the Workers Free plan are limited to 5GB 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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
+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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
 </Details>
 
 ### SQL storage limits
@@ -55,21 +60,25 @@ For Durable Object classes with [SQLite storage](/durable-objects/api/storage-ap
 | 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           | 500 (Workers Paid) / 100 (Free) [^1]                             |
-| Storage per account                      | 50 GB (can be raised by contacting Cloudflare) [^2]              |
+| Maximum Durable Object classes           | 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                   | 1 MiB (only for received messages)                               |
-| CPU per request                          | 30s (including WebSocket messages) [^3]                          |
+| CPU per request                          | 30s (including WebSocket messages) [^7]                          |
+
+[^5]: Identical to the Workers [script limit](/workers/platform/limits/).
+[^6]: Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
+[^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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
 
-<Details header="Footnotes">
-1: Identical to the Workers [script limit](/workers/platform/limits/)
+<Details header="Footnotes" open={true}>
+5. Identical to the Workers [script limit](/workers/platform/limits/).
 
-2: Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
+6. Durable Objects both bills and measures storage based on a gigabyte <br/> (1 GB = 1,000,000,000 bytes) and not a gibibyte (GiB). <br/>
 
-3: 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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
+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](/durable-objects/platform/limits/#increasing-durable-object-cpu-limits).
 </Details>
 
 <Render file="limits_increase" product="workers" />
diff --git a/src/content/docs/workers/platform/storage-options.mdx b/src/content/docs/workers/platform/storage-options.mdx
@@ -9,7 +9,7 @@ head:
 description: Storage and database options available on Cloudflare's developer platform.
 ---
 
-import { Render } from "~/components";
+import { Render, Details } from "~/components";
 
 Cloudflare Workers support a range of storage and database options for persisting different types of data across different use-cases, from key-value stores (like [Workers KV](/kv/)) through to SQL databases (such as [D1](/d1/)). This guide describes the use-cases suited to each storage option, as well as their performance and consistency properties.
 
@@ -44,24 +44,34 @@ The following table highlights the performance and consistency characteristics o
 
 | Feature                     | Workers KV                                       | R2                                    | Durable Objects                  | D1                                                  |
 | --------------------------- | ------------------------------------------------ | ------------------------------------- | -------------------------------- | --------------------------------------------------- |
-| Maximum storage per account | Unlimited<sup>1</sup>                            | Unlimited<sup>2</sup>                 | 50 GiB                           | 250GiB <sup>3</sup>                                 |
+| Maximum storage per account | Unlimited [^1]                                   | Unlimited [^2]                        | Unlimited [^3]                   | 250 GB [^4]                                         |
 | Storage grouping name       | Namespace                                        | Bucket                                | Durable Object                   | Database                                            |
-| Maximum size per value      | 25 MiB                                           | 5 TiB per object                      | 128 KiB per value                | 10 GiB per database <sup>4</sup>                    |
-| Consistency model           | Eventual: updates take up to 60s to be reflected | Strong (read-after-write)<sup>5</sup> | Serializable (with transactions) | Serializable (no replicas) / Causal (with replicas) |
+| Maximum size per value      | 25 MiB                                           | 5 TiB per object                      | 128 KiB per value                | 10 GB per database [^5]                             |
+| Consistency model           | Eventual: updates take up to 60s to be reflected | Strong (read-after-write) [^6]        | Serializable (with transactions) | Serializable (no replicas) / Causal (with replicas) |
 | Supported APIs              | Workers, HTTP/REST API                           | Workers, S3 compatible                | Workers                          | Workers, HTTP/REST API                              |
 
 </table-wrap>
 
-<sup>1</sup> Free accounts are limited to 1 GiB of KV storage.
+[^1]: Free accounts are limited to 1 GiB of KV storage.
+[^2]: Free accounts are limited to 10 GB of R2 storage.
+[^3]: Free accounts are limited to 5 GB of storage for SQLite-backed Durable Objects. 50 GB limit applies for KV-backed Durable Objects. Refer to [Durable Objects limits](/durable-objects/platform/limits/).
+[^4]: Free accounts are limited to 5 GB of database storage.
+[^5]: Free accounts are limited to 500 MB per database.
+[^6]: Refer to the [R2 documentation](/r2/reference/consistency/) for more details on R2's consistency model.
 
-<sup>2</sup> Free accounts are limited to 10 GB of R2 storage.
+<Details header= "Footnotes" open = {true}>
+1. Free accounts are limited to 1 GiB of KV storage.
 
-<sup>3</sup> Free accounts are limited to 5 GiB of database storage.
+2. Free accounts are limited to 10 GB of R2 storage.
 
-<sup>4</sup> Free accounts are limited to 500 MiB per database.
+3. Free accounts are limited to 5 GB of storage for SQLite-backed Durable Objects. 50 GB limit applies for KV-backed Durable Objects. Refer to [Durable Objects limits](/durable-objects/platform/limits/).
 
-<sup>5</sup> Refer to the [R2 documentation](/r2/reference/consistency/) for
-more details on R2's consistency model.
+4. Free accounts are limited to 5 GB of database storage.
+
+5. Free accounts are limited to 500 MB per database.
+
+6. Refer to the [R2 documentation](/r2/reference/consistency/) for more details on R2's consistency model.
+</Details>
 
 <Render file="limits_increase" />
 
