Cloudflare D1 Free Limits: When Queries Stop

Cloudflare D1 Free became a production availability decision on September 1, 2026. Once an account spends either 5 million row reads or 100,000 row writes in a day, D1 queries can stop until midnight UTC.

Cloudflare changed the failure mode, not the quota

The free allowances already existed. The change is what happens at the edge of them.

On Workers Free, crossing either daily allowance now makes D1 reject queries through both the Workers Binding API and the REST API. Cloudflare documents separate messages for the read and write limits, and says queries resume when the allowance resets at 00:00 UTC. Your stored data remains intact. Your application may still be unable to read or change it.

That distinction is the whole story. A soft usage number has become a hard availability boundary.

Cloudflare sends an email when the daily limit is reached. That tells you why the incident is happening, but it arrives after the database is already unavailable. A production team needs a budget and an earlier alert, not only a post-failure explanation. The September 1 D1 changelog carries the exact failure behavior and error text.

Workers Paid isn't affected by this daily stop. A prototype that stays comfortably below both allowances may not need to move today. A live product that depends on D1 now needs to treat Free like any other resource with a shutdown point.

Rows scanned are the unit that matters

The read allowance is not 5 million API calls or 5 million returned records. It is 5 million rows scanned by the database while answering your queries.

Suppose a filter returns one customer but has no useful index. D1 may scan a 5,000-row table to find that record. Run that query 1,000 times and you have spent all 5 million daily row reads. The result looked tiny. The work underneath it was not.

Writes are more direct. An INSERT, UPDATE, or DELETE counts the rows changed. An insert of 10 rows counts as 10 rows written. Schema operations such as CREATE, ALTER, and DROP can consume a mix of reads and writes too.

Row size does not change this meter. A 1 KB row and a 100 KB row each count as one row. Query shape is what moves the read number.

An index lets D1 jump to the relevant records instead of scanning the table. That usually trades a small amount of extra write work for a much larger reduction in reads. When you write a column covered by an index, D1 writes the table row and at least one index row. This is why the right answer is to index the columns used by frequent filters and joins, not every column in sight.

Cloudflare's index guide gives you a clean test. Prefix the expensive query with EXPLAIN QUERY PLAN. A plan showing SCAN is reading the table. A plan showing SEARCH ... USING INDEX is using an index. After adding an index, run PRAGMA optimize so the query planner has current statistics.

The business math changed

Workers Free still costs $0. What changed is the downside: your maximum database bill remains zero, but the database can now stop serving the application for the rest of the UTC day.

Workers Paid starts at $5 per account per month. It replaces the daily hard stop with monthly included usage and overage pricing.

The step from Free to Paid is larger than it first looks. Thirty days at the Free read ceiling would total 150 million rows, only 0.6% of the Paid plan's 25 billion included reads. Thirty days at the Free write ceiling would total 3 million rows, or 6% of the 50 million included writes.

For many small applications, the first paid decision is therefore not an overage decision. It is a $5 availability decision. Workers requests, CPU, D1 storage above 5 GB, and any other Cloudflare products still have their own meters, so $5 is the floor rather than a promise that the whole account will cost exactly $5. The broader Cloudflare pricing review shows where those account and product lines separate.

There is no D1 data-transfer or throughput charge. That does not soften the Free failure. It just means egress is not one of the numbers you need in this decision.

Four teams, four practical moves

A solo founder with a live SaaS

If sign-in, billing state, or the customer dashboard reads D1, the Free plan is now carrying production downtime risk. Start by finding the busiest normal day, then fix any full scans. If the application still approaches the cap, the $5 minimum is cheaper than planning around an unknown number of hours without database access.

The payoff is not more database capacity in the abstract. It is removing midnight UTC from your incident recovery plan.

An agency with several databases in one account

The limit language is account-level. An agency operator should inventory every D1 database on that Cloudflare account, not inspect one client property and declare the account safe.

Use per-database metrics to find the noisy project, then add the totals before setting the account budget. The payoff is a shared number that operations can own. One project's inefficient scan should not arrive as a mystery outage somewhere else in the same account.

A backend engineer chasing expensive reads

