SYSTEM Cited by 3 sources

Cloudflare D1

D1 is Cloudflare's serverless SQLite database offered as a first-class Workers binding (developers.cloudflare.com/d1). Each database is a SQLite file hosted by Cloudflare and accessed from Workers via a binding; no connection management from user code.

Role

• OLTP-style relational storage colocated with Workers edge compute.
• Exposed to Workers as an RPC-style binding (not raw SQL over the wire from the client).
• Under local dev, D1 is backed by a local SQLite file managed by Miniflare; identical API shape to production (Source: sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare).

Local / remote parity

D1 is one of the binding types exposed through Local Explorer's API at /cdn-cgi/explorer/api. Same queries, same results, same responses — the only difference between local and remote is the --local flag on cf or Wrangler. Seeding, schema-verification, and DROP TABLE are all agent-accessible in local dev.

Seen in

• sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster — canonical wiki instance of D1 as the post-migration allocation-state store for an exclusive-resource hot path. Browser Run migrated container-allocation state from Workers KV to D1 because KV's eventual consistency (recently reduced 60s → 30s minimum cache TTL, "still too high") caused race-condition overallocation on the claim hot path under demand spikes from AI agent builders. D1's transactional SQLite supports

atomic check-mark-return claim via:

WITH candidate_pool AS ( /* candidate pool logic */ )
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
    SELECT sessionId FROM candidate_pool
    ORDER BY RANDOM() LIMIT ?5
) RETURNING data

Two operational disclosures: shards are per-location (matched to the per-region queue naming convention), and batch-write P95 is 0.1 ms — meaning a 100-row batch costs the same wall-clock as a single-row write, lifting the per-location ceiling from 5,000 (per-row, ~1 ms) to 500,000 containers (100× headroom) when paired with Queues-batched writes. Canonical wiki instance of queue-batching-amortizes-db-write-throughput (state-update path) and transactional-db-over-eventually-consistent-kv-for-claim (claim path). - sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare — mentioned as one of the remote-or-local bindings the new CLI is designed to unify.

Related

• systems/cloudflare-workers
• systems/miniflare
• systems/cloudflare-local-explorer
• systems/wrangler-cli
• systems/cloudflare-queues — paired upstream for batched-write amortisation in Browser Run's state-tracking pipeline.
• systems/cloudflare-browser-rendering — canonical 2026-05-13 consumer for both atomic-claim + batched-state-update paths.
• systems/cloudflare-kv — eventually-consistent sibling primitive replaced for the allocation hot path.
• sqlite-transaction-for-atomic-resource-claim — the canonical D1 SQL primitive for race-free claim.
• concepts/eventual-consistency — the failure mode that drove the migration onto D1.
• transactional-db-over-eventually-consistent-kv-for-claim — the canonical migration-pattern.
• queue-batching-amortizes-db-write-throughput — the throughput-amortisation pattern D1 batch-write P95 0.1 ms enables.
• sources/2026-05-28-cloudflare-how-we-built-cloudflares-data-platform-and-an-ai-agent-on-top-of-it — D1 as the relational metadata store inside Town Lake. Two distinct roles in the data platform: (a) Lifeguard stores access rules in D1 — "Lifeguard is our access control service: it stores access rules in D1, dynamically pulls user and group membership from our internal access management system, and renders a combined JSON policy that Trino reads over HTTP" — the durable access-policy substrate of Cloudflare's default-closed governance; (b) Transformer ELT stores run history in D1 — the relational metadata for queries over past pipeline runs (which steps ran when, durations, errors). Third major dogfood role in the Cloudflare corpus (Browser Run state-tracking → CLI binding → Town Lake's relational metadata).

Spec-reviewer state store

Cloudflare's spec reviewer uses D1 for review results and execution state while a Worker discovers specs and AI Gateway routes model calls. This is a distinct D1 role from allocation claims, policy metadata, and ELT run history: stateful workflow coordination for an asynchronous AI review service. The post does not disclose D1 schema, location strategy, or retention. (Source: sources/2026-08-04-cloudflare-how-cloudflare-enforces-engineering-standards-using-ai)

Seen in

• sources/2026-08-04-cloudflare-how-cloudflare-enforces-engineering-standards-using-ai — D1 as persisted review state/results for the spec-reviewer platform.