CockroachDB: distributed Postgres-compatible SQL for multi-region setups

What is CockroachDB?

CockroachDB is a distributed relational database, developed since 2015 by Cockroach Labs (headquartered in New York). Former Google engineers built the system inspired by Google Spanner, the internal database system for global consistency. CockroachDB uses the PostgreSQL wire protocol, so existing Postgres clients and ORMs (Prisma, TypeORM, SQLAlchemy, Django ORM) work without changes. In May 2026, version 24 is stable.

The key difference to classic Postgres: CockroachDB is designed as a distributed database from the ground up. Data is split into ranges, each range is replicated across 3-5 nodes (default 3), consensus runs via Raft. Write and read operations are ACID-compliant across multiple nodes. Automatic failover on node failure, automatic rebalancing when adding/removing nodes.

License history: CockroachDB was historically under Apache 2.0 (Community Edition) and Enterprise (proprietary). In August 2024, Cockroach Labs switched to a new license strategy: self-host for companies with > USD 10M revenue requires a license, smaller companies and hobby users stay free. From 2026 it is announced that self-host converts to Apache 2.0 after 3 years -- i.e. version 24 becomes fully OSS in August 2027. This builds trust for SMEs concerned about license lock-in.

Cockroach Cloud (cockroachlabs.cloud) offers three tiers: Serverless (from USD 0, scale-to-zero), Dedicated (USD 400+/month for dedicated clusters), Advanced (Enterprise). EU regions (Frankfurt, Dublin) available. Self-host runs as a container or Kubernetes operator -- requires at least 3 nodes for the default replication factor.

Why it matters

CockroachDB is rarely the right choice in the SME market in 2026 -- but when right, then very right. Three indicators.

First: real multi-region requirement. A Swiss group with sites in CH, DE, and USA that needs consistent database access at all sites under 100 ms latency. Postgres streaming replication is asynchronous (data lag of seconds to minutes), CockroachDB synchronous with Raft consensus. Whoever truly needs data consistency across continents has two realistic options: CockroachDB or Google Spanner.

Second: high availability as architectural duty. An application with SLA "no data loss even on datacenter outage" does not belong on a single-Postgres setup. CockroachDB with 3 nodes across 3 availability zones keeps data consistent even on complete zone outages. Auto-failover in seconds instead of minutes.

Third: Postgres compatibility as migration path. Whoever starts with Postgres and must switch to distributed load in 2-3 years can move to Cockroach with minimal application changes. Wire protocol and SQL syntax are largely compatible; some Postgres-specific features (e.g. some PL/pgSQL constructs, sequence behavior) need adjustment, but the schema is portable.

For typical Swiss SME fiduciary setups, Cockroach is overkill in 2026. A single office with 200 clients and one server in Falkenstein gets no added value from a distributed consensus layer -- only additional complexity. Anyone considering Cockroach should first check whether Postgres with good backup and possibly a hot standby does not suffice.

Important: the 2024 license change was a trust shock for some OSS users. The 2026 announcement of the 3-year Apache conversion has won some of that back -- but is not yet established in every release cycle. Anyone valuing license clarity above all waits for the first Apache 2.0 release in 2027.

How it works

CockroachDB runs as a symmetric cluster -- every node is equal, no primary, no slave. Data is split into ranges (64 MB per range default), each range is replicated to 3-5 nodes via Raft. A Raft leader per range coordinates writes; reads can be served by any replica (with follower reads for read scaling).

A three-node cluster is the minimum: with one node failure, the cluster stays available (2 of 3 nodes available = Raft majority). Production setups typically run with 3-9 nodes across multiple availability zones or regions. Cross-region latency on writes is in the range of RTT between nodes -- typically 30-100 ms in intra-EU setups.

A minimal production setup with Docker:

# Start three nodes (example for Hetzner cluster) docker run -d --name=cockroach-1 -p 26257:26257 -p 8080:8080 \ -v cockroach-data-1:/cockroach/cockroach-data \ cockroachdb/cockroach:v24.2.0 start \ --advertise-addr=cockroach-1 --join=cockroach-1,cockroach-2,cockroach-3 \ --insecure

