Michael JohnsonA query to Cloudflare D1 that returns a result larger than 50 MB fails starting November 4, 2026. The key distinction for developers is the scope of the change: it concerns the size of an individual query’s result, not the maximum database size. Imports and exports through the REST API are not subject to this limit, so the way you read data determines whether you need to change your workflow.
What exactly is limited?
Cloudflare described the change in an October 30 post: a query whose result exceeds 50 MB returns the error D1 query result exceeded the maximum response size limit of 50 MB. The limit takes effect on November 4, 2026. D1’s documentation also lists a limit on query result size; meanwhile, a database can store up to 10 GB on a paid plan or 500 MB on the free plan.
These are different limits: storage determines how much data a database can hold, while the result limit determines how much data a single query can return. A database can therefore contain much more than 50 MB of data and remain readable in parts. At the same time, even a small database can exceed the limit if a query selects many wide rows or large text and binary fields.
In its announcement of the limit, Cloudflare says the threshold covers the 99.999th percentile of D1 queries. That is the provider’s estimate of the distribution of queries; for an application-level check, it is more important to measure actual responses and identify queries that return large arrays of data.
Why are REST API exports a separate case?
An application query typically receives the result of executing SQL and passes it to the calling code. Importing and exporting a database through the REST API are different operations: Cloudflare specifically says they are not subject to the new threshold and continue to work as before. So an error on a large query does not mean you cannot export a large amount of data from the database.
In practice, this distinction helps you choose the right approach. If an application needs all the records for display, processing, or a report, split the read into batches. If the goal is to move or export data, check the REST API export workflow rather than trying to retrieve the entire database in a single SQL response.
How can you reduce the response without losing needed data?
The first step is to remove unnecessary columns. Instead of SELECT *, specify only the fields needed for the current operation. This reduces the response size, especially if the table contains long descriptions, JSON, or BLOB values.
The second step is to read rows in batches using LIMIT and OFFSET, as Cloudflare recommends. For example, an interface can fetch the next page as the user scrolls, while a batch job can process separate chunks. Add a stable sort order, such as by a unique identifier: without one, page boundaries can shift if the data changes between queries.
For long-running exports, it is also worth storing a checkpoint for the last processed record. That way, a job can resume after a failure without processing the entire dataset again. The specific design depends on the application; the key principle is to limit the size of each response rather than rely on a single query that returns the whole dataset.
What to check in your application
Start with queries that return large lists: report exports, admin screens, background jobs, and API routes that return arrays of rows. Temporarily log the serialized response size or the number and sizes of the selected fields. Then check the maximum expected volume, not just the small datasets in ordinary test cases.
If the application starts returning an error after the change, D1’s documentation ties it specifically to results larger than 50 MB and recommends selecting only the required columns or paginating the result. This helps distinguish a response-size issue from execution-time, memory, or database availability limits, which have different errors and causes.
The takeaway for teams is simple: ordinary, short queries are unlikely to need changes, but large reads should be switched to batch processing. The limit does not prevent you from storing a larger database or exporting through the REST API; it means queries should be designed so that each response stays within 50 MB.
