A startup with a few thousand users is choosing between a single-region Postgres and a geo-distributed serializable database. What evidence should drive the decision, and what would trigger revisiting it?

The answer at this scale, and why

Single-region managed Postgres, almost certainly — and the reasoning matters more than the conclusion.

At a few thousand users, no evidence exists that a distributed database is needed, because no measurement has been taken that could produce it. The choice is therefore being made on anticipated future scale, which is the single most common source of over-engineering in the profession.

What Postgres gives at this stage: full relational semantics without distributed-transaction retry behaviour, mature tooling, an enormous knowledge base, extensions covering full-text search, JSON and vectors, and an operational model a small team can hold in their heads.

What distributed SQL costs at this stage: every write is a consensus round trip, contended transactions retry under serialisable isolation, the operational and query-tuning knowledge is scarcer, and the team spends attention on a capability it is not using.

The evidence that would justify the other choice

• Demonstrated write throughput beyond one primary — after connection pooling, batching, index tuning and read replicas have been exhausted. Projected throughput is not evidence.
• A multi-region requirement with local write latency, where users in different geographies must write quickly and geo-partitioning genuinely resolves it.
• A residency requirement that maps to row-level locality — customer rows physically remaining in a jurisdiction, which geo-partitioning expresses directly and which is otherwise a difficult problem.
• A written availability commitment that a failover window would breach. A single-writer database has a real interruption on primary failure; if seconds of write unavailability are genuinely unacceptable and this is documented, that is a legitimate driver rather than a preference.
• Single-node storage or vacuum behaviour having become the operational problem, which is a late-stage signal.

The evidence that argues against it even at scale

• The workload is partitionable by tenant with no 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, so a workload with hot rows performs worse on distributed SQL than on single-node Postgres, which resolves the same contention with a local lock. This surprises people and is worth stating plainly.
• The scaling need is reads, which replicas serve far more cheaply.

Designing so the decision is reversible

This is the substantive engineering work, and it is what makes the choice low-risk:

• Write portable SQL, keeping engine-specific features behind a boundary.
• Avoid depending on single-node behaviour that will not hold in a distributed engine — particularly sequences for ordering, and transactions that assume no retry.
• Handle serialisation failures in the data access layer from the start. A retry loop is cheap to add now and invasive to add later, and it costs nothing on Postgres.
• Keep the schema partitionable: ensure a tenant or locality key exists on every table that would need one, even if nothing uses it yet. This is the single cheapest piece of future-proofing available, and adding it retroactively to a large table is genuinely expensive.
• Prove the migration path in a lower environment before the decision becomes urgent.

The trigger to write down

"We revisit this when sustained write throughput exceeds X, or when we take on a customer with a residency requirement, or when p99 write latency for non-home-region users exceeds Y."

A decision with a stated trigger is a monitorable position rather than a snapshot, and it converts a recurring argument into an observation.