Michael JohnsonIf your application fetches large result sets from Cloudflare D1 in a single query, check it before November 4: from that date, a query returning more than 50 MB will fail. The change concerns the size of the result, not the database size or the volume of an API request; imports and exports through the REST API retain their previous behavior.
What exactly is changing
Cloudflare announced the limit on October 30, 2026. The new rule takes effect on Wednesday, November 4: if an SQL query’s result exceeds 50 MB, D1 will return the error D1 query result exceeded the maximum response size limit of 50 MB. The company says this threshold covers the 99.999th percentile of queries on D1, meaning the vast majority of queries remain below the limit. This is Cloudflare’s estimate across its platform, not a guarantee for any individual application.
The distinction between query results and data transfers matters. The limit applies to the result returned by a D1 query; import and export operations through the REST API are explicitly excluded. So the main things to check are application queries that read many rows or wide records and then retrieve them in full.
Why a large result can appear unnoticed
Response size depends on more than the number of rows. A query with many columns can return a large result even with a moderate number of records, especially if rows contain long text or other sizable values. The SELECT * construct includes every column, even when the caller needs only a few. As a table grows over time, a query that was once safe can also cross the threshold.
The practical takeaway is to check not only one-off administrative exports, but also recurring application operations—for example, report handlers, background jobs, and API methods that collect data for further processing. These are scenarios to audit, not claims that each one will necessarily be affected.
How to prepare your queries
In its announcement, Cloudflare recommends reducing the returned data set: select the required columns instead of using SELECT *, and split large queries into pages with LIMIT and OFFSET. This reduces the size of each response and helps spread processing across multiple queries.
- Find broad queries. Review queries that use
SELECT *, have no row limit, or include large text fields. - Narrow the projection. List only the columns actually needed by the next processing step.
- Read in batches. Add pagination using
LIMITandOFFSET, as Cloudflare suggests, and process batches sequentially. - Check behavior after splitting. Make sure the application combines results correctly and does not rely on receiving the entire result set in one response.
If your application needs a complete data set for a separate export, check whether the REST API export operation suits the task: Cloudflare says the new limit does not apply to it. For ordinary application logic, this exception is no substitute for reviewing large SQL responses.
Who should pay attention to the deadline
The deadline directly concerns D1 users whose queries return more than 50 MB. Start by checking code where results are loaded into memory in full, passed between components, or generated for a report. If queries already return only small pages and the required fields, no special changes may be needed; the actual response size of your queries is what should guide the decision.
Checking before November 4 can uncover reliance on a single large response before the limit takes effect. According to Cloudflare, the threshold is well above the usual volume for most queries; for affected systems, the most direct plan is to reduce the selected data, read it in batches, or use the REST API route intended for exports.
