Binding reference Bindings

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

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

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
Authoring shape
Best for: Structured data, SQL queries, and cases where key-based lookup is not enough

Add the binding to config

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.

In reviews, look for human-meaningful names in source. 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' },

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

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first D1 path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

A tiny route that proves the binding works

import { env } from 'devflare/runtime'

export async function fetch(): Promise<Response> {

const row = await env.DB.prepare('select 1 as ok').first<{ ok: number }>()

return Response.json({ ok: row?.ok === 1 })

}

Local and Remote Support

Devflare can run useful D1 application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Local runtime and tests. Start locally with with or ; that lane should cover the normal D1 application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only D1 details.

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.

Testing path

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.

Open the next page when you need it

Subpage

D1 internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing D1

Testing

Pick the with or path first, then move to remote checks only when the test needs them.

Subpage

D1 example

Example

Copy a fuller application path when the quick example is too small.