Binding reference Bindings

Use D1 when the worker wants real queries instead of key-value tricks

D1 gets the same stable-name authoring story as KV, but the runtime shape is relational: , , , and prepared statements.

Devflare keeps D1 readable in config and testable in local runtime, which means you can model actual query behavior before you wire up preview or deploy steps.

Config key: bindings.d1
Authoring shape: Record<string, string | { name: string } | { id: string }>
Best for: Structured data, SQL queries, and cases where key-based lookup is not enough

Author it in the simplest shape that still says what you mean

D1 follows the same stable-name instinct as KV: author by readable name unless you intentionally already have a database id you want to pin to.

That gives teams one repeatable review habit: look for human-meaningful names in source, then inspect generated or resolved output only when a deploy flow needs it.

D1 binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'd1-worker',

bindings: {

d1: {

DB: 'app-db',

AUDIT: { name: 'audit-db' },

LEGACY: { id: 'd1-database-id' }

}

})

When this binding fits best

Use D1 when the worker needs SQL, joins, or a schema that should be queried instead of fetched by a single key.
It fits better than KV for records that need filtering, ordering, or transactional updates.
If the only operation is key lookup or a tiny cache record, KV usually stays simpler.

Notes worth keeping visible

Run after binding changes so the database bindings show up correctly in .
Preview-scoped databases are useful when branch data must stay isolated, but they should still be provisioned and cleaned up deliberately.
Name-based D1 authoring is readable, but build and deploy still need a path that resolves those names to ids before output is treated as final.

Do not hide the database shape

The point of D1 docs is to keep SQL visible enough that reviewers can still understand what the worker is doing, not to hide every query behind framework glue.

Cloudflare docs vs the Devflare layer

Cloudflare D1 docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

Reference

Cloudflare D1 docs

Cloudflare Docs

Platform reference for D1 databases, Worker APIs, migrations, and database limits.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for D1 databases, Worker APIs, migrations, and database limits.	How to author , what the runtime surface looks like, and how D1 fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself.	First-class local runtime and tests. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

Go deeper only if this one-page guide stops being enough

Subpage

D1 internals

Internals

See normalization, Wrangler , and the preview or runtime details behind the authored shape.

Subpage

Testing D1

Testing

Start from with or and only escalate when the binding or deployment model genuinely needs it.

Subpage

D1 example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.