A delivery platform migrated parts of its data estate to CockroachDB and other parts to Aurora. What evidence distinguishes workloads that justify a distributed SQL database from those better served by a single-writer managed Postgres?

What each actually gives you

Aurora-style managed Postgres: a single writer, replicas for reads, storage replicated across availability zones, failover in tens of seconds. Full Postgres semantics, mature tooling, well-understood performance, and a hard ceiling — the write path is one node.

CockroachDB-style distributed SQL: horizontally scalable writes via Raft-replicated ranges, serialisable isolation by default, survivability of node and zone loss without failover, and geo-partitioning so rows can be pinned to regions. Costs: every write is a consensus round trip, contended transactions retry under serialisable isolation, and the operational and query-tuning knowledge is less common.

The evidence that justifies distributed SQL

• Write throughput that exceeds what one primary can absorb, demonstrated rather than projected — after connection pooling, batching and index tuning have been exhausted.
• A multi-region requirement with local write latency, where users in different geographies must write with low latency and geo-partitioning genuinely resolves it.
• A residency requirement that maps to row-level locality — customer rows must physically remain in a jurisdiction, which geo-partitioning expresses directly.
• An availability target that a failover window would breach. A single-writer database has a real interruption on primary failure; if seconds of write unavailability are unacceptable and this is written down, that is a legitimate driver.
• Table sizes where a single node's storage or vacuum behaviour has become the operational problem.

The evidence that argues for the simpler choice

• The workload is partitionable by tenant or entity and never needs cross-partition transactions — in which case sharded Postgres is simpler and faster than distributed consensus.
• Contention is concentrated. Serialisable isolation converts contention into transaction retries, and a workload with hot rows performs worse on distributed SQL than on single-node Postgres, which resolves the same contention with a local lock rather than a distributed one.
• The team is small. Operational unfamiliarity is a real cost and a real source of incidents.
• The scaling need is reads, not writes — replicas solve that far more cheaply.
• Postgres extensions matter to the workload.

The mixed estate is the correct outcome

The realistic answer is not one database. Order and delivery state — high write volume, partitionable, needing multi-region survivability — is a good fit for distributed SQL. Configuration, catalogue and internal tooling — modest volume, complex queries, low write rates — belongs on managed Postgres. The cost of running two is real and is smaller than forcing either workload onto the wrong engine.

The reversibility question decides the argument. Design against portable SQL, keep engine-specific features behind a boundary, and prove the migration path in a lower environment before committing — so that the choice can be revisited when the evidence changes, which it will.