Edge databases explained: what Cloudflare D1 means for your app's speed and cost

Most application databases spend their lives waiting. A server sits in a rack in northern Virginia, powered on around the clock, holding a few hundred megabytes of customer records, and answers maybe four hundred queries an hour. You pay for the rack time, not the queries.

Edge databases invert that. Cloudflare D1 is the one we reach for most, and the short version is: it’s SQLite, run as a managed service on Cloudflare’s network, billed by what you actually read and write. That change sounds small. It moves both the speed math and the cost math for a normal business app.

Here’s what’s actually going on, where it helps, and where it’s the wrong tool.

What “SQLite at the edge” actually means

SQLite is not a toy. It’s the most widely deployed database engine in existence — it’s in every iPhone, every Android phone, every browser, most desktop software, and a great many airplanes. It’s been in continuous development since 2000, it has an aviation-grade test suite, and it’s public domain.

What makes it different from Postgres or MySQL is that it isn’t a server. There’s no daemon listening on a port, no connection pool, no authentication handshake. It’s a library that reads and writes a single file. Your code and your data live in the same process.

D1 takes that model and runs it on Cloudflare’s network. You still write ordinary SQL:

• CREATE TABLE, SELECT, JOIN, GROUP BY, indexes, foreign keys, transactions
• Migrations as plain .sql files, versioned in your repo
• A schema you could hand to any SQL developer and have them understand in a minute

What you don’t do is size an instance, pick a region, configure a connection pool, tune max_connections, or pay for the hours when nobody visits.

Why this arrangement works now and didn’t before

Two things had to be true. First, the compute had to move — Cloudflare Workers run your application code in hundreds of cities rather than one region, so there’s an “edge” for the database to sit next to. Second, D1 had to grow up: read replication, real migrations, backup and point-in-time restore, a stable API, and a sessions model that keeps reads consistent for a given user. By 2026 those exist. Five years ago the honest answer was “not yet.”

The three things that actually change

Speed is about round trips, not query time

Here’s the part most people get backwards. SQLite querying a few hundred thousand rows with a decent index is fast — sub-millisecond fast. So is Postgres. The engine was almost never your bottleneck.

The bottleneck is distance, multiplied by how many times you cross it. A page that runs six sequential queries against a database 2,000 miles away pays that round trip six times before it renders anything. That’s where the “why is our dashboard slow” feeling comes from, and no amount of query optimization fixes it, because the queries aren’t slow — the phone line is long.

Edge databases attack the distance. Code runs near the user, read replicas put a copy of the data near the code, and the six round trips shrink toward local. For a read-heavy app — and most business apps are overwhelmingly read-heavy — that’s the whole ballgame.

Two honest caveats. Writes still go to a single primary, so a write from Sacramento pays the trip to wherever the primary lives. And a chatty query pattern is still a chatty query pattern; fixing the N+1 in your code will usually beat any infrastructure change you can buy.

Cost stops scaling with time and starts scaling with use

A managed Postgres instance bills for existence. The smallest production-grade instance at a traditional cloud provider, plus a standby for failover, plus backup storage, lands in the low hundreds per month before a single customer touches it. That’s the floor, and it doesn’t move whether you serve 100 requests a day or 100,000.

D1 bills on rows read, rows written, and gigabytes stored. There is no floor. An internal tool used by nine people at a contracting company costs pennies. A public app doing real traffic costs meaningfully more, but the curve starts at zero and bends gently.

For the client apps we ship, the whole stack — Pages, Workers, D1, R2, KV — typically runs $40–$300/month, and D1 is a small slice of that. The database line item stops being something anyone thinks about. (Cloudflare’s per-unit rates change; check their pricing page rather than trusting a number in a blog post, including this one.)

Operations mostly disappear — but application design doesn’t

No instance to patch, no version upgrade window, no connection pool exhaustion at 2 a.m., no “the database ran out of disk” page.

What remains: schema design, migrations, indexes, seed data, secrets management, and knowing what happens when a write fails. The edge removes infrastructure babysitting. It does not remove engineering. Anyone who tells you serverless means you stop thinking about the database is selling something.

Where D1 is genuinely the right answer

• Content-and-forms sites with a dynamic layer. Marketing site, gated resources, quote requests, a small admin view. Overwhelmingly reads.
• Internal business tools. Job tracking, inventory, scheduling, approvals — the spreadsheet replacements. Small data, modest write volume, high value.
• Client portals. Login, view your projects, download documents, submit a request.
• Analytics and event logging at moderate volume. Append rows, aggregate on a schedule.
• AI workflow state. Conversation history, extraction results, job queues, audit logs for automated workflows. The data volume is small; the read pattern is hot.

Notice the shape: modest data size, read-dominant traffic, latency the user can feel.

Where it’s the wrong tool

Be blunt about this, because picking wrong is expensive later.

The single-primary write model is the real ceiling. SQLite serializes writes; that’s a design choice, not a defect, and it’s why it’s so reliable. If your app’s defining characteristic is thousands of concurrent writers hitting the same table, you want a database built for that, and Cloudflare will happily sit in front of it.

Also worth saying plainly: if your current Postgres setup works and costs $60/month, migrating it to the edge is not a project with a payback case. Do it on new builds.

Portability, which is the question you should ask

Every platform decision should come with an exit. D1 exports to standard SQL. SQLite’s file format is documented to a degree almost nothing else in software matches, and the project has a stated commitment to support it into the 2050s. Moving to Postgres later is a schema-translation task — real work, but a Tuesday, not a crisis.

The stickier dependency in an edge stack is the Workers glue and routing around the database, not the data. That’s true of every platform’s serverless layer, and it’s the thing to weigh honestly before you commit.

How we actually decide

On a new custom app, the database question takes about twenty minutes and comes down to four answers:

1. How big does the data get in three years? Under a few gigabytes per logical database, D1 stays comfortable.
2. What’s the read-to-write ratio? Strongly read-heavy favors the edge. Write-saturated doesn’t.
3. Does anything need a Postgres-only feature? Geospatial queries, vector search, exotic extensions — if yes, that decides it.
4. Who maintains it after launch? Fewer moving parts means fewer things a small business has to keep alive.

Then it gets tested. Test-driven development is house policy here, and database code is where it earns its keep — migrations that run against a real schema, queries with assertions, and a suite that fails loudly when someone changes a column. You can see how we run projects on our process page, and what past builds looked like in our work.

You probably don’t need to care

If you own a business rather than write the code, here’s the whole article in four questions to ask whoever builds your app: Was the database chosen deliberately for this workload? Can we export the data? What’s the monthly run cost at our expected traffic? Who fixes it at 2 a.m.?

Good answers to those four matter more than which engine won. A well-designed app on the wrong database is still a good app. A badly designed one on the perfect database is still slow.

If you’re weighing an edge stack for a build in Rocklin, Roseville, Auburn, Lincoln, or anywhere else in the Sacramento region, we’re happy to talk through whether it fits — including telling you it doesn’t. We quote flat, we’re at 6770 Stanford Ranch Rd in Roseville, and a conversation costs nothing.

Related reading: The 2026 Cloudflare stack: Workers, D1, and the edge · Why we build on Cloudflare · Why your website should be boring and fast · Custom apps we build