CockroachDB vs Spanner in 2026: The Dev-Productivity vs Ops-Cost Trade

CockroachDB and Spanner have been the two answers to “I want global SQL with serializable consistency” for almost a decade. Spanner came first as Google internal infrastructure and lit the path. CockroachDB built the open-source Raft-based answer that anyone could deploy. The technical comparison was always close. The 2024 CockroachDB license change to BSL — and the operational realities of each — have made the trade-off much sharper in 2026.

The thirty-second framing#

Both databases give you horizontal scale, strong consistency across regions, automatic sharding, and ACID transactions. Both implement serializable isolation as the default. Both survive entire-region failures with the right topology. After that, they diverge.

• Spanner is Google Cloud only, fully managed, priced by node-hour plus storage plus egress. Truly serverless via Spanner Granular Instance Sizing. The “you do not operate the database” answer.
• CockroachDB is Go, open-source-ish (BSL since 2024), runs anywhere, and ships in three flavors — Core (BSL), Enterprise (paid features), and CockroachDB Cloud (Serverless, Standard, Advanced/Dedicated). You can operate it yourself or have Cockroach Labs operate it for you.

The hardware abstraction is the headline difference. Spanner uses TrueTime — atomic clocks and GPS in Google data centers — to give bounded time uncertainty. CockroachDB uses HLC (hybrid logical clocks) and pessimistic locking to achieve the same serializable result without special hardware. Both work. The implementation cost shows up in P99 write latency.

Internals worth knowing#

Both shard data into ranges and replicate via Paxos (Spanner) or Raft (CockroachDB). Range size is similar — Spanner around 1 GB splits, CockroachDB around 512 MB. Both rebalance ranges automatically across nodes.

The transaction protocols are where they differ:

• Spanner uses TrueTime to assign commit timestamps. The TT.now() interval gives you a window of clock uncertainty (single-digit milliseconds). Read-write transactions wait out this window before committing, which is where Spanner’s commit latency floor comes from. The win: external consistency (linearizability) globally, with no coordination on reads of recent snapshots.
• CockroachDB uses HLC with a small max clock offset (default 500 ms) and falls back to pessimistic locking for contended writes. No special hardware. The cost: read-write transactions on contended keys can block, and clock skew above the configured threshold causes node fencing.

For most workloads, both feel like SQL with multi-region replication. The differences show under contention and at the tail.

Performance characteristics#

On apples-to-apples regional workloads:

• Single-region point reads: both in single-digit milliseconds. Roughly tied.
• Single-region point writes: Spanner ~5 to 8 ms baseline (TrueTime wait floor), CockroachDB ~3 to 6 ms baseline. CockroachDB has a slight edge here.
• Cross-region writes (3 regions, quorum-replicated): both bottleneck on round-trip latency between regions. Spanner ~50 to 100 ms depending on geography, CockroachDB similar. Network physics wins.
• Read-after-write across regions: Spanner can serve via the closest replica with bounded staleness, fast. CockroachDB with follower reads is similar.

Where they diverge sharply: extreme write contention on hot rows. Spanner queues these elegantly; CockroachDB’s pessimistic locking can produce visible tail-latency spikes that take real work to tune.

The license change and what it actually means#

In late 2024, Cockroach Labs moved core CockroachDB from Apache 2.0 to the Business Source License (BSL 1.1) with a four-year clock to Apache. Practical implications:

• You can still run CockroachDB free. Most companies and individuals can use it in production without paying.
• You cannot offer CockroachDB as a competing managed service. This was the actual target — clouds reselling Cockroach.
• Some features (multi-region in particular) moved to Enterprise tier and require a license for production use beyond the free quota.

For most enterprise users this changed nothing in practice. For platform companies considering CockroachDB as the back-end of a multi-tenant SaaS, the conversation got more interesting. The market response was muted — similar to MongoDB SSPL and Elastic SSPL — but the trust signal mattered. Some teams used the license change as the reason to evaluate alternatives (YugabyteDB, TiDB, plain Postgres with Citus).

Ops realities#

CockroachDB Cloud Dedicated/Advanced is what we deploy when teams want CockroachDB without operating it. It is good. Multi-region, monitoring, backups, upgrades, all handled. Pricing is per-vCPU-hour plus storage plus IO, which is comparable to Spanner at small to mid scale and meaningfully cheaper at large scale.

Spanner is Google’s managed service. You provision processing units (the new finer-grained sizing), Google handles the rest. The ops surface is genuinely close to zero. The price is the largest in this category at scale — Spanner gets expensive fast above a few hundred nodes.

Self-hosted CockroachDB is real but not light. We have run it on Kubernetes with the official operator. The hard parts: capacity planning across regions, hot-range remediation, replica placement tuning, and the recurring “why did this read get blocked” debugging sessions.

When each one wins#

Pick Spanner when:

• You are already on Google Cloud and the integration story matters (IAM, Dataflow, Vertex AI).
• You need true zero-ops and you can pay for it.
• You have variable workloads and the Granular Instance Sizing serverless model fits — pay only for the processing units you use.
• You want the strongest correctness guarantees (external consistency) and the cleanest abstractions.

Pick CockroachDB when:

• Multi-cloud or on-prem matters. Spanner runs only on GCP.
• You want PostgreSQL wire compatibility — Spanner has GoogleSQL plus a Postgres dialect, but Cockroach is more drop-in for existing Postgres apps.
• Cost at scale matters. CockroachDB is meaningfully cheaper above ~50 nodes equivalent.
• You want the option of self-hosting later. Easier to migrate Cockroach Cloud to self-hosted than to leave Spanner.
• The BSL license is acceptable for your use case.

Pick neither when: your workload is single-region OLTP with no real scale needs. Plain Postgres on RDS or AlloyDB is dramatically cheaper, simpler, and faster for the vast majority of applications. The “we might go global someday” rationale is one of the most expensive architecture decisions teams make.

The dev-productivity vs ops-cost trade#

This is the real choice in 2026. Spanner gives you developer productivity through fully-managed-ness — your engineers never think about ranges, replicas, or upgrades. The ops cost is paid to Google in dollars. CockroachDB Cloud is most of the way there, with a meaningfully lower bill and slightly more visible ops shape.

Self-hosted Cockroach trades dollars for engineering time. We have seen both work; we have also seen teams burn 18 months of platform-team capacity on Cockroach operations when Spanner would have shipped the same product six months earlier.

The honest heuristic: if your team has fewer than three people who could comfortably operate a Raft-based distributed database, do not self-host. Use CockroachDB Cloud or Spanner.

Where pdpspectra fits#

We have shipped CockroachDB Cloud for a regional banking platform that needed multi-region active-active for regulatory data locality, and Spanner for a Google Cloud-native SaaS that wanted zero-ops global SQL. Both were the right call for those teams.

If you are deciding between them, our data engineering team will benchmark both against your real query shapes, run the cost math with current pricing, and recommend the one we would deploy. We do not have a preferred vendor — we have a preferred way of making the call.

Related reading#

• CAP theorem and distributed databases in 2026
• TiDB distributed SQL in 2026
• PostgreSQL failover and replica deep dive

Global SQL is a real product category now. Picking inside it is mostly about your team shape and your cloud posture. Tell us about the workload and we will help you choose.