# Schema in Postgres-compatible SQL CREATE DATABASE fiduciary; CREATE TABLE fiduciary.clients ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name STRING NOT NULL, region STRING NOT NULL, created_at TIMESTAMPTZ DEFAULT now() );

Multi-region tables: ALTER TABLE clients SET LOCALITY REGIONAL BY ROW AS region. This stores data rows in the region where the corresponding users are -- GDPR-compliant with data in EU region, low latency for EU customers.

Clients: all Postgres drivers work (pg, node-postgres, psycopg, JDBC). ORMs like Prisma, Drizzle, TypeORM support CockroachDB explicitly or via Postgres dialect. Specific Cockroach features (multi-region, time-travel queries via AS OF SYSTEM TIME) need explicit use.

Backup: BACKUP command writes to S3-compatible storage or GCS. PITR via incremental backups plus time-travel queries. Auto-configured in Cockroach Cloud; in self-host you must set up backup schedules yourself.

Monitoring: built-in web UI on port 8080 with cluster health, range distribution, query performance. Prometheus endpoint /metrics for Grafana integration. Slow-query log and statement diagnostics built-in.

CockroachDB to production in 5 steps

1. 01Decide cloud vs. self-host: with single-stack < USD 10M revenue and without cluster experience -> Cockroach Cloud Serverless. For truly distributed self-host requirements -> 3-node cluster across 3 availability zones.
2. 02Initialize cluster: start three nodes with common --join parameter, run cockroach init. For multi-region: set locality tags per node.
3. 03Design schema with Postgres wire protocol compatibility: UUID primary keys, TIMESTAMPTZ for times, REGIONAL BY ROW for multi-region tables.
4. 04Application binding: Prisma/Drizzle with Postgres connection string, retry logic for conflict errors (Cockroach raises SERIALIZATION_FAILURE on transaction conflicts -- app must retry).
5. 05Backup and monitoring: BACKUP schedule to S3 (daily full + hourly incremental), Prometheus scraper, Grafana dashboard with latency, QPS, Raft health.

When to use CockroachDB

The right choice when (a) real multi-region consistency is required, (b) high availability with RTO under 30 seconds is mandatory, or (c) horizontal scaling beyond Postgres vertical limits is needed.

Concrete scenarios: an international group with sites in CH, DE, USA, and SEA that needs consistent accounting data at all sites under 100 ms latency. A banking or insurance software with SLA "zero data loss" even on datacenter outage. A SaaS platform that quickly grows beyond Postgres vertical scaling limits (e.g. > 50k QPS write).

Cockroach Cloud Serverless is attractive for prototypes with global ambition: scale-to-zero, pay-per-use, EU regions available. Anyone needing a multi-region stack quickly without cluster-operations knowledge starts there.

Hybrid setups: Postgres main DB for single-region workload, CockroachDB for globally consistent subset (e.g. user profiles, session data across regions). That is a reasonable architecture for applications only partially global.

When not to use

For single-region Swiss SME applications, CockroachDB is overkill. An office in Zurich with 200 clients and one server in Falkenstein gets no added value from a distributed consensus layer -- only additional complexity, latency, and license topics.

For Postgres-specific features without multi-region need: some Postgres functions are unavailable or different in Cockroach (e.g. complex PL/pgSQL procedures, some extensions like PostGIS at full scope). Whoever explicitly uses these features stays on Postgres.

For pure OLAP workloads, Cockroach is not the right tool -- ClickHouse or DuckDB are faster for aggregates over millions of rows. Cockroach is OLTP-optimized.

For setups with < USD 10M revenue and 1-2 servers in one region: self-host free up to the threshold, but operationally heavier than Postgres. Postgres with standby replication suffices in 95 percent of SME cases and is significantly simpler.

For teams without cluster-operations experience: operating a CockroachDB cluster needs experience with distributed systems -- diagnosing node outages, rebalancing after node additions, backup-restore in multi-region scenarios. Anyone with 1-2 IT staff without this experience moves to Cockroach Cloud or stays on Postgres.

Trade-offs

FAQ

Related topics

Sources

1. CockroachDB v24 release notes · 2026-05
2. CockroachDB Licensing FAQ 2024-2026 · 2026-04
3. CockroachDB Multi-Region documentation · 2026-05
4. CockroachDB pricing and Cloud regions · 2026-05