Cloudflare D1 Free Tier: Limits, Pricing, and 5 Alternatives (2026)

TL;DR: Cloudflare D1’s free tier gives you 5 million row reads per day, 100,000 row writes per day, and 5 GB of total storage across all your databases - no credit card required on the Workers Free plan. Limits reset daily at 00:00 UTC. Queries simply stop working once you hit a daily cap; storage blocks new inserts, schema changes, and index creation once you hit 5 GB. If that’s not enough, Turso, Supabase, and Neon are the strongest free-tier alternatives, depending on whether you need SQLite compatibility or full Postgres.

What is Cloudflare D1?

D1 is Cloudflare’s serverless SQL database, built on SQLite and designed to run at the edge alongside Cloudflare Workers. Instead of provisioning a server, you create a database, bind it to a Worker, and query it with a driver that looks almost identical to better-sqlite3 or any other SQLite client. Reads happen close to wherever the request originated, which is the whole pitch: low-latency SQL without running your own database server.

D1 sits in Cloudflare’s broader storage lineup next to KV, R2, and Durable Objects, but it’s the only one that speaks SQL. That makes it the natural pick for anything that outgrows a key-value store - user accounts, order history, anything with relationships between rows - without wanting to run Postgres yourself.

The free tier is generous enough to build and test a real application on, and specific enough that it’s worth knowing the exact numbers before you commit an app’s data layer to it.

D1’s free tier limits, in full

D1’s free allowance ships as part of the Workers Free plan - no credit card needed to get started. Here’s what it includes, straight from Cloudflare’s own pricing page:

5 million rows read per day
100,000 rows written per day
5 GB total storage, shared across every database in your account
Daily read/write limits reset at 00:00 UTC
Access to prototype and experiment with D1 at no cost on the Workers Free plan

There’s no time limit on any of this. Unlike a 12-month intro tier or a 30-day trial database, D1’s free allowance renews every day for as long as your account exists - it’s a genuine free tier, not a countdown.

D1 free vs. D1 paid

If you outgrow the free plan, D1 usage on Workers Paid is metered rather than capped - you get a larger included allowance, then pay per unit beyond it:

	D1 Free (Workers Free)	D1 Paid (Workers Paid, $5/mo base)
Rows read	5,000,000 / day	25,000,000,000 / month included, then $0.001 per million rows read
Rows written	100,000 / day	50,000,000 / month included, then $1.00 per million rows written
Storage	5 GB total	5 GB included, then $0.75 per GB-month
Credit card required	No	Yes
Behavior at the cap	Queries fail once the daily limit is hit	Billed automatically, no hard stop

The jump from free to paid is steep on paper - 25 billion reads a month dwarfs 5 million a day (roughly 150 million a month) - but the per-unit price stays low even past that: a million extra row reads costs a tenth of a cent. For most side projects, the free tier’s daily caps are the real ceiling, not the paid plan’s pricing.

What happens when you hit a cap

This is the part that trips people up, because D1 doesn’t behave like a database with soft throttling - it behaves like a switch:

Hit the daily read or write cap and queries against that database stop succeeding until the next UTC day rolls over. There’s no burst allowance, no grace period, no partial degradation - the request just fails.
Hit the 5 GB storage cap and D1 blocks new inserts, schema changes, and creating new indexes or triggers. Existing reads keep working; you just can’t grow the database further until you free up space or upgrade.

If you’re building something with real traffic, budget for this explicitly. 100,000 writes/day sounds like a lot until you do the math on a busy app logging events, updating session state, or writing analytics rows - that can burn through six figures of writes well before a human user base would call the app “popular.”

Is D1’s free tier enough for your project?

For prototypes, personal projects, and low-traffic apps, yes - comfortably. But read the read limit carefully, because it’s the one most people misjudge: 5 million rows read per day works out to roughly 58 rows per second sustained around the clock. That’s rows, not requests. A query that scans 100 rows spends 100 of your daily allowance, so at that rate you’d sustain well under one request per second - and an unindexed query scanning a large table can burn through the cap far faster than your request count suggests. Add an index and the same query might read a handful of rows instead of thousands. In our view the 5 GB storage cap tends to be the less surprising limit of the two: it’s plenty for structured app data (users, posts, orders) but tight if you’re storing anything resembling blobs or logs directly in D1 rather than in R2 or an object store.

Two situations where D1’s free tier specifically falls short:

