[Durable Objects] Creating a new consolidated FAQ page, using partials

src/content/docs/durable-objects/platform/limits.mdx

@@ -85,40 +85,4 @@ For Durable Object classes with [SQLite storage](/durable-objects/api/storage-ap
 
 ## 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](/durable-objects/api/storage-api/) `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](/durable-objects/observability/troubleshooting/#durable-object-is-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 <GlossaryTooltip term="namespace">namespace</GlossaryTooltip>.
-- 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](https://forms.gle/ukpeZVLWLnKeixDu7) and we will contact you with next steps.
-
-### Increasing Durable Object CPU limits
-
-Durable Objects are Worker scripts, and have the same [per invocation CPU limits](/workers/platform/limits/#worker-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:
-
-<WranglerConfig>
-
-```jsonc
-{
-  // ...rest of your configuration...
-  "limits": {
-    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
-  },
-  // ...rest of your configuration...
-}
-```
-
-</WranglerConfig>
+<Render file="do-faq-limits" product="durable-objects"/>

src/content/docs/durable-objects/platform/pricing.mdx

@@ -122,32 +122,4 @@ In this scenario, the estimated monthly cost would be calculated as:
 
 ## Frequently Asked Questions
 
-### Does an empty table / SQLite database contribute to my storage?
-
-Yes, although minimal. Empty tables can consume at least a few kilobytes, based on the number of columns (table width) in the table. An empty SQLite database consumes approximately 12 KB of storage.
-
-### Does metadata stored in Durable Objects count towards my storage?
-
-All writes to a SQLite-backed Durable Object stores nominal amounts of metadata in internal tables in the Durable Object, which counts towards your billable storage.
-
-The metadata remains in the Durable Object until you call [`deleteAll()`](/durable-objects/api/storage-api/#deleteall).
-
-### When does a Durable Object incur duration charges?
-
-A Durable Object incurs duration charges as long as the JavaScript object is held in memory. Once an object has been evicted from memory, the next time it is needed, it will be recreated (calling the constructor again). There are two factors which decide when an object may be evicted from memory: hibernatability and existence of clients.
-
-A Durable Object is considered hibernatable any time that it is not waiting for any I/O or callbacks that depend on the in-memory state. 
-
-- For example, if an object calls `fetch()` and awaits the response, it is considered to be waiting for I/O, and so cannot hibernate. 
-
-- Less obvious to a user, if an object calls `setTimeout()` to schedule a callback in the future - no matter how far in the future - then it is considered non-hibernatable, since there would be no way to recreate the callback after hibernating. 
-
-- Additionally, if the Durable Object has received an incoming request and has not fully responded yet, then it cannot be hibernated, because hibernating would mean losing track of the async function which is eventually supposed to return a response to that request.
-
-- As an exception, a WebSocket request which has explicitly been accepted using the [WebSocket hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) allows a Durable Object to hibernate even while the WebSocket is still connected.
-
-
-
-Once a Durable Object has been in a hibernatable state for 10 consecutive seconds, it hibernates, and duration billing stops.
-
-Even if a Durable Object never becomes hibernatable, it will still be evicted once all clients have gone away. A Durable Object is considered to have clients if any other Worker currently holds a stub pointing to the Durable Object, or is waiting for a response from the Durable Object. An incoming WebSocket connection counts as a client. If the object is currently responding to an alarm event, this also counts as having a client. When not hibernatable, a Durable Object will be evicted from memory after it has had no client for 70-140 seconds (the exact interval varies). But again, if the object is hibernatable, then the 10-second hibernation timeout takes precedence and the 70-140 second no-client timeout is moot.
+<Render file="do-faq-pricing" product="durable-objects"/>

src/content/docs/durable-objects/reference/faq.mdx

@@ -0,0 +1,18 @@
+---
+title: Frequently Asked Questions
+pcx_content_type: concept
+sidebar:
+  order: 12
+
+---
+
+import { Render } from "~/components";
+
+## Pricing
+
+<Render file="do-faq-pricing" product="durable-objects"/>
+
+## Limits
+
+<Render file="do-faq-limits" product="durable-objects"/>
+

src/content/partials/durable-objects/do-faq-limits.mdx

@@ -0,0 +1,44 @@
+---
+{}
+---
+
+import {GlossaryTooltip, WranglerConfig} from "~/components";
+
+### 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](/durable-objects/api/storage-api/) `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](/durable-objects/observability/troubleshooting/#durable-object-is-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 <GlossaryTooltip term="namespace">namespace</GlossaryTooltip>.
+- 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](/durable-objects/platform/limits/) for more information.
+
+### Can I increase Durable Objects' CPU limit?
+
+Durable Objects are Worker scripts, and have the same [per invocation CPU limits](/workers/platform/limits/#worker-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:
+
+<WranglerConfig>
+
+```jsonc
+{
+  // ...rest of your configuration...
+  "limits": {
+    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
+  },
+  // ...rest of your configuration...
+}
+```
+
+</WranglerConfig>

src/content/partials/durable-objects/do-faq-pricing.mdx

@@ -0,0 +1,31 @@
+---
+{}
+---
+
+### When does a Durable Object incur duration charges?
+
+A Durable Object incurs duration charges as long as the JavaScript object is held in memory. Once an object has been evicted from memory, the next time it is needed, it will be recreated (calling the constructor again). There are two factors which decide when an object may be evicted from memory: hibernatability and existence of clients.
+
+A Durable Object is considered hibernatable any time that it is not waiting for any I/O or callbacks that depend on the in-memory state.
+
+- For example, if an object calls `fetch()` and awaits the response, it is considered to be waiting for I/O, and so cannot hibernate.
+
+- Less obvious to a user, if an object calls `setTimeout()` to schedule a callback in the future - no matter how far in the future - then it is considered non-hibernatable, since there would be no way to recreate the callback after hibernating.
+
+- Additionally, if the Durable Object has received an incoming request and has not fully responded yet, then it cannot be hibernated, because hibernating would mean losing track of the async function which is eventually supposed to return a response to that request.
+
+- As an exception, a WebSocket request which has explicitly been accepted using the [WebSocket hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) allows a Durable Object to hibernate even while the WebSocket is still connected.
+
+Once a Durable Object has been in a hibernatable state for 10 consecutive seconds, it hibernates, and duration billing stops.
+
+Even if a Durable Object never becomes hibernatable, it will still be evicted once all clients have gone away. A Durable Object is considered to have clients if any other Worker currently holds a stub pointing to the Durable Object, or is waiting for a response from the Durable Object. An incoming WebSocket connection counts as a client. If the object is currently responding to an alarm event, this also counts as having a client. When not hibernatable, a Durable Object will be evicted from memory after it has had no client for 70-140 seconds (the exact interval varies). But again, if the object is hibernatable, then the 10-second hibernation timeout takes precedence and the 70-140 second no-client timeout is moot.
+
+### Does an empty table / SQLite database contribute to my storage?
+
+Yes, although minimal. Empty tables can consume at least a few kilobytes, based on the number of columns (table width) in the table. An empty SQLite database consumes approximately 12 KB of storage.
+
+### Does metadata stored in Durable Objects count towards my storage?
+
+All writes to a SQLite-backed Durable Object stores nominal amounts of metadata in internal tables in the Durable Object, which counts towards your billable storage.
+
+The metadata remains in the Durable Object until you call [`deleteAll()`](/durable-objects/api/storage-api/#deleteall).