Pricing (30)·续1

In most cases, it takes 3 operations to deliver a message: 1 write, 1 read, and 1 delete. Therefore, you can use the following formula to estimate your monthly bill:

((Number of Messages * 3) - 1,000,000) / 1,000,000  * $0.40

Additionally:

• Each retry incurs a read operation. A batch of 10 messages that is retried would incur 10 operations for each retry.
• Messages that reach the maximum retries and that are written to a Dead Letter Queue incur a write operation for each 64 KB chunk. A message that was retried 3 times (the default), fails delivery on the fourth time and is written to a Dead Letter Queue would incur five (5) read operations.
• Messages that are written to a queue, but that reach the maximum persistence duration (or "expire") before they are read, incur only a write and delete operation per 64 KB chunk.

Queues billing examples

To learn more about Queues pricing and review billing examples, refer to Queues Pricing.

Workflows

Cloudflare will not bill step and storage usage before the start date announced in the Workflows billing changelog.

Workflows pricing

To learn more about Workflows billing, refer to Workflows pricing.

D1

D1 is available on both the Workers Free and Workers Paid plans.

Track your D1 usage

To accurately track your usage, use the meta object, GraphQL Analytics API, or the Cloudflare dashboard ↗︎. Select your D1 database, then view: Metrics > Row Metrics.

Definitions

1. Rows read measure how many rows a query reads (scans), regardless of the size of each row. For example, if you have a table with 5000 rows and run a SELECT * FROM table as a full table scan, this would count as 5,000 rows read. A query that filters on an unindexed column may return fewer rows to your Worker, but is still required to read (scan) more rows to determine which subset to return.
2. Rows written measure how many rows were written to D1 database. Write operations include INSERT, UPDATE, and DELETE. Each of these operations contribute towards rows written. A query that INSERT 10 rows into a users table would count as 10 rows written.
3. DDL operations (for example, CREATE, ALTER, and DROP) are used to define or modify the structure of a database. They may contribute to a mix of read rows and write rows. Ensure you are accurately tracking your usage through the available tools (meta object, GraphQL Analytics API, or the Cloudflare dashboard ↗︎).
4. Row size or the number of columns in a row does not impact how rows are counted. A row that is 1 KB and a row that is 100 KB both count as one row.
5. Defining indexes on your table(s) reduces the number of rows read by a query when filtering on that indexed field. For example, if the users table has an index on a timestamp column created_at, the query SELECT * FROM users WHERE created_at > ?1 would only need to read a subset of the table.
6. Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index. The performance benefit of an index and reduction in rows read will, in nearly all cases, offset this additional write.
7. Storage is based on gigabytes stored per month, and is based on the sum of all databases in your account. Tables and indexes both count towards storage consumed.
8. Free limits reset daily at 00:00 UTC. Monthly included limits reset based on your monthly subscription renewal date, which is determined by the day you first subscribed.
9. There are no data transfer (egress) or throughput (bandwidth) charges for data accessed from D1.
10. Read replication does not charge extra for read replicas. You incur the same usage billing based on rows_read and rows_written by your queries.

D1 billing

Refer to D1 Pricing to learn more about how D1 is billed.

Durable Objects

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 the SQLite storage backend are available. The key-value storage backend is only available to accounts that already have a key-value-backed namespace.

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.

Compute billing

Durable Objects are billed for compute duration (wall-clock time) while the Durable Object is actively running or is idle in memory but unable to hibernate. Durable Objects that are idle and eligible for hibernation are not billed for duration, even before the runtime has hibernated them. Requests to a Durable Object keep it active or create the object if it was inactive.

For each metered dimension, billable usage is the amount consumed in excess of the included monthly allocation. This billable usage is rounded up to the next billable unit before the corresponding rate is applied. For example, 500,000 GB-s of billable compute duration is rounded up to 1,000,000 GB-s and billed accordingly.

<details>

<summary>

Footnotes

</summary>

¹ Each <a href="https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle/">RPC session</a> is billed as one request to your Durable Object. Every <a href="https://developers.cloudflare.com/durable-objects/best-practices/create-durable-object-stubs-and-send-requests/">RPC method call</a> on a <a href="https://developers.cloudflare.com/durable-objects/">Durable Objects stub</a> is its own RPC session and therefore a single billed request.

RPC method calls can return objects (stubs) extending <a href="https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle/#lifetimes-memory-and-resource-management"><code>RpcTarget</code></a> and invoke calls on those stubs. Subsequent calls on the returned stub are part of the same RPC session and are not billed as separate requests. For example:

let durableObjectStub = OBJECT_NAMESPACE.get(id); // retrieve Durable Object stub
using foo = await durableObjectStub.bar(); // billed as a request
await foo.baz(); // treated as part of the same RPC session created by calling bar(), not billed as a request
await durableObjectStub.cat(); // billed as a request

² A request is needed to create a WebSocket connection. There is no charge for outgoing WebSocket messages, nor for incoming <a href="https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2">WebSocket protocol pings ↗︎</a>. For compute requests billing-only, a 20:1 ratio is applied to incoming WebSocket messages to factor in smaller messages for real-time communication. For example, 100 WebSocket incoming messages would be charged as 5 requests for billing purposes. The 20:1 ratio does not affect Durable Object metrics and analytics, which reflect actual usage.

³ Application level auto-response messages handled by <a href="https://developers.cloudflare.com/durable-objects/best-practices/websockets/"><code>state.setWebSocketAutoResponse()</code></a> will not incur additional wall-clock time, and so they will not be charged.

⁴ Duration is billed in wall-clock time as long as the Object is active and not eligible for hibernation, but is shared across all requests active on an Object at once. Calling <code>accept()</code> on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. It is recommended to use the WebSocket Hibernation API to avoid incurring duration charges once all event handlers finish running. For a complete explanation, refer to <a href="https://developers.cloudflare.com/durable-objects/platform/pricing/#when-does-a-durable-object-incur-duration-charges">When does a Durable Object incur duration charges?</a>.

⁵ Duration billing charges for the 128 MB of memory your Durable Object is allocated, regardless of actual usage. If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. These Durable Objects are still billed as if they are allocated a full 128 MB of memory.

</details>

Storage billing

The Durable Objects Storage API is only accessible from within Durable Objects. Pricing depends on the storage backend of your Durable Objects.

• SQLite-backed Durable Objects (recommended): SQLite storage backend is recommended for all new Durable Object classes. Workers Free plan can only create and access SQLite-backed Durable Objects.
• Key-value backed Durable Objects: Key-value storage backend is only available on the Workers Paid plan.