Write-heavy workloads. Anything ingesting events, telemetry, or high-frequency updates will hit the 100K writes/day ceiling faster than the read ceiling. If your workload is write-dominant, look at a database priced by storage and compute rather than a hard daily write cap.
You need a relational engine beyond SQLite’s feature set. D1 is SQLite under the hood - excellent for straightforward relational data, but it doesn’t have Postgres’s extension ecosystem (no pgvector, no PostGIS, no stored procedures in the Postgres sense). If your project needs those, a Postgres-compatible free tier is the better fit from day one.

5 free-tier alternatives to D1

If D1’s shape doesn’t fit - too little storage, the wrong query engine, or you’re not inside the Workers ecosystem to begin with - here’s how the strongest free-tier databases compare on the axes that actually matter: storage, throughput, and whether you need a credit card to start.

Product	Engine	Free storage	Free throughput	Credit card?	Best for
Cloudflare D1	SQLite (edge)	5 GB	5M rows read/day, 100K rows written/day	No	Workers-native apps, low-latency edge reads
Turso	SQLite (libSQL)	5 GB	500M reads/mo, 10M writes/mo	No	SQLite compatibility outside Cloudflare’s ecosystem
Supabase	Postgres	500 MB/project (2 projects)	Unlimited API requests	No	Full Postgres + built-in auth, storage, realtime
Neon	Postgres (serverless)	0.5 GB/project (100 projects)	100 CU-hours/project/mo	No	Branching, autoscaling Postgres for many small projects
CockroachDB	Distributed SQL	10 GiB	50M request units/mo	No	Multi-region durability without a SQLite ceiling
Amazon Aurora DSQL	Distributed SQL	1 GB/mo	100,000 DPUs/mo	Yes (AWS account)	Teams already inside AWS wanting distributed Postgres-compatible SQL

A quick read on each:

Turso is the most direct like-for-like swap - it’s also SQLite (technically libSQL, a SQLite fork), so query syntax and mental model carry over almost exactly. Its free tier is measured monthly rather than daily (500 million reads and 10 million writes per month, versus D1’s daily caps), which in practice gives Turso more headroom for bursty traffic, since a slow week banks unused capacity that D1’s daily reset throws away.

Supabase and Neon are the moves if you specifically need Postgres rather than SQLite - extensions, JSONB, full-text search, or just familiarity. Supabase bundles auth, storage, and realtime subscriptions around the database, so it’s less “just a database” and more “backend-as-a-service.” Neon is closer to a pure database: it leans into branching (spin up a full copy of your schema and data for a PR, throw it away after merge) and lets you run up to 100 small projects at 0.5 GB each rather than one big one - handy if you’re managing many small apps instead of one large one.

CockroachDB and Amazon Aurora DSQL are the options for when “edge SQLite” undersells what you need - genuinely distributed SQL with multi-region durability. Both are newer entrants to the free-tier conversation and price their free allowance in abstract compute units (Request Units for CockroachDB, DPUs for Aurora DSQL) rather than a flat read/write count, which takes a bit more work to map onto expected traffic but scales further before you need to pay anything.

Which should you actually use?

If you’re already building on Cloudflare Workers, stick with D1 - the integration is native and there’s no reason to add a network hop to an external database for most use cases. If you’re not on Workers, or you specifically want SQLite semantics somewhere else, Turso is the closest match. If your project needs Postgres-specific features - extensions, complex joins, an ecosystem of ORMs that assume Postgres - Supabase or Neon will save you a rewrite later. And if you’re building something that genuinely needs to survive a regional outage, CockroachDB or Aurora DSQL are worth the extra setup complexity.

FAQ

Does Cloudflare D1’s free tier expire? No. Unlike a 12-month intro tier or a time-boxed trial, D1’s free allowance is a standing part of the Workers Free plan and renews daily for as long as your account is active.

Do I need a credit card to use D1’s free tier? No. The Workers Free plan, which includes D1’s free allowance, doesn’t require payment details to sign up.

What happens to my data if I exceed the 5 GB storage limit? Nothing is deleted. D1 blocks new inserts, schema changes, index creation, and trigger creation until you either free up space or upgrade to the paid plan. Existing reads continue to work.

Can I run D1 outside of Cloudflare Workers? Not directly - D1 is designed to be bound to and queried from Workers. If you need a similarly SQLite-flavored database usable from any runtime, Turso is the closer fit.

Is D1 an always-free service or a free tier with a paid upgrade path? It’s a free tier: a permanent allowance (5M rows read/day, 100K rows written/day, 5 GB storage) alongside a metered paid plan for anything beyond that, not an unbounded always-free offering.