Architecture / Ideal Workloads
Distributed SQL, shared-nothing, peer-to-peer architecture. All nodes symmetrical; any node can handle reads/writes. Cluster uses distributed consensus: No matter where data lives, every node can access data anywhere in cluster
SYSTEM OF RECORD. Optimized for transactional workloads that require strong consistency and global distribution, such as AI innovators, cybersecurity, eCommerce & retail, financial services, fintech/payments, gaming, quant/trading & research, and online travel
Single primary instance with optional streaming or logical replication to standbys. All roles (compute, storage, WAL) reside on one server; HA requires external tools such as Patroni or repmgr
OLTP + LIGHT ANALYTICS/REPORTING/BI supporting financial services, e‑Commerce and retail, B2B apps, public sector, and healthcare. Best suited to single-node transactional workloads with predictable data volumes. Not designed for global distribution, horizontal write scale, or multi-region active-active deployments
Auto-Sharding (Dynamic Re-Sharding Online)
NATIVE & AUTOMATIC. Automatically shards data into ranges and dynamically splits, merges, and rebalances online across nodes based on load and size. Zero downtime, fully transparent
NATIVE & MANUAL. Number of shards fixed at table creation; requires manual partitioning or third-party extensions to shard data across multiple nodes; no dynamic resharding without downtime. Native declarative table partitioning (range, list, hash) available for single-node partition management. Citus extension enables sharding across nodes but requires manual shard count definition; no dynamic resharding
Automatic Geo-Partitioning (Multi-Region Data Affinity)
NATIVE AND AUTOMATIC. Declarative SQL schema adjustments automatically route, partition, and anchor data close to the user's location, automatically moving data to the region where it is most frequently accessed. Supports geo-partitioning with zone configurations for data locality, compliance, and low latency
MANUAL. Declarative table partitioning can organize data by geography but does not automatically place partitions in specific regions. Requires setting up specific table partitions and manually routing application traffic to correct partition; no support for geo-partitioning or multi-region clusters. Application layer must route queries to the correct geographic partition; no multi-region cluster awareness
Availability including Multi-Cloud and Hybrid
Available on all public clouds, e.g., AWS-Google Cloud-Azure; can run a single logical cluster spanning multiple clouds. Can run on prem/local, and cloud + prem hybrid deployments
Single-region by default; multi-cloud and hybrid require manual networking, separate instances, and external replication tooling. No native multi-cloud cluster spanning
Change Data Capture (CDC)
NATIVE. CHANGEFEED command enables scalable, resilient streaming of data changes to Kafka, cloud storage, and webhooks; no third-party CDC tool needed. CDC Queries enable SQL-based filtering and transformation of streams
PARTIALLY NATIVE. Native support for Logical Decoding via WAL (Write-Ahead Log) decoding, but requires external connectors Debezium, pgoutput, and Kafka Connect connectors route changes to downstream targets. Native publication/subscription (pub/sub) model for table-level logical replication
Data Anomalies
ZERO under Serializable isolation: all standard SQL anomalies (dirty reads, non-repeatable reads, phantom reads, lost updates, and write skew) are prevented by default with no additional developer configuration. Read Committed is also available for workloads where some consistency relaxation is an acceptable tradeoff for reduced latency
Default isolation (Read Committed) allows non-repeatable reads and phantom reads. Serializable Snapshot Isolation (SSI) available but must be explicitly requested per transaction. Anomalies can occur unless the application explicitly sets the appropriate isolation level
Data Integrity & Foreign Keys Support
Provides strict ACID enforcement at the storage layer and full referential integrity. NATIVELY VALIDATES FOREIGN KEYS, explicit CHECKs, and transactional constraints to ensure absolute global correctness across global nodes
Full ACID enforcement on the primary node; foreign keys, CHECK constraints, triggers, and deferrable constraints are fully supported. Referential integrity is not enforced on async read replicas
Data Model Complexity
LOW. Relational model with strict schemas, normalized tables, joins, and referential integrity. Ideal for managing complex relationships and transactional systems of record; adapts easily to microservices and enterprise legacy systems
Relational model with strict schemas, normalized tables, joins, and referential integrity. Also supports JSONB for semi-structured data, arrays, and custom types. Full-featured RDBMS designed for complex data relationships on a single node or primary-replica setup
Data Residency
STRONG, INTUITIVE, AND LOCALITY-AWARE. Helps fulfill compliance (e.g., GDPR, CCPA) with Row-Level Control: can pin specific rows to specific geographic regions using REGIONAL BY ROW command, while preserving single logical data platform. Business and compliance teams can use simple SQL commands to ensure customer data never leaves specific geographic borders
LIMITED AND COMPLEX. Table and Instance-Level Control: Requires either separate database instances per region or complex manual partitioning. Declarative table partitioning can help organize data but does not enforce geographic placement natively
Developer Tools / Experience / Ease of Use
Rich ecosystem: Local CLI, web console UI, ORMS, BI tools, SQL clients, native DB migration toolkits, language‑specific drivers, and compatibility with standard PostgreSQL developer tools like psql
PostgreSQL wire protocol-compatible; feels exactly like developing on standard PostgreSQL. Fits effortlessly into existing ORMs, drivers, and frameworks
Can be spun up instantly in any environment (AWS, GCP, on-prem) with the exact same management interface. The cluster manages its own data balancing, scaling, and hardware survival automatically; DBAs do not need to be distributed systems experts to keep it running smoothly.
psql CLI, pgAdmin, DataGrip, and other GUI clients; pg_dump/pg_restore for backups; pgBadger for log analysis; Flyway and Liquibase for schema migrations. Wide compatibility with ORMs, BI tools, and CI/CD toolchains
The most widely adopted open source relational database; large ecosystem of drivers, ORMs, and tools. Connection pooling (e.g., PgBouncer) must be separately configured and managed. Extensive documentation and community resources
Single-node setup is well-documented and straightforward. High availability, failover, and connection pooling require assembling separate tools (Patroni, PgBouncer, HAProxy). DBAs must manually manage replication slots, vacuum tuning, and failover runbooks
Distributed ACID Transactions
YES. Fully distributed, multi-row, multi-table ACID transactions out-of-the-box. Fully supported with serializable isolation using distributed consensus (Raft Protocol) across tables, ranges, and regions; strong ACID guarantees
NO: NOT NATIVE. Requires Two-Phase Commit (2PC) orchestration or extensions, and even then supported only across partitions, not across nodes | 2PC supported for cross-database transactions via foreign data wrappers (FDW). Single-node ACID is complete; distributed ACID across independent PostgreSQL nodes requires third-party tooling (e.g., EDB BDR)
Enterprise Support
Dedicated 24/7/365 enterprise support directly from Cockroach Labs with strict SLAs and custom engineering channels. Offers global follow-the-sun support (TSE+SRE) with proven reliability and global partnerships with industry leaders. Single Global Incident Management integrates Engineering + Support + Customer Success in one channel for consistency/immediacy
No vendor-backed support from the PostgreSQL project. Commercial support available from third parties (EDB, Percona, Crunchy Data). SLAs and incident escalation paths vary by provider; no unified global support channel
FinOps Support
HIGH. Straightforward pricing based on predictable node usage or consumption metrics. Avoids hidden, fluctuating network traps when moving data across different infrastructure regions. Supports financial governance/FinOps
MODERATE TO HIGH. No licensing fees; primary costs are infrastructure, DBA labor, and third-party HA/monitoring tools. Managed cloud offerings (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL) add per-instance costs that can scale unpredictably with traffic and data volume
Follower Reads
SUPPORTED. Supports follower/replica reads with Bounded (controlled) Staleness, allowing low‑latency local reads from nearby replicas while keeping strong global ordering
PARTIALLY SUPPORTED. No built-in read routing or staleness control at the database level; replication lag can range from milliseconds to seconds. Reads from replicas are eventually consistent; staleness is undefined/variable depending on replication lag. Application or proxy must explicitly direct read queries to replica connection strings
FREEDOM
ZERO VENDOR LOCK-IN. Runs on any public or private cloud, across multiple clouds, via CockroachDB's Bring Your Own Cloud (BYOC) offering, on-premises, bare metal, Kubernetes, self-hosted, or in a hybrid deployment encompassing some or all of these. Business Source License (BSL) but Source Available. Full commercial-grade support directly from CockroachDB
ZERO VENDOR LOCK-IN. PostgreSQL License allows use, modification, and redistribution—but users must rely on non-guaranteed voluntary support from open source community. HA tooling, monitoring, and enterprise management must be assembled by the user or a third-party provider
Joins
Executes fully distributed hash joins, merge joins, and lookup joins across arbitrary nodes with CockroachDB's advanced Cost-based Optimizer. Full standard SQL support for complex INNER, OUTER, LEFT, RIGHT joins across distributed tables
Full SQL join support: INNER, OUTER, LEFT, RIGHT, CROSS, and LATERAL joins. Hash join, merge join, and nested loop join algorithms selected by the cost-based optimizer. All join processing confined to the single primary node
LDAP Support
NATIVE. Direct native support for external authentication systems like LDAP, Active Directory, GSSAPI, and OIDC
Supported natively via pg_hba.conf; supports LDAP, GSSAPI, SSPI, RADIUS, and certificate-based authentication. Configuration is file-based; changes to pg_hba.conf require a reload to take effect
Migrations
Uses MOLT (Migration Off Legacy Technology) Toolkit & change data capture (CDC): MOLT handles schema conversion/verification and CDC moves data out. PostgreSQL wire protocol compatibility enables lift-and-shift; shadow mode testing
Logical Replication: Native logical replication and tool support: pg_dump/pg_restore for schema and data export; pg_upgrade for major version upgrades; pgloader, Flyway, and Liquibase for schema migrations. Major version upgrades may require downtime or a logical replication-based cutover
Multi-Active
YES: FULLY MULTI-ACTIVE/MULTI-REGION; read/write and handle connection requests from any node in the cluster. All nodes are equal and active; any node can accept read and write traffic simultaneously.
NO. Single-writer architecture by default; writes must go to single Primary node. Bidirectional replication via third-party tools (EDB BDR, pglogical) available with manual conflict resolution required; not native to core PostgreSQL
Multi-Data-Center Support
YES. Connects geographically isolated, heterogeneous data centers (AWS, GCP, Azure, on-prem) into a single logical cluster, supported by features such as Physical Cluster Replication (PCR) and Logical Data Replication (LDR)
NO. Streaming replication can replicate data to a standby in another data center, but the standby is passive (read-only). Active-active multi-data-center writes not supported natively; requires third-party tools such as EDB BDR or pglogical
Multi-region Functionality / Multi-region Writes
ACTIVE-ACTIVE: Read/Write from any node in any region; built-in low-latency local access patterns and Survival Goals (e.g., ALTER DATABASE...SURVIVE REGION FAILURE) commands configure fault tolerance intent
True multi‑region, multi‑active writes: any node in any region can serve reads and writes while preserving serializable consistency guarantees
ACTIVE-PASSIVE: No native multi-region awareness. Standby in another region must be promoted manually or via external tooling on failure. Managing region-specific data requires complex setup of cascading replicas, logic in the application layer, or extensions. Infrastructure-based: Survival determined by architecture (e.g., number of standby nodes provisioned). All writes route to the primary regardless of region
NOT SUPPORTED NATIVELY. All writes must route to the single primary node regardless of region. Bidirectional replication tools (e.g., EDB BDR, pglogical) exist but introduce conflict resolution complexity and are not part of core PostgreSQL
Replication
Built-in, automatic consensus replication using the Raft protocol; data is divided into ranges and replicated across nodes
Built-in streaming replication (physical, byte-for-byte copy) and logical replication (selective, table-level). Both are asynchronous by default; synchronous replication available but adds write commit latency. Cascading replication supported
Required Downtime
ZERO. Online schema changes, rolling upgrades, and cluster expansion occur without taking the data platform offline
MODERATE. Major version upgrades and some schema changes require maintenance windows or logical replication setups. Many DDL operations acquire table locks that block concurrent writes. CREATE INDEX CONCURRENTLY allows non-blocking index creation. Major version upgrades require pg_upgrade or a logical replication cutover with planned downtime
Resilience
Five 9s availability: Survives node/disk/rack/region failures automatically via Raft consensus, with zero data loss (RPO=0). Naturally resilient to outages with granular row-level control
Failover is manual; automatic failover requires external tools. Synchronization between primary and secondary can be complex. Async replication carries risk of data loss (RPO > 0) on primary failure. Synchronous replication available but impacts write latency
Scale
Virtually unlimited horizontal scale-out. Automatic, seamless handling of growing datasets; increase storage and throughput capacity linearly simply by adding more nodes
Vertical (Scale-up): Scales by increasing hardware resources (CPU/RAM) on the single primary node. When vertical scale is maxed out, must shift to horizontal scale, which means manual sharding via application-level logic or extensions such as Citus. Read scale via read replicas only; replicas are passive and asynchronously updated
Schema Changes
FULLY ONLINE & NON-BLOCKING. Online transactional schema changes (add/alter columns, indexes, constraints) run in the background without locking tables with zero downtime. Designed for always‑on services
Many DDL operations (e.g., adding NOT NULL constraints, full index rebuilds) acquire locks that block reads or writes. CREATE INDEX CONCURRENTLY allows non-blocking index creation. Some complex schema changes require maintenance windows or multi-step workarounds
Security-Privacy-Compliance
RBAC, Encryption at Rest with Customer Managed Encryption Keys (CMEK), TLS encryption in transit, IAM integrations, column-level encryption, and robust data-masking natively. Fine-grained encryption at cluster, database, table, or partition levels. Certified SOC 2 Type II and SOC 3, PCI-DSS, HIPAA, and ISO 27001-27017-27018 compliant, with ISO 42001 (Responsible, Ethical, and Safe AI Governance) pending. CockroachDB CIS Benchmarks to deploy hardened CockroachDB configurations. Comprehensive support for GDPR and DORA compliance
RBAC, TLS in transit, native LDAP, GSSAPI, and certificate authentication, row-level security (RLS), audit logging via pgaudit extension. Encryption at rest is OS- or cloud-provider-managed, not native at the database level. Compliance certifications depend on the managed service provider, not PostgreSQL itself
SQL Compatibility
HIGH. PostgreSQL Wire Compatible: Uses PG wire protocol; strong ANSI SQL with complex queries, joins, window functions, triggers, stored procedures, and UDFs. Supports spatial data, extensions, syntax; most apps connect with minimal or no changes
HIGH. Considered the most standards-compliant open source RDBMS. Extensive extensions ecosystem. Strong ANSI SQL support including joins, UDFs, stored procedures, and triggers. All SQL capability operates within a single-node or primary-replica architecture; no distributed SQL query optimizer
Storage Engine
Built on Pebble, a highly tuned, GO-based, LSM-tree key-value storage engine developed by Cockroach Labs and inspired by RocksDB specifically for distributed SQL
Heap storage (tuple-based) with Write-Ahead Logging (WAL). MVCC handles concurrent access; dead tuples from MVCC require periodic VACUUM/autovacuum maintenance. Pluggable Table Access Method (TAM) API (PostgreSQL 12+) allows alternative storage engines
Stored Procedures
SUPPORTED AND MATURE. PL/pgSQL and other languages such as Python and Perl support deep procedural logic, autonomous transactions, and complex business rule enforcement. Supports user-defined stored procedures
SUPPORTED AND MATURE. PL/pgSQL and other languages such as Python and Perl support deep logic capabilities | PL/pgSQL is native; also supports PL/Python, PL/Perl, PL/Tcl, and external language extensions. Autonomous transactions not natively supported; workarounds available via dblink
Transaction Performance / Isolation Levels
Optimized for OLTP with strong consistency; cross‑region transactions maintain data correctness. Optimizations like Parallel Commits drop distributed execution overhead to a single network round-trip for most transactions
Enforces strict Serializable isolation exclusively, the strongest isolation level, to ensure zero data anomalies under heavy parallel traffic, and Read Committed
Supports Read Committed (default), Repeatable Read, and Serializable isolation levels. Read Uncommitted accepted but maps to Read Committed. Serializable uses Serializable Snapshot Isolation (SSI)
High single-node OLTP throughput; low-latency for local transactions. Performance degrades at high connection counts without connection pooling (PgBouncer). No native multi-node write distribution; performance ceiling bound by single primary node capacity
Triggers & Deferrable Constraints
FULLY SUPPORTED. Supports triggers and deferrable constraints across all deployment models
FULLY SUPPORTED. Supports row-level and statement-level triggers; and BEFORE, AFTER, and INSTEAD OF trigger types. Deferrable constraints allow constraint checking to be deferred to the end of the transaction. No distributed trigger execution across nodes
Vector Search
BUILT-IN NATIVE VECTOR SEARCH, scalable distributed HNSW/IVF indexing, and pgvector (the industry standard for vector similarity search). CockroachDB's C-SPANN provides distributed vector indexing (ANN) at scale; available across all tiers. Suited for AI/ML inference and RAG applications where vectors and transactional data coexist in one engine without a separate vector database
BUILT-IN NATIVE VECTOR SEARCH supported via pgvector extension. IVFFlat and HNSW indexing for approximate nearest neighbor (ANN) search on a single node. No native distributed vector indexing across multiple nodes
Writes and Query Routing
Every node is a gateway to the entirety of the database for unlimited reads and writes in any region. Any node can accept SQL queries; a Distributed Optimizer routes work to the right ranges/replicas based on locality and cost
All writes must route to the single primary node. Read queries can be directed to replicas but routing must be configured by the application or an external proxy (PgBouncer, HAProxy, pgpool-II). No built-in intelligent query routing
PRICING
SIMPLE. Commercial Enterprise: Simple, straightforward pricing, plus the ability to tie data to a location to avoid egress costs. Free for single-node/dev. Free Community Tier
SIMPLE. No licensing fees; infrastructure and DBA labor are the primary cost drivers. Managed cloud offerings add per-instance costs that can scale with traffic and storage size
