Under the hood Bindings

How Devflare wires D1 from config to runtime

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

Devflare normalizes the authored shape before it does anything louder

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 from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

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' }

}

})

Local runtime support depends on what Devflare can model directly

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 unapologetically SQL-shaped. That is exactly how it should feel.

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.