Skip to content

Multi-Region CockroachDB

Every MySQL or PostgreSQL architecture across regions hits the same limit: there is one primary. Reads spread out, caching helps, the local replica answers the SELECT — but writes still have to travel to a single region.

When the requirement is to write locally in more than one region, at the same time, the answer is not to bolt bidirectional replication onto a single-primary database — it is to use a database designed for it. CockroachDB speaks the PostgreSQL wire protocol, which lets you reuse drivers, tooling and most existing SQL, and distributes data in ranges replicated by consensus, with no primary and no manual failover.

How it works

Data is split into ranges, and each range is replicated (three copies by default) across different nodes. Every write requires acknowledgement from the majority of replicas — the quorum. There is no promotion and no split-brain: if a node or an entire domain goes down, the remaining majority keeps accepting writes.

Ranges replicated across three failure domains — br-sp-1, br-sp-2 and a third — with a leaseholder per range and Raft consensus between the replicas

Each range has three replicas in distinct failure domains; a write is acknowledged by two of the three.

Two regions do not form a quorum

With only two failure domains, losing one leaves half the replicas — and half is not a majority. A topology that survives the loss of an entire region needs three failure domains: br-sp-1, br-sp-2 and a third, which may be another region or a set of nodes dedicated to forming quorum. That is the requirement that defines the real cost of the project, and we address it right at the sizing stage.

Survival goals: how much the cluster must survive

Comparison between survive zone, which tolerates the loss of a node or rack, and survive region, which tolerates the loss of an entire region at the cost of cross-region writes

The survival goal is a database setting, not a cluster redesign — and it can change as the system matures.

SURVIVE ZONE FAILURE SURVIVE REGION FAILURE
Tolerates Loss of a node, rack or zone Loss of an entire region
Replica distribution May concentrate in one region Spread across three domains
Write latency Lower, local quorum Pays the cross-region round trip
Domains required One with multiple zones Three
Recommended for Most applications Systems that cannot stop when a datacenter goes down

Between br-sp-1 and br-sp-2 the distance is measured in milliseconds, so SURVIVE REGION FAILURE costs far less here than in an intercontinental topology — which is exactly what makes the configuration viable in Brazil.

Table localities: where each piece of data lives

REGIONAL BY ROW, REGIONAL BY TABLE and GLOBAL tables, with the effect of each on read and write latency

Locality is defined per table — and, in the case of REGIONAL BY ROW, row by row.

  • REGIONAL BY ROW — each row has a home region. The Brazilian customer writes in São Paulo, the customer in another region writes there, in the same table, with the same SQL query. This is the feature that solves the multi-tenant case without manual sharding in the application.
  • REGIONAL BY TABLE — the whole table has a home region. Fast writes in that region, reads from anywhere.
  • GLOBAL — fast reads in every region, more expensive writes. Ideal for reference tables: catalogues, pricing, settings.
  • Follower reads — slightly stale reads served by the local replica, without crossing the WAN. Excellent for reports and lookup screens.

When it fits — and when it does not

Scenario Recommendation
Multi-tenant SaaS with customers in different regions CockroachDB, REGIONAL BY ROW
Active writes in two regions, without electing a primary CockroachDB
Regional downtime is unacceptable, even for minutes CockroachDB, SURVIVE REGION FAILURE
Read-heavy application, concentrated writes Multi-Region PostgreSQL — simpler and cheaper
Many PostgreSQL extensions, procedures and specific SQL PostgreSQL — compatibility is with the protocol, not the whole ecosystem
Analytical workload, aggregations over billions of rows ClickHouse
Small database and a single region PostgreSQL High Availability

Compatible is not identical

CockroachDB speaks the PostgreSQL protocol and covers most application SQL, but it is not PostgreSQL: extensions, stored procedures, triggers and some transactional behaviours differ. Every migration starts with a compatibility inventory and a test with the real workload, before any decision.

Operating it at InteSys

  • Distribution across br-sp-1, br-sp-2 and a third failure domain, with localities declared so the database knows where each node is and places replicas correctly.
  • On Kubernetes or virtual machines — the cluster is homogeneous, every node runs the same role, which makes operations predictable either way.
  • Upgrades and maintenance without downtime, node by node, with quorum always preserved.
  • Backup to object storage, with tested restores — quorum protects against infrastructure failure, not against human error.
  • Observability — latency per region, range distribution, hot ranges, quorum health and transaction contention.
  • Assisted migration from PostgreSQL, with a compatibility inventory, a test workload and a cutover plan.

Data sovereignty

In a distributed database, "where the data is" is a configuration, not a consequence — and that is what makes multi-region writes compatible with data residency in Brazil.

  • Three failure domains inside Brazil — when sovereignty is a requirement, the third domain is Brazilian too. The cluster survives the loss of an entire region without a single replica leaving the country.
  • REGIONAL BY ROW pins data to its home region — the Brazilian customer's row is written and kept in Brazil, even in a cluster serving other regions. It is the mechanism that lets you operate abroad without blurring data residency.
  • A failure domain in another country is an explicit decision — it improves survivability and creates a cross-border transfer of data; the legal basis belongs in the solution design, not after it.
  • Backups and snapshots with a chosen destination — backup to object storage in Brazil by default and, on Kubernetes, encrypted volume snapshots that can stay in the country or be replicated abroad on request. See PostgreSQL High Availability.
  • LGPD — in the default, fully Brazilian topology there is no cross-border transfer to document.

How InteSys deploys it

  1. Requirement assessment — confirming the case genuinely needs multi-region writes; often a read replica solves it for a fraction of the cost.
  2. Compatibility inventory — mapping the SQL, extensions and transactional behaviours in use.
  3. Topology design — regions, third failure domain, node count and survival goal.
  4. Data locality — deciding which tables are REGIONAL BY ROW, REGIONAL BY TABLE or GLOBAL.
  5. Provisioning — cluster on Kubernetes or VMs, with correct localities and anti-affinity.
  6. Failure testing — we take an entire domain down in a controlled environment and measure the real impact on the application.
  7. Migration — initial load, synchronization and cutover in a short window.
  8. Observability and runbook — dashboards, alerts and a documented procedure.

The cheaper path usually comes first

Multi-region writes solve a real problem, but they are not the first step of every project. If your workload is read-dominated, start with Multi-Region PostgreSQL. If regional downtime is the central risk, CockroachDB is the direct answer. Talk to our team to evaluate which of the two fits your case.

Next Steps