Cloudflare spent the first week of September 2026 quietly rewriting the rules for anyone building on its free tier. Starting September 1, D1 database queries that blow past daily row limits now fail outright instead of sliding through. A day later, the Web Application Firewall flipped several SQL injection detections from passive logging to active blocking. Then on September 4, Cloudflare reversed course on a long-standing complaint and tripled its Workers bundle size ceiling from a compressed 10 MB cap to a flat 64 MiB, measured uncompressed, on every plan. Three separate changelog entries, three different parts of the platform, one clear signal: Cloudflare is tightening enforcement on the free side of its business while loosening a technical constraint that has annoyed developers for years.
None of this happened in isolation. Cloudflare has been converting its Workers ecosystem into what the company calls an agentic cloud platform, and free-tier economics matter more when millions of prototype apps and AI agents are hammering shared infrastructure. The changes reveal how a company that built its brand on generous free plans is now drawing sharper lines around what “free” actually means in 2026, while simultaneously making its paid product more attractive to developers who outgrow those limits.
What Changed on Cloudflare’s Platform in September 2026
Three Cloudflare changelog posts, published within four days of each other, define this story. The first, dated September 1, 2026, states plainly that “D1 queries on Workers Free accounts that exceed daily row read or write limits will fail and return errors,” according to Cloudflare’s official changelog. The second covers a Web Application Firewall release that moved specific SQL injection detections from a log-only posture to active blocking. The third, published September 4, 2026, removed the compressed-size ceiling on Workers deployments entirely and replaced it with a single 64 MiB uncompressed limit across both Free and Paid plans, confirmed directly on Cloudflare’s Workers platform limits page.
Two of the three moves tighten the free tier. One loosens it. Read together, they describe a platform maturing past its early give-away-everything posture into something closer to how AWS and Google Cloud have run their free tiers for a decade: generous enough to prototype, strict enough to force a plan upgrade the moment a project gets real traffic. Developers scanning the changelog on the day it dropped described the D1 change as the more consequential of the two restrictions, since a failed database query breaks an app outright, while a WAF rule mostly affects edge cases in query syntax.
The D1 Free Tier Numbers, Before and After
D1 is Cloudflare’s serverless SQL database, built on SQLite and designed to run at the edge alongside Workers functions. Its free-tier quotas were never a secret. Cloudflare’s own D1 pricing documentation lists them as 5 million rows read per day, 100,000 rows written per day, and 5 GB of total storage on the Workers Free plan, with limits resetting daily at 00:00 UTC. Those numbers have not moved. What changed is enforcement.
Before September 1, developers who crossed those thresholds experienced inconsistent behavior. Some queries went through anyway, while others degraded unpredictably. After September 1, the rule is binary. Once an account exceeds either the daily read or write ceiling, every subsequent D1 query fails, whether it arrives through a Workers binding or the REST API, until the clock resets at midnight UTC. Cloudflare does send email alerts as accounts approach the cap, giving teams a chance to react before their database effectively disappears for the rest of the day.
The detail that trips people up is what counts as a row read. It is not a request count. It is rows scanned by the query engine, regardless of how many rows the application actually uses. A single unindexed SELECT against a 200,000-row table can burn through a meaningful chunk of the daily 5-million-row allowance in one call. That makes query efficiency, not raw traffic volume, the real gatekeeper for staying inside the free tier. A poorly indexed analytics dashboard can exhaust a day’s quota faster than a busy but well-optimized production app.
WAF Moves SQL Injection Rules From Logging to Blocking
Cloudflare’s Web Application Firewall changelog shows a specific new detection rule, described internally as SQLi – WHERE Comparison With WITH Clause, moving from a Log action to a Block action in the release dated around September 1 and 2, 2026. A related PostgreSQL-specific rule, targeting SQL injection attempts through COPY and URI parameters, received the same treatment. Cloudflare’s documentation on the WAF changelog describes the update as introducing a new threat detection to enhance protection against SQL injection attempts exploiting complex query syntax.
Part of a Longer Pattern, Not a One-Off
This September update did not appear out of nowhere. Cloudflare converted several beta-stage SQL injection rules, covering patterns like AND/OR MAKE_SET/ELT abuse, comment-based evasion, and sub-query attacks, from logging to blocking back in January 2026. A more urgent example came on July 17, 2026, when Cloudflare shipped an emergency WAF release at 17:03 UTC to stop active exploitation of a critical remote code execution and SQL injection vulnerability affecting popular web frameworks, deploying rules that defaulted to Block from the moment they went live. The September SQLi rule fits that same pattern. Cloudflare is steadily narrowing the gap between detected and stopped across its Managed Ruleset, and the change applies to both free and paid customers rather than being gated behind a paid tier.
For most developers, the practical effect is invisible. Legitimate applications rarely construct queries that trip a WHERE-plus-WITH-clause SQL injection signature. The developers who notice are usually running PostgreSQL-backed apps with genuinely complex query builders, ORMs that generate nested common table expressions, or admin panels that accept raw SQL fragments from trusted internal users. Those teams need to check WAF logs for new false positives and, where necessary, add scoped exceptions rather than disabling the rule outright.
Workers Bundle Size Jumps to 64 MiB Across Every Plan
The most developer-friendly change in this batch addresses a complaint that has followed Cloudflare Workers for years. Previously, Cloudflare checked the compressed size of a deployed Worker bundle, capping it at 3 MB on the Free plan and 10 MB on Paid. Wrangler, Cloudflare’s deployment CLI, would gzip a bundle before checking it against that ceiling, which meant developers had to watch a gzip size figure in their terminal output and prune dependencies to stay under it. Modern JavaScript frameworks, with their bundled polyfills, tree-shaken but still substantial dependency graphs, and increasingly common AI SDK integrations, made that limit feel outdated fast.
As of the September 4, 2026 changelog entry, Cloudflare dropped the compressed-size check entirely. The only number that matters now is the uncompressed bundle size, and the ceiling is 64 MiB, applied identically to Workers Free and Workers Paid accounts, according to Cloudflare’s own platform limits documentation. Wrangler’s deploy output now surfaces a “Total Upload” figure representing that uncompressed size, while the old gzip number is still shown but no longer enforced. A developer posting about the change on X framed it as removing a cap that had forced teams into code-splitting and asset-offloading gymnastics just to fit inside 3 MB.
The scale of the jump is worth sitting with. Going from a 3 MB compressed limit to a 64 MiB uncompressed limit is not an incremental bump. Because compressed JavaScript typically shrinks by roughly 70 to 80 percent, the old 3 MB compressed cap translated to somewhere around 10 to 15 MB of actual source code. The new 64 MiB uncompressed ceiling is more than four times that effective ceiling, and it removes the guesswork of predicting how well a given bundle will compress before deploying it.
Cloudflare’s September 2026 Free Tier Changes at a Glance
| Platform Feature | Before September 2026 | After September 2026 | Effective Date |
|---|---|---|---|
| D1 rows read (Workers Free) | 5M/day, soft enforcement | 5M/day, hard failure past cap | Sept 1, 2026 |
| D1 rows written (Workers Free) | 100,000/day, soft enforcement | 100,000/day, hard failure past cap | Sept 1, 2026 |
| D1 storage (Workers Free) | 5 GB total | 5 GB total, unchanged | N/A |
| WAF SQLi (WHERE + WITH clause) | Log only | Block by default | Sept 1-2, 2026 |
| Workers bundle size, Free | 3 MB, compressed | 64 MiB, uncompressed | Sept 4, 2026 |
| Workers bundle size, Paid | 10 MB, compressed | 64 MiB, uncompressed | Sept 4, 2026 |
| Workers requests (Free plan) | 100,000/day | 100,000/day, unchanged | N/A |
The pattern in that table tells its own story. Storage and request quotas held steady. The two changes that moved were enforcement, on D1 and WAF, and a hard technical ceiling that had nothing to do with billing on Workers bundle size. Cloudflare is not shrinking what free accounts get access to. It is closing the gap between the documented limit and the actual limit.
How Cloudflare’s New Limits Compare to AWS, Vercel, and Google Cloud
Bundle size limits are one of the more direct ways to compare serverless platforms, because every major provider publishes a hard number and developers hit it in practice. Cloudflare’s new 64 MiB uncompressed ceiling puts it in a different category than it occupied a week earlier.
| Platform | Deployment Size Limit | Measured As | Source |
|---|---|---|---|
| Cloudflare Workers (all plans) | 64 MiB | Uncompressed bundle | Cloudflare Workers limits docs |
| AWS Lambda (console/API upload) | 50 MB zipped / 250 MB unzipped | Zip archive, including layers | AWS Lambda quotas docs |
| Vercel Functions | 250 MB (500 MB for Python) | Uncompressed, including layers | Vercel Functions limitations docs |
| Google Cloud Run functions | 100 MB compressed / 500 MB uncompressed | Source plus modules | Google Cloud Functions quotas docs |
Cloudflare’s 64 MiB figure still trails AWS Lambda’s 250 MB unzipped ceiling, Vercel’s 250 to 500 MB range, and Google’s 500 MB uncompressed allowance. But the comparison that matters is not the absolute number, it is the direction of travel and who the limit applies to. AWS, Vercel, and Google all size their functions for a traditional serverless model running in shared regional data centers with more headroom per invocation. Cloudflare Workers execute at the edge, in hundreds of points of presence simultaneously, on a runtime optimized for cold-start speed measured in single-digit milliseconds rather than the hundreds of milliseconds typical of container-based serverless. A larger bundle size ceiling narrows Cloudflare’s practical gap with the bigger clouds without changing the architectural trade-off that makes Workers faster to start but historically more bundle-constrained.
The gap that matters more for the D1 story has no equivalent table, because AWS, Vercel, and Google do not run a comparable edge-native SQL database with a comparable enforcement model. DynamoDB’s free tier is measured in monthly request units rather than daily row scans. Firestore throttles rather than fails outright. Cloudflare’s decision to fail queries completely once a daily cap is breached, rather than throttling or queuing them, is a stricter posture than most competing free database tiers, and it is the detail most likely to surprise developers who assumed a free tier meant degraded, not broken.
Why the Timing Points to FinOps, Not Just Engineering
Cloudflare rarely explains free-tier enforcement changes as cost-control measures in public, but the underlying economics are not hard to read. D1 runs on real compute and storage that Cloudflare pays for regardless of whether an account is on the Free or Paid plan. As more prototype apps, internal tools, and increasingly AI agents get spun up against D1, the aggregate load on shared infrastructure grows even if any individual free account stays small. Converting soft limits into hard limits is a direct lever for controlling that cost, and it is a lever cloud providers have pulled before, from AWS’s 2024 free-tier term changes to Google Cloud’s repeated adjustments to its always-free quotas as usage patterns shifted.
The Workers bundle size increase, by contrast, looks like a retention and competitive play rather than a cost play. A larger bundle limit does not cost Cloudflare much at the infrastructure level since the constraint was primarily about deployment validation, not ongoing compute. What it does is remove a reason for developers building with heavier frameworks, AI SDKs, or large dependency trees to choose AWS Lambda or Vercel over Workers in the first place. Lowering the compressed-size friction while tightening database enforcement is a coherent strategy: make it easier to start building on Workers, then make sure teams that outgrow the free database tier feel the wall clearly enough to upgrade rather than migrate away out of frustration with inconsistent behavior.
What This Means for Startups and Side Projects
For a hobby project or an early-stage prototype, none of this changes much. Five million row reads and 100,000 row writes per day is still a generous allowance for anything short of meaningful production traffic, and the storage ceiling of 5 GB comfortably covers most early-stage schemas. The risk shows up specifically for teams that were relying on the old soft-enforcement behavior as an informal buffer, treating the documented limits as guidelines rather than hard walls.
Three groups feel this most directly. Analytics and dashboard builders running unindexed queries against growing tables can burn through the row-read quota well before hitting anything resembling real user traffic, since the metric counts rows scanned rather than requests served. Multi-tenant SaaS prototypes sharing one D1 database across customers accumulate read volume faster than single-tenant apps and can hit the ceiling from aggregate load rather than any single customer’s usage. And teams that had been quietly exceeding limits without consequence now need to either optimize query patterns, shard across multiple D1 databases, or move to Workers Paid, where the same rows-read and rows-written meters convert into per-million-row billing rather than an outage.
Security Implications of the Tighter WAF Rules
From a pure security standpoint, moving SQL injection detections from Log to Block is a straightforward improvement, and it costs legitimate applications very little. The rules target specific, unusual query syntax patterns, complex WHERE clauses combined with WITH statements, and COPY-based injection attempts against PostgreSQL, that show up far more often in attack traffic than in normal application queries. Cloudflare applying the update across both free and paid tiers, rather than reserving stronger protection for paying customers, means smaller projects and side businesses that cannot afford a dedicated security budget get the same baseline protection as an enterprise account.
The tradeoff, as with any WAF tightening, is false positives. Teams running PostgreSQL with ORMs that auto-generate nested common table expressions, or admin tools that accept raw SQL from internal staff, are the most likely to see legitimate requests blocked. Cloudflare’s dashboard lets customers review WAF event logs and add scoped rule exceptions, but that requires someone on the team to actually notice the block, which is easy to miss on a low-traffic side project until a customer reports a broken feature.
How to Check Your Current Workers Bundle Size
Developers who want to see where their existing Workers deployment stands relative to the new 64 MiB ceiling can run a dry-run deploy with Wrangler, which now reports both the uncompressed Total Upload figure that counts against the limit and the legacy gzip estimate for reference.
npx wrangler deploy --dry-run
# Sample output
# Total Upload: 8.42 MiB / gzip: 2.10 MiB
# Worker Startup Time: 12 ms
# --dry-run: exiting before deployingAnything comfortably under 64 MiB in the Total Upload line deploys without issue on either Free or Paid plans. Teams closer to the ceiling should check whether they are bundling unused polyfills, large AI model client libraries, or duplicate dependency versions, since the removal of the compressed-size check means gzip efficiency no longer buys any headroom.
Historical Context: Cloudflare’s Pattern of Platform Tightening
This is not the first time Cloudflare has adjusted the terms of its free and paid Workers plans mid-year. The July 17, 2026 emergency WAF release, which added blocking rules for a critical remote code execution and SQL injection vulnerability affecting WordPress and other frameworks, showed the company is willing to ship defensive changes fast when active exploitation is underway, rather than waiting for a scheduled release window. Earlier in 2026, Cloudflare converted a batch of beta-stage SQL injection rules covering comment-based evasion and sub-query attacks into blocking rules, a smaller-scale version of the same pattern seen in September.
The broader trend across 2026 has been Cloudflare layering AI-facing infrastructure, from Sandboxes for running coding agents to expanded Workers AI bindings, onto the same Free and Paid plan structure that has existed for years. That layering creates pressure on the underlying resource limits, since AI agent workloads tend to generate bursty, unpredictable database and compute usage compared to traditional request-response web apps. Tightening D1 enforcement now, before agent-driven usage patterns become the norm rather than the exception, reads as Cloudflare getting ahead of a cost problem rather than reacting to one that has already spiraled.
Competitive Landscape: Where Cloudflare Sits Among Edge and Serverless Platforms
Cloudflare Workers, AWS Lambda, Vercel Functions, and Google Cloud Run functions are converging on similar feature sets even as their underlying architectures stay distinct. AWS Lambda remains the default choice for teams already inside the AWS ecosystem, with the deepest set of integrations into other AWS services and a deployment size ceiling that gives more room for large dependency trees, containerized runtimes, and multi-language support. Vercel Functions lean on Next.js integration and developer experience, with limits that Vercel itself notes are ultimately enforced by AWS infrastructure underneath.
Google’s Cloud Run functions sit in the middle, with a 500 MB uncompressed allowance that beats Cloudflare’s new 64 MiB ceiling but comes with the higher cold-start latency typical of container-based execution. Cloudflare’s differentiator has never really been bundle size. It has been edge placement and startup speed. The September 2026 changes narrow the gap on one weakness, bundle size, while reinforcing that Cloudflare intends D1 to be treated as a real database with real limits, not an informally unmetered convenience layer bolted onto Workers.
What Happens Next: Five Predictions
Several developments look likely to follow from this round of changes. First, expect Cloudflare to publish usage-optimization guidance for D1, similar to what AWS did after tightening its own free-tier terms, aimed at helping developers stay under the row-read ceiling through indexing and query design rather than simply upgrading. Second, D1 sharding patterns, splitting one logical database across multiple D1 instances to multiply the effective daily quota, will likely become a more commonly discussed workaround among Workers developers over the next few months.
Third, Cloudflare’s Workers Paid conversion rate among free accounts that hit the new hard D1 limit is worth watching as a signal of whether this was primarily a cost-control move or a monetization move, though Cloudflare does not typically break out that metric publicly. Fourth, given the pace of 2026 WAF releases, more SQL injection and related rules currently sitting in Log-only mode across the Managed Ruleset are likely to graduate to Block status before the end of the year, continuing the pattern set in January, July, and September. Fifth, competing edge platforms, including Deno Deploy and Vercel’s own edge runtime, will likely respond to Cloudflare’s bundle size increase with their own limit adjustments, since edge compute has become competitive enough that a meaningful developer-experience gap rarely stays unaddressed for long.
What Developers Should Do Right Now
Teams running production or near-production workloads on D1’s free tier should check their current daily row-read and row-write volume against the 5 million and 100,000 thresholds before a traffic spike triggers the new hard cutoff. Cloudflare’s dashboard, under Metrics and Row Metrics for each D1 database, shows this directly. Anyone deploying Workers with dependency-heavy bundles should re-run a dry-run deploy to see where they land against the new 64 MiB uncompressed ceiling, since the removal of the compressed-size check may open room to un-tree-shake libraries that were previously stripped down purely to fit under 3 MB. And any team running PostgreSQL through D1’s external database connections or using raw SQL admin tools should scan recent WAF logs for new SQL injection blocks that could indicate false positives rather than actual attacks.
Frequently Asked Questions
What exactly changed with Cloudflare D1 on September 1, 2026?
Cloudflare began enforcing daily row read and row write limits on the Workers Free plan as hard cutoffs. Queries that exceed 5 million rows read or 100,000 rows written in a day now fail with errors until the quota resets at 00:00 UTC, rather than continuing to run inconsistently past the documented limit.
Did Cloudflare lower the D1 free tier limits themselves?
No. The 5 million rows read, 100,000 rows written, and 5 GB storage figures are unchanged. What changed is enforcement: exceeding those limits now causes queries to fail rather than behaving inconsistently.
How big can a Cloudflare Worker be now?
Up to 64 MiB, measured as the uncompressed bundle size, on both Workers Free and Workers Paid plans. This replaced the old system that capped compressed bundle size at 3 MB on Free and 10 MB on Paid.
How does Cloudflare’s 64 MiB Workers limit compare to AWS Lambda?
AWS Lambda allows a 50 MB zipped deployment package, or up to 250 MB unzipped including layers, according to AWS’s own quotas documentation. Cloudflare’s 64 MiB uncompressed limit is smaller than Lambda’s 250 MB uncompressed ceiling but far larger than Cloudflare’s own previous limits.
Will the new WAF SQL injection rules block legitimate requests?
For most applications, no. The rules target unusual query syntax, complex WHERE clauses combined with WITH statements and certain PostgreSQL COPY-based patterns, that rarely appear in normal application traffic. Teams running complex ORM-generated queries or raw SQL admin tools should review WAF logs for false positives.
Do I need to upgrade to Workers Paid because of these changes?
Only if your D1 usage regularly approaches or exceeds the free daily quotas, or if your Worker bundle previously needed the extra headroom that Workers Paid provided under the old compressed-size limits. The bundle size increase now applies equally to both plans, so that specific reason to upgrade has gone away.
What is a row read in D1’s billing and limits model?
It measures rows scanned by a query’s execution, not the number of rows returned or the number of requests made. A query that scans a large table to return a small filtered result still counts every scanned row against the daily limit, which makes indexing and query efficiency directly relevant to staying under quota.
