Changelog
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.
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.
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.
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.
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.
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.
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.
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.
It is also now possible to specify one of --local or --remote to explicitly tell wrangler which environment you wish to run your commands against.
As of 2024-03-05, D1 usage will start to be counted and may incur charges for an account's future billing cycle.
Developers on the Workers Paid plan with D1 usage beyond included limits will incur charges according to D1's pricing.
Developers on the Workers Free plan can use up to the included limits. Usage beyond the limits below requires signing up for the $5/month Workers Paid plan.
Account billable metrics are available in the Cloudflare Dashboard and GraphQL API.
A previous change (made on 2024-02-13) to the run() query statement method has been reverted.
run() now returns a D1Result, including the result rows, matching its original behavior prior to the change on 2024-02-13.
Future change to run() to return a D1ExecResult, as originally intended and documented, will be gated behind a compatibility date as to avoid breaking existing Workers relying on the way run() currently works.
D1's raw(), all() and run() query statement methods have been updated to reflect their intended behavior and improve compatibility with ORM libraries.
raw() now correctly returns results as an array of arrays, allowing the correct handling of duplicate column names (such as when joining tables), as compared to all(), which is unchanged and returns an array of objects. To include an array of column names in the results when using raw(), use raw({columnNames: true}).
run() no longer incorrectly returns a D1Result and instead returns a D1ExecResult as originally intended and documented.
This may be a breaking change for some applications that expected raw() to return an array of objects.
Refer to D1 client API to review D1's query methods, return types and TypeScript support in detail.
D1 now supports adding a LIMIT clause to UPDATE and DELETE statements, which allows you to limit the impact of a potentially dangerous operation.
Databases using D1's legacy alpha backend will no longer run automated hourly backups. You may still choose to take manual backups of these databases.
The D1 team recommends moving to D1's new production backend, which will require you to export and import your existing data. D1's production backend is faster than the original alpha backend. The new backend also supports Time Travel, which allows you to restore your database to any minute in the past 30 days without relying on hourly or manual snapshots.
Developers using D1 on a Workers Paid plan can now create up to 50,000 databases as part of ongoing increases to D1's limits.
- This further enables database-per-user use-cases and allows you to isolate data between customers.
- Total storage per account is now 50 GB.
- D1's analytics and metrics provide per-database usage data.
If you need to create more than 50,000 databases or need more per-account storage, reach out to the D1 team to discuss.
D1 is now in public beta, and storage limits have been increased:
- Developers with a Workers Paid plan now have a 2 GB per-database limit (up from 500 MB) and can create 25 databases per account (up from 10). These limits will continue to increase automatically during the public beta.
- Developers with a Workers Free plan retain the 500 MB per-database limit and can create up to 10 databases per account.
Databases must be using D1's new storage subsystem to benefit from the increased database limits.
Read the announcement blog for more details about what is new in the beta and what is coming in the future for D1.
D1 now returns a count of rows_written and rows_read for every query executed, allowing you to assess the cost of query for both pricing and index optimization purposes.
The meta object returned in D1's Client API contains a total count of the rows read (rows_read) and rows written (rows_written) by that query. For example, a query that performs a full table scan (for example, SELECT * FROM users) from a table with 5000 rows would return a rows_read value of 5000:
"meta": {
"duration": 0.20472300052642825,
"size_after": 45137920,
"rows_read": 5000,
"rows_written": 0
}
Refer to D1 pricing documentation to understand how reads and writes are measured. D1 remains free to use during the alpha period.
You can now bind a D1 database to your Workers directly in the Cloudflare dashboard. To bind D1 from the Cloudflare dashboard, select your Worker project -> Settings -> Variables -> and select D1 Database Bindings.
Note: If you have previously deployed a Worker with a D1 database binding with a version of wrangler prior to 3.5.0, you must upgrade to wrangler v3.5.0 first before you can edit your D1 database bindings in the Cloudflare dashboard. New Workers projects do not have this limitation.
Legacy D1 alpha users who had previously prefixed their database binding manually with __D1_BETA__ should remove this as part of this upgrade. Your Worker scripts should call your D1 database via env.BINDING_NAME only. Refer to the latest D1 getting started guide for best practices.
We recommend all D1 alpha users begin using wrangler 3.5.0 (or later) to benefit from improved TypeScript types and future D1 API improvements.
Databases using D1's new storage subsystem can now grow to 500 MB each, up from the previous 100 MB limit. This applies to both existing and newly created databases.
Refer to Limits to learn about D1's limits.
Databases created via the Cloudflare dashboard and Wrangler (as of v3.4.0) now use D1's new storage subsystem by default. The new backend can be 6 - 20x faster than D1's original alpha backend.
To understand which storage subsystem your database uses, run wrangler d1 info YOUR_DATABASE and inspect the version field in the output.
Databases with version: beta use the new storage backend and support the Time Travel API. Databases with version: alpha only use D1's older, legacy backend.
Time Travel is now available. Time Travel allows you to restore a D1 database back to any minute within the last 30 days (Workers Paid plan) or 7 days (Workers Free plan), at no additional cost for storage or restore operations.
Refer to the Time Travel documentation to learn how to travel backwards in time.
Databases using D1's new storage subsystem can use Time Travel. Time Travel replaces the snapshot-based backups used for legacy alpha databases.
You can now view per-database metrics via both the Cloudflare dashboard and the GraphQL Analytics API.
D1 currently exposes read & writes per second, query response size, and query latency percentiles.
New documentation has been published on how to use D1's support for generated columns to define columns that are dynamically generated on write (or read). Generated columns allow you to extract data from JSON objects or use the output of other SQL functions.
As of wrangler v3.1.1 the D1 client API now returns detailed error messages within the top-level Error.message property, and no longer requires developers to inspect the Error.cause.message property.
To facilitate a transition from the previous Error.cause behaviour, detailed error messages will continue to be populated within Error.cause as well as the top-level Error object until approximately July 14th, 2023. Future versions of both wrangler and the D1 client API will no longer populate Error.cause after this date.
D1 has a new experimental storage back end that dramatically improves query throughput, latency and reliability. The experimental back end will become the default back end in the near future. To create a database using the experimental backend, use wrangler and set the --experimental-backend flag when creating a database:
$ wrangler d1 create your-database --experimental-backend
Read more about the experimental back end in the announcement blog.
You can now provide a location hint when creating a D1 database, which will influence where the leader (writer) is located. By default, D1 will automatically create your database in a location close to where you issued the request to create a database. In most cases this allows D1 to choose the optimal location for your database on your behalf.
New documentation has been published that covers D1's extensive JSON function support. JSON functions allow you to parse, query and modify JSON directly from your SQL queries, reducing the number of round trips to your database, or data queried.