Cloudflare Workers, D1 and R2 as a default for new web apps

Why do developers make Cloudflare's developer platform (Workers, the D1 database and R2 storage) their default for new web apps, and which critiques of that choice hold up? AR Labs researched the question in November 2026. The report weighs vendor documentation, practitioner accounts, competitor guides and trade press, each source scored for credibility with the CRAAP test.

Method: one breadth pass, 2026-11-11. Five searches, 14 sources scored with the CRAAP test (Currency, Relevance, Authority, Accuracy, Purpose; weighted 0–5).

Summary

Developers choose Cloudflare's developer platform mainly because it is cheap or free at small scale, has no servers to manage, and keeps compute, database and storage under one account. Those reasons are well supported (High confidence). The "global edge" speed argument is weaker than it sounds. Code runs near each user, but D1, Cloudflare's database, writes to one primary location, so an app that reads and writes the database on every request loses most of that benefit (High). The main costs are runtime limits, lock-in through Cloudflare-specific connections, and a database that is still maturing (Moderate). These costs grow with the size and complexity of the app, which makes Cloudflare a sound default for small apps and a choice that needs deliberate review for a scaled product. No independent source explains why AI-coding playbooks favour Cloudflare. The only evidence on that question is Cloudflare's own promotion (Insufficient).

Terms

• Serverless: you upload code, and the provider runs it on demand. You never manage or patch a machine.
• Edge: Cloudflare's network of data centres in hundreds of cities. A Worker (a small serverless program) runs in whichever centre is nearest the person making the request.
• Binding: a line in the Worker's configuration that connects code to a Cloudflare service such as D1 (database), R2 (file storage) or a Durable Object (a small stateful server instance). Code reaches these services through Cloudflare-specific objects, not standard network protocols.
• Egress: data sent out of a provider's network to users. Most clouds charge for it per gigabyte.

Core findings

1. Cost and free tier are the strongest reason (High)

The free plan allows 100,000 Worker requests a day, and the paid plan costs $5 a month with 10 million requests included (Cloudflare pricing, vendor; Vercel KB, competitor, which concedes the point). D1's permanent free tier includes 5 GB of storage, 5 million rows read a day and 100,000 rows written a day, and there are no compute or data-transfer charges (InfoQ, Nov 2026). Practitioners describe their bills as "dirt cheap" and "always tiny" (Syntax #879). Workers bill for CPU time, so time spent waiting on another service's reply costs nothing.

Counterpoint (Moderate, single detailed account): billing has no hard spending cap. Two bugs in a solo developer's apps wrote 4.83 billion rows to D1, which turned a $5 monthly bill into a $4,586 invoice. Cloudflare waived it after 18 days of support. The developer still uses D1 but says users must build their own circuit breakers (Little Bear Apps, Mar 2026).

2. Zero egress matters only for apps that send a lot of data (High)

R2 charges nothing for egress, while AWS S3 charges $0.09 per GB. One file-processing service reports a bill in single-digit dollars where AWS would have cost $200–400 a month (Ryan, dev.to, Mar 2026; Syntax; Vercel KB). The same author notes that a low-transfer CRUD app (an ordinary create-read-update-delete app) gains little from this.

3. "Edge latency" is undone by single-region database writes (High)

Without read replication, D1 sends every query, reads and writes alike, to one database instance in one location. With replication turned on, writes still go to that primary instance (Cloudflare D1 docs, vendor). A Worker runs near the user and not near the database, so a page that makes several queries pays a long round trip for each one (Vercel KB). Measured examples include writes from Sydney to a Virginia primary taking 200–300 ms (Whoff, dev.to, low authority) and a Tokyo replica lagging writes by up to 6.1 seconds at the 99th percentile (riversea, dev.to). Cloudflare's own answer, Smart Placement, moves the Worker next to the database. That cuts the per-query round trips by giving up "running near the user".

4. Runtime limits are real but narrowing (High)

