Cloudflare D1 now enforces daily Free limits: audit row scans before they fail (2026)

Decision: If a production-like or shared test account still runs D1 on Workers Free, audit that account now. Cloudflare began enforcing daily row quotas on September 1, 2026: an account that exceeds 5 million rows read or 100,000 rows written in a day receives D1 errors until the daily reset. The database contents remain intact. 1 2

The quick read

Signal	Current behavior	What to do
Affected plan	Workers Free accounts that exceed the daily D1 row-read or row-write quota	Check every Free account that serves traffic, runs CI, or carries shared test data. 1
Daily allowance	5 million rows read and 100,000 rows written	Compare the quota with account-level usage, rather than with the result size of one query. 2
Failure mode	Workers Binding API and REST API queries return errors after the account reaches a read or write limit	Add an explicit error path and decide whether optimization or a Paid upgrade fits the workload. 1
Reset and data	The quota resets daily; stored data is unaffected by the query block	Treat an overage as a service-availability problem for the affected account, not as data loss. 1
Migration signal	The change is a D1 plan and query-shape decision	Audit, index, batch, or upgrade first. Keep the hosting boundary unchanged unless a separate requirement demands a move.

What changed at the boundary

Cloudflare's September 1 changelog changes an old assumption about the Workers Free plan: a D1 query that pushes the account past its daily row-read or row-write allowance now fails. The limit applies to queries through both the Workers Binding API and the REST API. Cloudflare sends an email when the account reaches a daily limit. 1

The quota belongs to the account. A large table scan in one database and smaller queries in another database draw from the same account-level daily allowance. D1 counts rows scanned for reads, so a query that returns ten rows can still consume many more read units when the database scans an unindexed column. D1 counts rows affected for writes, including INSERT, UPDATE, and DELETE. 2

The failure lasts until the daily allowance resets. Cloudflare says the account can continue by waiting for the reset or upgrading to Workers Paid. The query block leaves stored data in place, which separates this incident from a storage or database-corruption event. 1

The workload that is exposed

The update matters when a Free account has a predictable daily traffic pattern that approaches either quota. Four cases deserve a quick check:

Request paths with broad reads. Full-table scans and filters on unindexed columns can consume read units faster than the response size suggests. An index on a frequently filtered field can reduce the rows scanned. 2
Write-heavy endpoints. Bulk imports, synchronization jobs, and repeated updates can reach 100,000 written rows before the application appears large. D1 counts each affected row, and indexed writes can add another written row for the index. 2
CI, load tests, and operator queries. D1 counts queries run from the dashboard and Wrangler as usage, so a shared Free account can spend its allowance outside the public request path. 2
Several environments in one account. Because the changelog describes an account-level limit, a staging workload can consume headroom that a production-like workload expected to have. 1

A prototype that stays well below both daily quotas has a watch item. The new enforcement becomes an action item when usage has little margin, when a scheduled job creates a sharp daily peak, or when the application has no response for the new error state.

A low-risk response

Inventory the accounts and environments. List every D1 database queried by production-like traffic, CI, load tests, scheduled jobs, the dashboard, or Wrangler. Group the result by Cloudflare account so the quota is measured at the same boundary Cloudflare enforces.
Measure rows, rather than returned objects. D1 returns rows_read and rows_written in each query's meta object. The Cloudflare dashboard and Analytics API also expose usage by database and time period. 2
Remove avoidable scans. Inspect queries that read far more rows than they return. Add indexes to the fields used for filtering, and check the resulting read counts under representative traffic. 1 2
Batch large writes. D1's limits documentation recommends breaking migrations that affect hundreds of thousands of rows into smaller batches. Apply the same discipline to recurring synchronization and cleanup jobs. 3
Choose the smallest paid step. Workers Paid removes the Free plan's daily read and write limits, then bills usage against monthly included amounts and overage rates. Cloudflare says the change usually takes effect within minutes. 2
Test the overage path. Force a controlled read or write overage in a non-production account and confirm that the application returns a useful response, the alert reaches the owning team, and the next reset restores normal queries.

Verdict: audit now, migrate nowhere yet

This update deserves an immediate audit for any D1 workload on Workers Free. The exposure is easy to miss because D1 counts rows scanned or affected across the account, while application metrics often emphasize returned records and successful requests. 1 2

The first response should be a query and account-usage check. An index or a batched job may restore enough headroom; a workload that intentionally needs more daily volume should evaluate Workers Paid. Teams already operating below the quotas can keep watching their margin and error telemetry. The platform migration question can wait until the D1 plan, query shape, and account boundary have been tested.

Fuentes de referencia

1
D1 enforces free tier daily query limits
developers.cloudflare.com
2
D1 pricing
developers.cloudflare.com
3
D1 limits
developers.cloudflare.com