The job is to identify query shapes, not delete random data. D1 returns rows_read and rows_written inside each query's meta object. Those counts show the precise cost of one execution.

Cloudflare also exposes query insights through Wrangler and the GraphQL Analytics API. Sort by reads to find the repeated scans, inspect the plan, add the narrow index, and measure again. The payoff is lower quota use and usually lower latency from the same change.

An operations lead running imports or syncs

A bulk sync can spend 100,000 writes before customer traffic has a chance to use the database. Pace a non-urgent job across reset windows, or move the account to Paid before a production import.

Do not plan to clean up after hitting the write cap. DELETE is itself a write operation, so the same exhausted allowance can block the cleanup query until reset. The payoff is keeping live writes available while the batch work runs.

Build the limit budget before the alert arrives

Here is a workable first policy. It is an operator rule, not a Cloudflare requirement: budget production at 80% of the published Free allowance. That gives you a daily operating ceiling of 4 million reads and 80,000 writes, with 1 million reads and 20,000 writes held back for bursts and measurement delay.

1. 1

   Measure the real day

   Open Cloudflare, go to D1, select each database, and open Metrics. The default view is the last 24 hours. Pull enough history to see ordinary weekdays, launches, imports, and traffic spikes. D1 keeps these metrics for 31 days.

2. 2

   Find the query spending the rows

   Use the per-query meta.rows_read and meta.rows_written values while testing important paths. Use query insights to rank frequent or expensive statements. Run EXPLAIN QUERY PLAN on the worst read query and fix a full scan before treating the plan upgrade as the only answer.

3. 3

   Alert before the hard line

   Use the GraphQL Analytics API, which reads the same datasets as the dashboard, for a scheduled account check. Alert the owner at 4 million reads or 80,000 writes. Cloudflare's email at the full limit remains useful as incident confirmation, but it should not be the first production signal.

4. 4

   Write the failure decision now

   Decide what the Worker returns if D1 throws a limit error. A cached read may remain useful if it does not execute another D1 query. A write path needs a clear unavailable response or a separately designed queue. Do not loop retries against a quota that cannot recover until midnight UTC or an upgrade.

The D1 metrics documentation names rowsRead and rowsWritten as the GraphQL fields and confirms that the dashboard uses the same analytics data. That gives a small team one manual path today and one automatable path when the database becomes important enough to page someone.

The honest limits of the fix

An index is not free. It consumes storage and adds writes when indexed values change. Add the indexes that remove costly scans, then measure the new balance. An account already close to the 100,000-write limit can make the wrong trade by indexing indiscriminately.

Paid also isn't unlimited. It includes 25 billion reads and 50 million writes each month, then bills overage at the published rates. Upgrading removes the Free daily stop, typically within minutes, but it does not remove the need to watch bad queries or forecast the rest of the Workers bill. Cloudflare's current D1 pricing page is the number sheet to keep in the runbook.

There is one source-history wrinkle worth knowing. A January 2025 D1 release note said enforcement would begin on February 10, 2025. The newer, event-specific changelog says it begins September 1, 2026. I am using the newer page as the controlling statement because it directly names the current rollout. That explains why an older search result may show a different date.

Finally, "stored data is not affected" is narrower than "the product is fine." Your data can be safe while every route that needs it returns an error. Availability is the business consequence.

What to do on Monday

Act this week if a customer-facing application runs on Workers Free and D1 is in the request path. Measure first, fix obvious scans, set the 4 million read and 80,000 write alert, and pre-authorize the $5 Paid move.

Wait if this is a disposable prototype, the 31-day history stays well below the operator budget, and a day of query failure would not affect customers or revenue. Keep the alert anyway, because traffic and table size both change the read math.

You are unaffected by this specific daily stop if the account is already on Workers Paid or the application does not query D1.

The Monday move is simple: open the D1 Metrics tab for every database, write down the account's highest read and write day, identify the query responsible for the largest scan, and give one person authority to upgrade. If a normal peak still crosses 4 million reads or 80,000 writes after the query fix, move the account to Workers Paid that day.

If you want the next platform change translated into an operating decision, join the newsletter.