Under the hood Bindings

How Devflare wires D1 from config to runtime

D1 is Cloudflare’s serverless SQL database for applications that run on Workers.

D1 uses the same normalize-then-resolve pattern as KV, but compiles to Wrangler and exposes a relational local runtime surface.

The key implementation detail is that Devflare can keep a stable database name around until a flow truly needs the real database id. That keeps config readable without giving up deploy precision.

Normalization: Name-based authoring stays name-based until a build or deploy flow resolves it
Compile target: Wrangler
Preview note: Preview-scoped D1 databases can be provisioned and cleaned up by Devflare

How authored config becomes Wrangler config

Like KV, D1 bindings normalize into one internal shape so compiler and runtime code do not need to special-case string versus object authoring everywhere.

That normalized form is what lets Devflare keep the friendly source-of-truth shape while still generating strict Wrangler-facing output later.

D1 config and emitted Wrangler output

Use this when you need to check how the Devflare config becomes Wrangler-compatible config.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'd1-worker',

bindings: {

d1: {

DB: 'app-db',

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

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

}

})

What local runtime support covers

The local bridge exposes the D1 APIs people actually use: , , , and the prepared-statement helpers like , , , and .
can boot those bindings without a custom mock layer, which is why D1 tests can stay close to production query code.
If you only need isolated unit tests, exists, but it is usually weaker than the full runtime-shaped harness.

Compile, preview, and cleanup behavior

Build and deploy resolve name-based D1 records to real database ids before Devflare emits compiled config.
Compile rejects unresolved name-based D1 bindings instead of silently producing half-finished Wrangler output.
Preview resource management can create and later remove branch-specific D1 databases when the preview model truly owns separate data.

Same authoring rule, different runtime shape

The config story is close to KV, but the runtime story is SQL-shaped — as it should be.

Cloudflare docs vs the Devflare layer

Cloudflare D1 docs is the platform reference. Use this internals page when you need to compare Cloudflare's product docs with Devflare config, generated env types, local support, and preview behavior for .

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.	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.

D1

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

Testing D1

D1 is one of the easiest bindings to test meaningfully with Devflare because the local runtime already speaks the same database API your worker uses.