Release notes (3)

Last updated Apr 21, 2026

2025-11-05

D1 can configure jurisdictions for data localization

You can now set a jurisdiction when creating a D1 database to guarantee where your database runs and stores data.

2025-09-11

D1 automatically retries read-only queries

D1 now detects read-only queries and automatically attempts up to two retries to execute those queries in the event of failures with retryable errors. You can access the number of execution attempts in the returned response metadata property total_attempts.

At the moment, only read-only queries are retried, that is, queries containing only the following SQLite keywords: SELECT, EXPLAIN, WITH. Queries containing any SQLite keyword that leads to database writes are not retried.

The retry success ratio among read-only retryable errors varies from 5% all the way up to 95%, depending on the underlying error and its duration (like network errors or other internal errors).

The retry success ratio among all retryable errors is lower, indicating that there are write-queries that could be retried. Therefore, we recommend D1 users to continue applying retries in their own code for queries that are not read-only but are idempotent according to the business logic of the application.

D1 ensures that any retry attempt does not cause database writes, making the automatic retries safe from side-effects, even if a query causing changes slips through the read-only detection. D1 achieves this by checking for modifications after every query execution, and if any write occurred due to a retry attempt, the query is rolled back.

The read-only query detection heuristics are simple for now, and there is room for improvement to capture more cases of queries that can be retried, so this is just the beginning.

2025-07-01

Maximum D1 storage per account for the Workers paid plan is now 1 TB

The maximum D1 storage per account for users on the Workers paid plan has been increased from 250 GB to 1 TB.

2025-07-01

D1 alpha database backup access removed

Following the removal of query access to D1 alpha databases on 2024-08-23, D1 alpha database backups can no longer be accessed or created with wrangler d1 backup, available with wrangler v3.

If you want to retain a backup of your D1 alpha database, please use wrangler d1 backup before 2025-07-01. A D1 alpha backup can be used to migrate to a newly created D1 database in its generally available state.

2025-05-30

50-500ms Faster D1 REST API Requests

Users using Cloudflare's REST API to query their D1 database can see lower end-to-end request latency now that D1 authentication is performed at the closest Cloudflare network data center that received the request. Previously, authentication required D1 REST API requests to proxy to Cloudflare's core, centralized data centers, which added network round trips and latency.

Latency improvements range from 50-500 ms depending on request location and database location and only apply to the REST API. REST API requests and databases outside the United States see a bigger benefit since Cloudflare's primary core data centers reside in the United States.

D1 query endpoints like /query and /raw have the most noticeable improvements since they no longer access Cloudflare's core data centers. D1 control plane endpoints such as those to create and delete databases see smaller improvements, since they still require access to Cloudflare's core data centers for other control plane metadata.

2025-05-02

D1 HTTP API permissions bug fix

A permissions bug that allowed Cloudflare account and user API tokens with D1:Read permission and Edit permission on another Cloudflare product to perform D1 database writes is fixed. D1:Edit permission is required for any database writes via HTTP API.

If you were using an existing API token without D1:Edit permission to make edits to a D1 database via the HTTP API, then you will need to create or edit API tokens to explicitly include D1:Edit permission.

2025-04-10

D1 Read Replication Public Beta

D1 read replication is available in public beta to help lower average latency and increase overall throughput for read-heavy applications like e-commerce websites or content management tools.

Workers can leverage read-only database copies, called read replicas, by using D1 Sessions API. A session encapsulates all the queries from one logical session for your application. For example, a session may correspond to all queries coming from a particular web browser session. With Sessions API, D1 queries in a session are guaranteed to be sequentially consistent to avoid data consistency pitfalls. D1 bookmarks can be used from a previous session to ensure logical consistency between sessions.

// retrieve bookmark from previous session stored in HTTP header
const bookmark = request.headers.get("x-d1-bookmark") ?? "first-unconstrained";

const session = env.DB.withSession(bookmark);
const result = await session
  .prepare(`SELECT * FROM Customers WHERE CompanyName = 'Bs Beverages'`)
  .run();
// store bookmark for a future session
response.headers.set("x-d1-bookmark", session.getBookmark() ?? "");

Read replicas are automatically created by Cloudflare (currently one in each supported D1 region), are active/inactive based on query traffic, and are transparently routed to by Cloudflare at no additional cost.

To checkout D1 read replication, deploy the following Worker code using Sessions API, which will prompt you to create a D1 database and enable read replication on said database.

To learn more about how read replication was implemented, go to our blog post.

2025-02-19

D1 supports `PRAGMA optimize`

D1 now supports PRAGMA optimize command, which can improve database query performance. It is recommended to run this command after a schema change (for example, after creating an index). Refer to PRAGMA optimize for more information.

