CockroachDB vs PostgreSQL

Quick verdict

CockroachDB, from Cockroach Labs, is a distributed SQL database. Its documentation explains that it converts SQL into key-value data, divides the keyspace into ranges, and replicates each range, by default to at least three nodes, using the Raft consensus protocol, so that a write is committed when a quorum of replicas acknowledge it. Data is rebalanced across nodes automatically. It supports version 3.0 of the PostgreSQL wire protocol and reports itself as PostgreSQL version 18 to clients, so PostgreSQL drivers and many tools can connect. Current releases are v26.3, an optional Innovation release (19 August 2026), and v26.2, a Regular release with a longer support window.

PostgreSQL is an open source object-relational database server. One primary server accepts writes; standby servers can be added with streaming (physical) or logical replication, and failover is handled by external tools or a managed service. It uses multiversion concurrency control (MVCC), defaults to the Read Committed isolation level, and is extended through a large ecosystem of extensions. It is released under the PostgreSQL License. postgresql.org lists 18.6 as the current release; PostgreSQL 19 is in beta, and PostgreSQL 14 reaches end of life on 12 November 2026.

Side by side

Key differences

Distributed by design versus a single primary

In CockroachDB every node can accept SQL, and data is spread over the cluster in ranges that split as they grow. Each range is replicated, three times by default, and Raft consensus means a write commits once a majority of its replicas agree, so the cluster keeps serving reads and writes when a minority of replicas are offline. Adding nodes adds capacity, and CockroachDB redistributes data without manual sharding.

PostgreSQL has one primary that accepts writes. You scale it by giving it more CPU, memory and faster storage, add read replicas for read traffic, and use streaming replication with a failover tool (or a managed service) for high availability. That model is simpler to reason about and fits the large majority of applications. In our view, CockroachDB's design is worth its added complexity mainly when write volume outgrows one large server, or when surviving a zone or region outage without manual failover is a hard requirement.

PostgreSQL compatibility: what is different

CockroachDB uses PostgreSQL's wire protocol and much of its dialect, and supports PL/pgSQL in user-defined functions, stored procedures and DO blocks, as well as triggers (row-level only; statement-level and INSTEAD OF triggers are not supported). Its compatibility page lists unsupported PostgreSQL features, including range types, events, dropping a primary key (every table must have one), XML functions, column-level privileges, XA syntax, creating a database from a template, dropping a single partition, foreign data wrappers and session-scoped advisory locks. Extensions are a fixed list rather than an ecosystem: its SQL feature support page lists CREATE EXTENSION for fuzzystrmatch and uuid-ossp as supported, postgis, pg_trgm, pgcrypto and vector (pgvector-compatible functions) as partially supported, and btree_gin, btree_gist, postgres_fdw, citext and pg_stat_statements as unsupported.

Some behaviour differs even where syntax matches:

-- Integer division
SELECT 7 / 2;     -- CockroachDB: 3.5 (DECIMAL)   PostgreSQL: 3
SELECT 7 // 2;    -- CockroachDB floor division: 3

-- INT size
CREATE TABLE t (n INT);   -- CockroachDB: INT is 64-bit (INT8)   PostgreSQL: INT is 32-bit

Auto-incrementing keys behave differently too. By default, CockroachDB turns SERIAL into an INT8 column with DEFAULT unique_rowid(), built from a timestamp and node ID, so values have gaps and are not strictly sequential. The documentation recommends UUID keys for new applications, because they spread writes across ranges:

-- CockroachDB: recommended primary key
CREATE TABLE orders (
    id    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    total DECIMAL(10,2) NOT NULL
);

-- PostgreSQL: identity column
CREATE TABLE orders (
    id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    total NUMERIC(10,2) NOT NULL
);

Before migrating, test your schema, queries and ORM against CockroachDB rather than assuming compatibility.

SERIALIZABLE by default, and transaction retries

CockroachDB runs every transaction at SERIALIZABLE, the strongest ANSI isolation level, unless you change it. READ COMMITTED is also available once the cluster setting sql.txn.read_committed_isolation.enabled is true. Under SERIALIZABLE, conflicting transactions can fail with error code 40001 ("restart transaction"), and the documentation says clients must include logic to retry them; it notes that client-side retry handling is not necessary for READ COMMITTED transactions.

PostgreSQL defaults to READ COMMITTED. Applications that opt into PostgreSQL's Serializable level also need to retry on serialization failures (also 40001), but many PostgreSQL applications never meet the issue because they stay at the default. Moving such an application to CockroachDB at its default level means adding retry logic or enabling Read Committed.