Workers run on V8 isolates (lightweight sandboxes from Chrome's JavaScript engine), not on full Node.js. Each isolate gets a fixed 128 MB of memory, and the CPU limit is 10 ms per request on the free plan and 30 s on the paid plan. A Worker's compressed code may not exceed 3 MB on the free plan or 10 MB on the paid plan (Vercel KB; Encore, Nov 2026, competitor; Syntax). Packages that need the filesystem or child processes fail. One practitioner had to write streaming ZIP code and a checkpoint/resume system to stay within the limits (Ryan). Cloudflare reports a year of work closing Node gaps, including node:net and node:http (Cloudflare blog, 2025, vendor). The usual reasons teams leave are memory-heavy jobs, Node-only libraries, long background work, and needing a regional Postgres database (Encore).

5. Lock-in sits in the code, less in the data (Moderate)

Practitioners on both sides acknowledge the lock-in. One podcast host calls it "probably the one downside" and limits it with a portable query library (Drizzle) and S3-compatible storage (Syntax). A framework author who is otherwise publicly critical of lock-in concedes the tension and proposes an "Open Bindings" specification to address it (RedwoodSDK, Dec 2025). A third practitioner says moving to AWS Lambda would need "significant rewriting" (Ryan). D1 is SQLite underneath, so the data itself is portable. The rewriting cost falls on code that depends on bindings and Durable Objects.

6. D1 maturity and size are disputed (Disputed)

Each D1 database is capped at 10 GB (500 MB on the free plan) and processes one query at a time. Cloudflare's guidance is to scale out to many small databases, such as one per user, rather than grow one large database (D1 limits, vendor). InfoQ cites Reddit users who call D1 unreliable for production, alongside 18-fold growth in daily active databases. Little Bear Apps calls the missing safeguards a "platform maturity gap". The Syntax hosts were positive. The disagreement lines up with scale: the complaints come from write-heavy or multi-database users.

7. Unified platform: real, but argued mostly by aligned voices (Moderate)

One account, one CLI (Wrangler) and one bill, with a local emulator that behaves like production and no credit card needed to start (RedwoodSDK; Syntax; Vercel concedes the single-dashboard benefit). RedwoodSDK builds its framework for Cloudflare, so its Purpose score is reduced.

8. Debugging, observability and the AI-playbook default (Insufficient)

No source assessed Cloudflare's logging and tracing directly. The Syntax hosts advise adding Sentry (an error-tracking service) to get error details. Little Bear Apps ran for days with no errors and no alerts while the runaway writes accumulated. Popularity in "vibe coding" (building apps by prompting an AI) is evidenced only by Cloudflare's own VibeSDK and reference architectures (Cloudflare). No independent source explains why playbooks prescribe Cloudflare.

Small app versus scaled product

For a small or single-user app, the strengths apply in full: free or $5 hosting, no server patching, a single deploy command. Most weaknesses do not apply: 10 GB is far more than one person's data, there is too little traffic to hit concurrency limits, and with one user the database can sit near that user. For a scaled product, write-heavy load, single-region writes, the 128 MB memory limit, missing spend caps and lock-in all grow. Teams leave at that stage (Encore; InfoQ's Reddit citations).

Implications

Consider a typical small case: a single-user app that records voice notes, running on one Worker with D1. Its likely load is light: small, infrequent reads and writes from one person in one place. On the evidence, "Cloudflare by default" is a sound choice for an app like this, but for different reasons than AI-coding playbooks give. Cost, no server operations and a single deploy target justify it. The edge and global-latency arguments add almost nothing for one user. "All-in, no side servers" is a matter of convenience, not a technical requirement. A VPS running a web server such as Caddy is a valid alternative: Node plus SQLite with no runtime limits and no lock-in, in exchange for the owner patching and backing up the server.

Three precautions follow from the findings. Confirm the D1 primary sits near the user. Keep any heavy audio processing out of the Worker, and call an external transcription service instead, which costs no Worker CPU while it waits. Add a usage alert or cap, because a write-loop bug is the one way a small app can produce a large bill.

Confidence: Moderate. The general findings are High, but this application to a single small app relies on assumptions about its workload that were not researched.

Evidence gaps

• Why AI playbooks default to Cloudflare: only vendor material was found. Query tried: "vibe coding AI agents deploy Cloudflare Workers default platform why agents choose Cloudflare".
• Observability and debugging: no direct evaluation was found. Queries tried: the lock-in and limits query and the D1 production critique query below.
• Sources that could not be retrieved: the "We Outgrew Cloudflare D1" article (404 via its HN mirror), a Reddit thread on D1 reliability (403), a Discord thread on Smart Placement latency (429), and a production cost-model blog (404).
• Other queries run: "Cloudflare Workers D1 production experience critique lessons learned 2025"; "why I build everything on Cloudflare Workers default stack free tier egress cost"; "Cloudflare Workers vendor lock-in Node.js compatibility limits CPU memory moved away"; "D1 single primary region write latency read replication Smart Placement".

Sources (CRAAP weighted score)

Source	Type	Score
Cloudflare D1 limits docs	Vendor docs	4.9
Cloudflare D1 read replication docs	Vendor docs	4.9
Cloudflare plans/pricing	Vendor	4.7
Cloudflare blog, Node.js compatibility 2025	Vendor (promotional)	4.3
InfoQ, D1 control plane, Renato Losio, 2026-11-08	Trade press	4.2
Vercel KB, Next.js on Vercel vs Cloudflare, 2026	Competitor	4.2
Syntax #879 "Fullstack Cloudflare", 2025-02-24	Practitioner podcast	4.0
Cloudflare AI vibe-coding reference architecture	Vendor (marketing)	4.0
Little Bear Apps, D1 billing disaster, Nathan Schram, 2026-03-18	Practitioner	3.75
RedwoodSDK, Why Cloudflare, Peter Pistorius, 2025-12-27	Aligned framework	3.55
Encore, Workers alternatives, Ivan Cernja, 2026-11-05	Competitor	3.4
Ryan, Zero egress (dev.to), 2026	Practitioner	3.05
riversea, D1 replica lag (dev.to)	Practitioner	2.95
Whoff, D1 after 6 months (dev.to)	AI-agent author, promotes kit	2.2 (fringe)

Confidence distribution: 4 High, 3 Moderate (including the single-user application), 1 Disputed, 1 Insufficient.