2025-02-04

Fixed bug with D1 read-only access via UI and /query REST API.

Fixed a bug with D1 permissions which allowed users with read-only roles via the UI and users with read-only API tokens via the /query REST API to execute queries that modified databases. UI actions via the Tables tab, such as creating and deleting tables, were incorrectly allowed with read-only access. However, UI actions via the Console tab were not affected by this bug and correctly required write access.

Write queries with read-only access will now fail. If you relied on the previous incorrect behavior, please assign the correct roles to users or permissions to API tokens to perform D1 write queries.

2025-01-13

D1 will begin enforcing its free tier limits from the 10th of February 2025.

D1 will begin enforcing the daily free tier limits from 2025-02-10. These limits only apply to accounts on the Workers Free plan.

From 2025-02-10, if you do not take any action and exceed the daily free tier limits, queries to D1 databases via the Workers API and/or REST API will return errors until limits reset daily at 00:00 UTC.

To ensure uninterrupted service, upgrade your account to the Workers Paid plan from the plans page. The minimum monthly billing amount is $5. Refer to Workers Paid plan and D1 limits.

For better insight into your current usage, refer to your billing metrics for rows read and rows written, which can be found on the D1 dashboard or GraphQL API.

2025-01-07

D1 Worker API request latency decreases by 40-60%.

D1 lowered end-to-end Worker API request latency by 40-60% by eliminating redundant network round trips for each request.

p50, p90, and p95 request latency aggregated across entire D1 service. These latencies are a reference point and should not be viewed as your exact workload improvement.

For each request to a D1 database, at least two network round trips were eliminated. One round trip was due to a bug that is now fixed. The remaining removed round trips are due to avoiding creating a new TCP connection for each request when reaching out to the datacenter hosting the database.

The removal of redundant network round trips also applies to D1's REST API. However, the REST API still depends on Cloudflare's centralized datacenters for authentication, which reduces the relative performance improvement.

2024-08-23

D1 alpha databases have stopped accepting SQL queries

Following the deprecation warning on 2024-04-30, D1 alpha databases have stopped accepting queries (you are still able to create and retrieve backups).

Requests to D1 alpha databases now respond with a HTTP 400 error, containing the following text:

You can no longer query a D1 alpha database. Please follow https://developers.cloudflare.com/d1/platform/alpha-migration/ to migrate your alpha database and resume querying.

You can upgrade to the new, generally available version of D1 by following the alpha database migration guide.

2024-07-26

Fixed bug in TypeScript typings for run() API

The run() method as part of the D1 Client API had an incorrect (outdated) type definition, which has now been addressed as of @cloudflare/workers-types version 4.20240725.0.

The correct type definition is stmt.run<T>(): D1Result, as run() returns the result rows of the query. The previously incorrect type definition was stmt.run(): D1Response, which only returns query metadata and no results.

2024-06-17

HTTP API now returns a HTTP 429 error for overloaded D1 databases

Previously, D1's HTTP API returned a HTTP 500 Internal Server error for queries that came in while a D1 database was overloaded. These requests now correctly return a HTTP 429 Too Many Requests error.

D1's Workers API is unaffected by this change.

2024-04-30

D1 alpha databases will stop accepting live SQL queries on August 15, 2024

Previously deprecated alpha D1 databases need to be migrated by August 15, 2024 to accept new queries.

Refer to alpha database migration guide to migrate to the new, generally available, database architecture.

2024-04-12

HTTP API now returns a HTTP 400 error for invalid queries

Previously, D1's HTTP API returned a HTTP 500 Internal Server error for an invalid query. An invalid SQL query now correctly returns a HTTP 400 Bad Request error.

D1's Workers API is unaffected by this change.

2024-04-05

D1 alpha databases are deprecated

Now that D1 is generally available and production ready, alpha D1 databases are deprecated and should be migrated for better performance, reliability, and ongoing support.

Refer to alpha database migration guide to migrate to the new, generally available, database architecture.

2024-04-01

D1 is generally available

D1 is now generally available and production ready. Read the blog post for more details on new features in GA and to learn more about the upcoming D1 read replication API.

• Developers with a Workers Paid plan now have a 10GB GB per-database limit (up from 2GB), which can be combined with existing limit of 50,000 databases per account.
• Developers with a Workers Free plan retain the 500 MB per-database limit and can create up to 10 databases per account.
• D1 databases can be exported as a SQL file.

2024-03-12

Change in `wrangler d1 execute` default

As of wrangler@3.33.0, wrangler d1 execute and wrangler d1 migrations apply now default to using a local database, to match the default behavior of wrangler dev.