Cloudflare D1 explained: serverless SQLite for your content

You’re looking into EmDash, you see “content lives in D1,” and you want to know what that actually means before you trust your site to it. Is D1 a real database? Is SQLite serious enough for production? What are the limits, and where does it fall over? Fair questions. Let’s answer them plainly.

What D1 is, in one sentence

Cloudflare D1 is a serverless SQLite database, a real SQL database that Cloudflare runs and scales for you, living right next to your Cloudflare Workers so your code can query it without managing a database server.

Two words there deserve unpacking: SQLite and serverless.

SQLite, yes, that SQLite, and yes, it’s serious

SQLite has a reputation as the “little” database, the one embedded in your phone, your browser, your car. That reputation undersells it. SQLite is one of the most widely deployed and battle-tested pieces of software on earth, it’s genuinely fast, and it speaks standard SQL: tables, indexes, joins, transactions, the works.

What it traditionally wasn’t is a networked, multi-machine database. Classic SQLite is a file on one disk, read and written by one process. That’s perfect for embedded use and awkward for a global web app, which is the problem D1 solves.

Serverless, Cloudflare runs the SQLite for you

D1 takes SQLite and wraps it as a managed, serverless service:

• No server to run. You don’t provision or patch a database box. You create a database and query it from your Worker.
• It’s provisioned on demand. With EmDash, wrangler creates the D1 database for you on first deploy, there’s no separate “stand up Postgres” step.
• It scales down to nothing. Like Workers, an idle database isn’t costing you a running server.

So you get SQLite’s speed and simplicity, plus the operational model of “there is no database server to think about.”

When D1 is a great fit

D1’s sweet spot is clear, and a content site sits right in the middle of it:

• Read-heavy workloads. Sites that serve far more reads than writes, blogs, docs, marketing sites, most CMSs, are ideal. Reads are what D1 does fastest.
• Moderate write volume. Publishing a post, editing content, the occasional form submission, all fine.
• Data that fits comfortably in a SQLite-shaped box. Structured, relational content. Exactly what a CMS stores.

If your app is read-mostly with sane write rates and a database that fits within a single logical SQLite database, D1 is a strong, simple choice.

The limits, be honest about them

No database is magic, and D1 has real edges you should know before betting on it:

• Size ceiling per database. A single D1 database maxes out around 10 GB. That’s a lot of text content, think many thousands of articles, but it’s not unlimited. Huge datasets need a different plan (or splitting across databases).
• Write concurrency. SQLite’s model favors reads; very high concurrent-write workloads aren’t its strength. A CMS rarely hits this, but a write-heavy analytics firehose would.
• It’s SQLite, not Postgres. No Postgres-specific extensions, no stored procedures in a PL/pgSQL sense. If you depend on advanced Postgres features, D1 isn’t a drop-in.
• Still maturing. D1 is relatively young as managed databases go. It’s production-ready for its sweet spot, but it’s not a decades-old Postgres install.

The honest summary: for a content site, none of these limits are likely to bite you. For a write-heavy, multi-terabyte application, D1 is the wrong tool, and that’s fine, it’s not trying to be that.

How EmDash uses D1 for your content

EmDash, Cloudflare’s open-source CMS, stores its structured content and metadata in D1. Because content is portable JSON rather than a blob of HTML, it maps naturally onto SQL tables: posts, fields, taxonomy, relationships. When a reader hits a page, the Worker queries D1 (right next to it, no cross-network hop to a distant database) and renders the page at the edge.

The developer experience is deliberately boring, which is the point:

# EmDash provisions D1 for you on first deploy, but you can also
# create and inspect a database directly with wrangler:
npx wrangler d1 create my-site-db
npx wrangler d1 execute my-site-db --command "SELECT count(*) FROM posts;"

On the very first deploy, EmDash applies its schema migrations automatically on the first request, so you don’t hand-run SQL to get started. The whole flow is covered in the deploy EmDash to Cloudflare guide.

Why this pairing works so well for a CMS:

• Content lives beside the compute. Worker + D1 in the same edge network means fast queries without a round-trip to a remote database.
• Read-heavy is D1’s home turf. Serving content is overwhelmingly reads, exactly what D1 optimizes for.
• The 10 GB ceiling is enormous for text. A blog or docs site will store years of content and not come close.
• No database ops. No Postgres to size, patch, back up manually, or keep alive at 3am.

Where D1 sits in the bigger picture

D1 is one leg of a three-part serverless stack that EmDash stands on:

• Workers run the code at the edge.
• D1 holds the structured content.
• R2 stores the files and media (with no egress fees).

Each is serverless and scales to zero, so a small site can cost almost nothing and a busy one scales without you re-architecting. It’s the same reason Cloudflare’s own blog runs on this stack and absorbed a 28,000 RPS DDoS without drama.

If you’re evaluating EmDash and worried “SQLite can’t be serious,” the honest answer is: for a content site, it absolutely is, and D1 gives you SQLite’s speed with none of the server babysitting.

We cover this because our readers ask about it. What we actually do at 2emdash is rebuild ageing websites on Cloudflare and hand the owner a simple panel to run them from. We’re an independent service, not affiliated with Cloudflare or the EmDash project.