CockroachDB vs Google Spanner

CockroachDB and Spanner employ a similar distributed architecture; however, with CockroachDB you are free to deploy wherever and however you like.

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

Globally distributed relational system; absolute consistency via TrueTime (atomic clocks + GPS); proprietary GCP infrastructure dependency

GCP USERS RUNNING CLOUD-NATIVE APPS. GCP-commited enterprises

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

Splits rebalanced automatically; less operator-visible; online but less configurable

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

Geo-partitioning available; requires careful interleaved schema design; less intuitive DDL

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

Historically locked to Google Cloud. Now available (Preview version, April 2026) as Spanner Omni, a managed GCP service, or self-managed for on-prem or other clouds; less mature and operationally flexible

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

Spanner Change Streams available; no native SQL-based stream transformation; typically requires Dataflow or Pub/Sub for downstream delivery

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

ZERO under Serializable isolation. all standard SQL anomalies prevented by default. Repeatable Read (snapshot) also available

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

Hardened data integrity via Paxos replication and two-phase commits. Guarantees absolute correctness across global nodes. Enforced and informational foreign keys

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

MODERATE TO HIGH. Requires intentional schema hierarchical design (interleaving tables) to ensure localized performance and avoid hotspotting

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

COMPLEX & RIGID. Lacks native, row-level data pinning out-of-the-box. To satisfy strict regional data-sovereignty laws, organizations must split data into separate, complex database instances or manually manage it. Geo-partitioning for data residency; supported but at less granular levels

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.

GCP Console UI, gcloud CLI tools, emulator for local testing, and tight integration with Google Cloud Code and Vertex

Requires learning custom schema concepts (e.g., table interleaving) and specific Google SQL dialects or custom APIs

FAST BUT RESTRICTIVE. If already fully committed to GCP, it can be a single-click deployment; if operating across multiple clouds or on-premise, introducing Spanner adds heavy infrastructure, architecture, and procurement friction. Once running in the cloud; administrative maintenance is low with Google handling the underlying hardware patching, backups, and sharding; uncertain with Spanner Omni

Distributed ACID Transactions

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

Fully supported; requires two-phase commit with TrueTime timestamps

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

Tiered Google Cloud premium support; specialized Spanner support requires a GCP enterprise-level organization agreement

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

LOW. Highly-complext, multi-layered a la carte billing combines processing nodes, storage tiers (SSD vs HDD), and highly variable cross-region network egress fees. Harder for finance teams to forecast

Follower Reads

SUPPORTED. Supports follower/replica reads with Bounded (controlled) Staleness, allowing low‑latency local reads from nearby replicas while keeping strong global ordering

Stale/snapshot reads available; less granular control

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

HIGH VENDOR LOCK-IN. Architecture tied to GCP's TrueTime hardware by design; Spanner Omni offers limited off-GCP deployment but is a newer, more constrained offering

Joins

Executes fully distributed hash, merge, 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

Efficiently executes distributed joins, which are optimized when using parental table interleaving

LDAP Support

NATIVE. Direct native support for external authentication systems like LDAP, Active Directory, GSSAPI, and OIDC

Indirect. Does not connect to LDAP natively; authentication must be mapped through Google Cloud IAM, single sign-on (SSO), or Workforce Identity

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

Spanner Migration Tool; Cassandra interface; library of MySQL functions for compatibility; more re-engineering typically required

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.

YES-PARTIALLY. All nodes can serve traffic; Paxos leader still coordinates writes

Multi-Data-Center Support

FULL. 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)

Historically GCP regions only. Now supports multi-environment topologies via Spanner Omni, which allows self-managed local instances

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

Single-region, dual-region, or multi-region configurations available; less granular, more complex to configure

Leader-dependent; every write must pass through the Paxos group's designated primary read-write leader zone, introducing network latency

Replication

Built-in, automatic consensus replication using the Raft protocol; data is divided into ranges and replicated across nodes

Built-in, managed consensus replication driven by the Paxos protocol across zone/regional boundaries

Required Downtime

ZERO. Online schema changes, rolling upgrades, and cluster expansion occur without taking the data platform offline

Near zero: Managed by Google with automated maintenance

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

Five 9s availability; massive scale (17+ exabytes, 6B+ queries/sec at peak); Google-managed resilience

Scale

Virtually unlimited horizontal scale-out. Automatic, seamless handling of growing datasets; increase storage and throughput capacity linearly simply by adding more nodes

