CockroachDB: Multi-Region, Backups & Changefeeds

Multi-Region & Geo-Partitioning

-- Declare survivability goal at database creation --
-- ZONE tolerates losing an availability zone; REGION tolerates
-- losing a whole region (needs replicas across >=3 regions,
-- more cross-region replication overhead in exchange).
ALTER DATABASE myapp SURVIVE REGION FAILURE;

ALTER DATABASE myapp ADD REGION 'us-east1';
ALTER DATABASE myapp ADD REGION 'eu-west1';

-- REGIONAL BY ROW: each row's "home region" determines where its
-- data (and leaseholder) actually lives -- low-latency local
-- reads/writes for users in that region
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT UNIQUE,
  region crdb_internal_region NOT NULL DEFAULT default_to_database_primary_region(gateway_region())
) LOCALITY REGIONAL BY ROW;

-- GLOBAL tables: optimized for fast reads everywhere, at the cost
-- of slightly higher write latency -- good fit for rarely-changing,
-- globally-read reference data (e.g. a product catalog)
CREATE TABLE product_catalog (id UUID PRIMARY KEY, name TEXT) LOCALITY GLOBAL;

Backup & Restore

-- Native, distributed backup as a SQL statement -- runs as a
-- background job across the cluster, no downtime required
BACKUP DATABASE myapp INTO 's3://my-backups/myapp'
  WITH revision_history;

-- Incremental backup, chained to the previous full backup
BACKUP DATABASE myapp INTO LATEST IN 's3://my-backups/myapp';

RESTORE DATABASE myapp FROM LATEST IN 's3://my-backups/myapp';

-- Point-in-time restore, using revision history
RESTORE DATABASE myapp FROM LATEST IN 's3://my-backups/myapp'
  AS OF SYSTEM TIME '2026-09-01 00:00:00';

Changefeeds (CDC)

-- Stream row-level changes to an external sink -- keeps a search
-- index, cache, or downstream service in sync without polling
CREATE CHANGEFEED FOR TABLE orders
  INTO 'kafka://broker:9092?topic_name=orders-cdc'
  WITH updated, resolved;

-- Webhook sink example
CREATE CHANGEFEED FOR TABLE orders
  INTO 'webhook-https://my-service.example.com/cdc'
  WITH updated;

Operations & Monitoring

• The built-in DB Console shows node health, range distribution/replication status, and slow-query/hotspot diagnostics.

• Write latency is generally higher than a single-node Postgres instance, since a write must reach quorum across replicas -- the cost of built-in replication and fault tolerance.

• Horizontal scaling (adding nodes) grows both read and write capacity, versus vertical scaling's ceiling on a single machine.

• Compared to hand-sharding Postgres, CockroachDB natively handles range splitting, rebalancing, cross-shard transactions, and failover -- avoiding significant custom engineering effort.