Multi-region features

CockroachDB has multi-region abstractions in SQL. You give a database a primary region and further regions, choose a survival goal (ZONE, or REGION, which needs at least three regions), and choose a locality per table: REGIONAL BY TABLE keeps a table in one home region, REGIONAL BY ROW places each row according to a crdb_region column, and GLOBAL replicates to all regions for low-latency reads. Super regions restrict where regional data is stored, which is relevant for data domiciling.

-- CockroachDB
ALTER DATABASE shop PRIMARY REGION 'us-east1';
ALTER DATABASE shop ADD REGION 'europe-west1';
ALTER DATABASE shop ADD REGION 'asia-northeast1';
ALTER DATABASE shop SURVIVE REGION FAILURE;
ALTER TABLE customers SET LOCALITY REGIONAL BY ROW;

PostgreSQL has no equivalent inside the engine. Teams build multi-region PostgreSQL with cross-region replicas, logical replication or a managed service's cross-region features, and typically keep a single writable primary.

Licensing: the 2024 change

CockroachDB used to have a free Core edition. Cockroach Labs removed the Core licence starting with v24.3.0 (and for patch releases of 23.1 to 24.2 from that date). CockroachDB is now distributed under the CockroachDB Software License, with three licence types documented in its licensing FAQ:

• Enterprise: paid, all features.
• Enterprise Free: the same functionality, free of charge for businesses with less than USD 10M in annual revenue; it requires sending telemetry.
• Enterprise Trial: a 30-day self-service trial, which also requires telemetry.

A new cluster with no licence key has a 7-day grace period. After that, or when a licence expires (Enterprise Free clusters are throttled 30 days after expiry, Trial clusters 7 days after), the cluster is throttled to 5 concurrent open SQL transactions; Free and Trial clusters are also throttled after 7 days without sending telemetry. No licence key is needed for developers running single-node clusters.

PostgreSQL, by contrast, is under the PostgreSQL License, which permits use, modification and distribution for any purpose with no revenue limits or telemetry. We describe licence terms only; take your own legal advice for your situation.

Pricing and licensing

CockroachDB self-hosted: Enterprise Free costs nothing for businesses under USD 10M annual revenue (with telemetry); larger businesses need a paid Enterprise licence, priced through Cockroach Labs' sales team.

CockroachDB Cloud: Cockroach Labs introduced a new pricing model, Cockroach Continuum, for Cloud organisations created on or after 15 September 2026. It has two plans: Standard (shared infrastructure, AWS and GCP, single- or multi-region, 99.99% availability SLA) and Mission Critical (dedicated infrastructure, AWS, GCP and Azure, 99.999% availability SLA). Listed on the vendor's pricing page in October 2026, Standard compute is USD 0.092 per vCPU-hour in AWS us-east-1, with storage and data transfer billed separately and rates varying by region. There is no free tier; new organisations get a 30-day trial with USD 400 of credit, and no credit card is needed to try Standard. Existing customers stay on their current plans (the documentation still describes Basic, Standard and Advanced) unless they opt in.

PostgreSQL is free under the PostgreSQL License. Managed PostgreSQL is priced by each provider, typically by instance or compute hours plus storage; see Neon vs AWS RDS and Supabase vs Neon for examples.

Prices exclude tax and change often; check the pricing pages before budgeting.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want serverless PostgreSQL with branching rather than a distributed database: see Supabase vs Neon and Neon vs AWS RDS.
• Your workload is mainly analytical rather than transactional: see DuckDB vs PostgreSQL and ClickHouse vs PostgreSQL.
• You are choosing between mainstream relational servers: see MySQL vs PostgreSQL and SQL Server vs PostgreSQL.
• You need high write throughput on AWS with managed regional failover: compare AWS options in Amazon RDS vs Amazon Aurora.

Final recommendation

Frequently asked questions

Sources

• CockroachDB: Architecture overview
• CockroachDB: PostgreSQL compatibility
• CockroachDB: SQL feature support (including PostgreSQL extensions)
• CockroachDB: Transactions and isolation levels
• CockroachDB: Multi-region overview
• CockroachDB: SERIAL
• CockroachDB: Triggers
• CockroachDB: Licensing FAQs
• CockroachDB: Releases
• CockroachDB Cloud pricing
• PostgreSQL home page (current releases)
• PostgreSQL: Transaction isolation
• PostgreSQL License

Checked October 2026.

How we research comparisons: our editorial method.