Virtually unlimited horizontal scale; seamless handling of growing datasets; tied to GCP compute capacity

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

Online & Managed. Changes run asynchronously in the background via schema update DDL operations without application downtime

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

GCP-native security: IAM integration, CMEK (Customer Managed Encryption Keys), VPC Service Controls, and Access Approval.

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

GoogleSQL and PostgreSQL dialects; not full PostgreSQL compatibility; gaps in spatial data, extensions, triggers, and stored procedures

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

Built on an internal, proprietary storage subsystem optimized by Google to interact directly with Colossus (Google's global file system)

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

Only built-in system stored procedures; users cannot create custom stored procedures

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

Enforces Serializable isolation by default, offering linearizable consistency guarantees

Distributed transactions globally optimized by Google's dedicated internal networking and TrueTime clock synchronization

Triggers & Deferrable Constraints

FULLY SUPPORTED. Supports triggers and deferrable constraints across all deployment models

No trigger support; workloads that rely on triggers require rework to run on Spanner

Vector Search

BUILT-IN NATIVE SUPPORT via VECTOR data type, 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

KNN and ANN (ScaNN-based); Vertex AI integration; restricted to Enterprise and Enterprise Plus editions

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

Handled at the network layer by Google's internal Cloud Load Balancing, routing requests to the nearest healthy replica zone

PRICING

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

Node/processing-unit pricing from; premium for multi-region; standardized GCP pricing model with less negotiation flexibility

Download the comparison

Databases and platform freedom

CockroachDB is architected to give you the freedom to deploy your database anywhere and on any cloud. You can use the best solution and still gain value from any cloud provider

Freedom from Lock-In

Make smart use of your existing resources with CockroachDB’s hybrid-cloud capabilities. AWS Aurora won’t let you deploy in a hybrid environment

Freedom of Choice

Pick any (or multiple) providers and run self-deployed or as-a-service. Because no one should have to be locked into a single provider

Freedom to Grow

Effortlessly scale and take control of your workloads. Avoid the significant egress costs often seen when moving data with AWS Aurora

^{Comparison data as of June 2026}

Databases and platform freedom

CockroachDB is architected to give you the freedom to deploy your database anywhere: Any private or public cloud, across multiple clouds, using our innovative [Bring Your Own Cloud (BYOC)](https://www.cockroachlabs.com/product/cloud/bring-your-own-cloud/) offering, on premises, self-hosted, or in a hybrid deployment encompassing some or all of these. Use the best solution for your workloads without cloud provider or deployment model lock-in.

Freedom from lock-in

Make smart use of your existing resources with CockroachDB’s hybrid-cloud capabilities. AWS Aurora won’t let you deploy in a hybrid environment

Freedom of choice

Pick any (or multiple) providers and run self-deployed or as-a-service. Because no one should have to be locked into a single provider

Freedom to grow

Effortlessly scale and take control of your workloads. Avoid the significant egress costs often seen when moving data with AWS Aurora

Architected to deliver the resilience modern business demands

CockroachDB vs Google Cloud Spanner

1. Deployment flexibility & global availability

How Google Cloud Spanner supports deployment environments

With Spanner you are tied to only the explicit GCP compute instances they offer (and this is somewhat limited). You cannot deploy a Spanner instance in a hybrid or multi-cloud configuration and are tied to the GCP environment only.

Google Cloud Spanner limitations for global availability

Spanner instances have only limited availability in Central and South America.

2. Multi-region & geo-partitioning control

How Google Cloud Spanner handles multi-region deployments

With Spanner, deployment of a multi-region application incurs a wholly new pricing structure, requires significant operations overhead and has no granular control for data residency.

How Google Cloud Spanner handles geo-partitioning

Multi-region for Spanner means the entire database lives in each region and you cannot control down to the row level for explicit survival/latency/compliance goals for particular (row-based) data.

3. Single control plane for k8s

How Google Cloud Spanner handles Kubernetes deployments

If you are deploying an app on any K8s (including GKE and Anthos) you cannot deploy Spanner in these environments. You can only use it as a service from these deployments. This increases complexity and operational overhead.

4. Spatial Data Types

Google Cloud Spanner limitations for spatial data support

Spanner does not offer support for spatial data types.

5. Distributed SQL architecture

How Google Cloud Spanner influenced distributed SQL architecture

Google Cloud Spanner is a pioneer of the distributed SQL movement and helped inspire much of the core architecture of CockroachDB. Key differences in approach exist, however, particularly with respect to technical decisions for a SQL API and the way time is managed within a cluster.

6. Scalability and workload distribution

How CockroachDB and Google Cloud Spanner handle scalability and workload distribution

Database Horizontal Scale
Increase storage and transactional capacity by adding more instances/nodes

Google Cloud Spanner — Node based, automated for both reads and writes

CockroachDB — Node based, automated for both reads and writes

Database Load Balancing (internal)
Locate data across multiple instances/nodes based on optimization criteria for balancing load

Google Cloud Spanner — Detailed options to optimize for storage, compute and latency efficiency

CockroachDB — Detailed options to optimize for storage, compute and latency efficiency

7. Availability and recovery

How CockroachDB and Google Cloud Spanner handle availability and recovery

Failover
Provide access to backup data upon failure

Google Cloud Spanner — Fully automated for both reads and writes

CockroachDB — Fully automated for both reads and writes

Automated Repair and RTO
Repair the database after failure and the time it takes for the database to come back online

Google Cloud Spanner — Automated Repair, RTO <10 sec

CockroachDB — Automated Repair, RTO <10 sec

8. Distributed operations and consistency

How CockroachDB and Google Cloud Spanner handle distributed transactions and consistency

Distributed Reads
Reliably read data in any instance/node of the database

Google Cloud Spanner — Yes

CockroachDB — Yes

Distributed Transactions
Allow for ACID writes across multiple instances/nodes

Google Cloud Spanner — Yes

CockroachDB — Yes, and extensions for parallel commits

Database Isolation Levels
Transaction isolation levels allowed for writes in the database

Google Cloud Spanner — Guaranteed Consistent; Default: Serializable; Highest: Serializable

CockroachDB — Guaranteed Consistent; Default: Serializable; Highest: Serializable

Potential data issues (default)
Possible data issues at default isolation level

Google Cloud Spanner — None

CockroachDB — None

9. SQL compatibility and schema operations

How CockroachDB and Google Cloud Spanner handle SQL compatibility and schema management

SQL
Compliance with standard SQL

Google Cloud Spanner — Yes, with some limitations

CockroachDB — Yes, wire compatible with PostgreSQL

Database Schema Changes
Modify database schema across all tables

Google Cloud Spanner — Online, Active, Dynamic

CockroachDB — Online, Active, Dynamic

Cost Based Optimization
Optimize query execution using analytics

Google Cloud Spanner — Yes

CockroachDB — Yes

Upgrade Method
Upgrade the database software

Google Cloud Spanner — Online, Rolling

CockroachDB — Online, Rolling

10. Geo-partitioning, multi-region, and deployment flexibility

How CockroachDB and Google Cloud Spanner handle geo-partitioning and deployment flexibility

Data Geo-partitioning
Tie data to an instance/node to comply with regulations or optimize access latency

Google Cloud Spanner — No

CockroachDB — Yes, Row level

Multi-region
Deploy a single database across multiple regions

Google Cloud Spanner — Yes, but not for writes

CockroachDB — Yes for both reads and writes

Hybrid and Multi-cloud
Deploy a single database across multiple cloud providers or on-prem

Google Cloud Spanner — No

CockroachDB — Yes

Related resources

BLOG

Learn more about migrating to CockroachDB

WEBINAR

How Shipt built a distributed payment system on CockroachDB

WEBINAR

CockroachDB and Spanner employ a similar distributed architecture; however, with CockroachDB you are free to deploy wherever and however you like.

Databases and platform freedom

Freedom from Lock-In

Freedom of Choice

Freedom to Grow

Databases and platform freedom

Freedom from lock-in

Freedom of choice

Freedom to grow

Architected to deliver the resilience modern business demands

CockroachDB vs Google Cloud Spanner

1. Deployment flexibility & global availability

2. Multi-region & geo-partitioning control

3. Single control plane for k8s

4. Spatial Data Types

5. Distributed SQL architecture

6. Scalability and workload distribution

7. Availability and recovery

8. Distributed operations and consistency

9. SQL compatibility and schema operations

10. Geo-partitioning, multi-region, and deployment flexibility

Related resources

Learn more about migrating to CockroachDB

How Shipt built a distributed payment system on CockroachDB

Introduction to Distributed SQL

Introduction to Distributed SQL 