CockroachDB vs TiDB vs Spanner: Choosing a NewSQL Database for Global Scale

CockroachDB: Distributed PostgreSQL for the Multi-Cloud World

CockroachDB was designed as an open-source implementation of the ideas in the Spanner paper, built for engineers who want Spanner-like capabilities without being locked into Google Cloud.

How It Works

CockroachDB is built on a strongly consistent key-value store with a PostgreSQL-compatible SQL layer on top. It uses the Raft consensus protocol (rather than Paxos) for replication and automatic sharding.

Data is divided into ranges, and each range is replicated across multiple nodes using Raft.

CockroachDB provides serializable isolation by default, the strongest isolation level. It uses a hybrid logical clock (HLC) system for timestamp ordering, which does not have the same precision as Spanner's TrueTime but achieves strong consistency through a combination of clock synchronization and commit-wait mechanisms.

One of CockroachDB's key innovations is geo-partitioning.

You can pin specific rows or tables to specific regions, ensuring that data stays close to the users who access it most. This reduces cross-region latency for reads and writes while maintaining global transaction capabilities.

Strengths

• PostgreSQL compatibility: CockroachDB supports the PostgreSQL wire protocol, which means most PostgreSQL drivers, ORMs, and tools work with minimal changes. Migration from PostgreSQL is significantly easier than migration to Spanner.
• Multi-cloud and on-premises: CockroachDB runs on AWS, GCP, Azure, or your own hardware. You are not locked into any single cloud provider. CockroachDB Cloud offers a managed service, but you can also self-host.
• Open source core: The core database is open source (BSL license), which gives you the ability to inspect the code, run it locally, and avoid vendor dependency.
• Mature geo-partitioning: CockroachDB has the most mature tooling for controlling where data lives geographically. This is critical for data residency compliance (like GDPR) and for minimizing latency in multi-region deployments.
• Operational simplicity: Among the self-hosted options, CockroachDB requires the least operational overhead. Adding nodes, rebalancing data, and handling failover are mostly automatic.

Weaknesses

• Write latency: CockroachDB's default serializable isolation adds latency to write operations because of the consensus round-trips. For write-heavy workloads, this can be noticeable compared to databases with weaker isolation levels.
• No HTAP support: CockroachDB is designed for OLTP (transactional) workloads. If you need to run analytical queries on the same data, you will need a separate analytics system.
• Licensing complexity: While the core is open source, some enterprise features require a commercial license. The BSL license has restrictions on offering CockroachDB as a service.

When to Choose CockroachDB

Choose CockroachDB when you need distributed SQL with PostgreSQL compatibility, multi-cloud or multi-region deployment is important, you want strong consistency without Google Cloud lock-in, and your workload is primarily OLTP.

For understanding how sharding and partitioning decisions affect database architecture at this level, The Complete Guide to Database Sharding for System Design Interviews [2026 Edition] covers the foundational concepts.

TiDB: The HTAP Powerhouse for MySQL Teams

TiDB (pronounced "T-I-D-B") was created by PingCAP and takes a different architectural approach than both Spanner and CockroachDB. Its biggest differentiator: it is designed to handle both transactional and analytical workloads on the same database.

How It Works

TiDB has a modular architecture with three separate components that can be scaled independently:

1. TiDB Server is the stateless SQL layer. It parses SQL, optimizes queries, and generates execution plans. Because it is stateless, you can add or remove TiDB servers without affecting the data layer.
2. TiKV is the distributed key-value storage engine. It stores the actual data, handles replication via the Raft protocol, and provides transactional support. TiKV is an independent project in the Cloud Native Computing Foundation (CNCF).
3. TiFlash is the columnar storage engine for analytical queries. It maintains a real-time replica of the data in TiKV but stores it in a columnar format optimized for aggregations, scans, and analytical queries. This is what enables HTAP.

TiDB uses MySQL wire protocol compatibility, meaning most MySQL drivers, ORMs, and tools work out of the box.

If you are running a sharded MySQL setup today, TiDB is designed to be the database you migrate to.

Strengths

• HTAP capability: This is TiDB's killer feature. You can run complex analytical queries on the same data you are writing transactions to, without setting up a separate data warehouse or ETL pipeline. TiFlash handles the analytical queries while TiKV handles the transactions, and they stay in sync automatically.
• MySQL compatibility: TiDB supports MySQL syntax and the MySQL wire protocol. For the large number of applications built on MySQL, TiDB offers a smoother migration path than either Spanner or CockroachDB.
• Component-level scaling: Because TiDB, TiKV, and TiFlash are separate components, you can scale each independently. Need more query processing power? Add TiDB servers. Need more storage? Add TiKV nodes. Need more analytical capacity? Add TiFlash replicas.
• Write throughput: TiDB uses optimistic concurrency control by default, which can deliver higher write throughput than CockroachDB's pessimistic approach in workloads with low contention.
• Open source: TiDB is fully open source under the Apache 2.0 license, which is more permissive than CockroachDB's BSL license.

Weaknesses

• Operational complexity: TiDB's modular architecture means you are managing three separate component types. The learning curve is steeper than CockroachDB, and you need to understand how each component scales and fails independently.
• Less mature geo-distribution: While TiDB supports multi-region deployments, the tooling and automation are less mature than CockroachDB's geo-partitioning. Setting up a truly global TiDB deployment requires more manual configuration.
• Optimistic concurrency trade-offs: TiDB's default optimistic concurrency control means transactions can fail and require retries under high write contention. For workloads with frequent conflicting writes (like auction systems or inventory counters), this can lead to higher abort rates than CockroachDB's pessimistic approach.
• Not PostgreSQL compatible: If your application is built on PostgreSQL, TiDB is not a natural fit. CockroachDB or YugabyteDB would be better options.

When to Choose TiDB

Choose TiDB when you need both transactional and analytical queries on the same data (HTAP), you are migrating from a sharded MySQL setup, component-level scaling flexibility is important, and your workload has relatively low write contention.

The Decision Framework

Choosing between these three databases comes down to four questions:

What is your SQL compatibility requirement?

If your application uses PostgreSQL, CockroachDB is the natural fit. If it uses MySQL, TiDB is the natural fit. If you are starting fresh or willing to adapt, Spanner offers the strongest consistency but requires learning its dialect.

Do you need HTAP?

If you need real-time analytics on transactional data without a separate data warehouse, TiDB is the only option among these three that supports it natively.

What is your cloud strategy?

If you are committed to Google Cloud, Spanner is the easiest choice. If you need multi-cloud or on-premises flexibility, CockroachDB offers the best support. TiDB Cloud is available on AWS and GCP but is less mature than CockroachDB Cloud.

What is your operational capacity?

If you want zero operational overhead, choose Spanner (managed) or CockroachDB Cloud (managed). If you have a strong infrastructure team and want maximum control, self-hosted TiDB or CockroachDB gives you that flexibility.

What About Performance?

Performance varies significantly by workload type, and vendor benchmarks are unreliable because each company optimizes for their own tests. Here are the general patterns based on independent comparisons.

For read-heavy OLTP, all three perform well. CockroachDB and Spanner have an edge because of their strongly consistent read paths. TiDB performs comparably but with slightly different latency characteristics due to its optimistic concurrency model.

For write-heavy OLTP, TiDB generally achieves higher throughput (around 40K TPS in benchmarks) compared to CockroachDB (around 35K TPS). This is because TiDB's optimistic concurrency control avoids some of the locking overhead. However, if your writes have high contention (many transactions updating the same rows), CockroachDB's pessimistic approach avoids the retry storms that optimistic control can cause.

For analytical queries, TiDB wins decisively. TiFlash's columnar storage is purpose-built for aggregations and scans. Running the same analytical query on CockroachDB or Spanner would be significantly slower because they store data in row format optimized for transactional access.

For multi-region latency, Spanner has an inherent advantage because of TrueTime's precision. CockroachDB's hybrid logical clocks add a small commit-wait period to ensure consistency, which adds a few milliseconds to cross-region writes. TiDB's multi-region support is functional but requires more manual tuning to optimize latency.

The key takeaway: benchmark with your actual workload.

Measure sustained transactions per second at P95 and P99 latency, not averages. Test cross-node transaction throughput under write contention, and if HTAP matters, run complex aggregations concurrently with peak OLTP load to verify neither workload degrades the other.

For a broader perspective on how to evaluate database trade-offs across all types, not just NewSQL, the System Design Interview resource covers database selection frameworks that apply to any system design problem.

For a broader comparison of database types and when to use each, ACID vs. BASE: The System Design Interview Guide to Database Consistency covers the foundational concepts that inform these decisions.

And if you are still building your core database knowledge, the System Design Fundamentals course covers database selection as part of a comprehensive introduction.

How This Shows Up in System Design Interviews

NewSQL databases are increasingly relevant in system design interviews, especially for senior and staff-level roles. Here is how to use this knowledge effectively.

When the question involves global scale with strong consistency, mention Spanner or CockroachDB as your database choice and explain why. "We need ACID transactions across regions for our payment system, so I would use CockroachDB for PostgreSQL compatibility and multi-cloud flexibility. The serializable isolation guarantees that two concurrent payments cannot overdraft the same account."

When the question involves both transactions and analytics, mention TiDB.

"The business needs real-time dashboards alongside transactional workloads. TiDB's HTAP architecture lets us run analytical queries on TiFlash while TiKV handles the write path, without building a separate data warehouse."

When the interviewer challenges your choice, discuss the trade-offs. "Yes, CockroachDB adds write latency because of the consensus round-trips. For our use case, the latency is acceptable because payment correctness is more important than payment speed. If we needed sub-10ms writes, I would consider a single-region PostgreSQL with read replicas instead."

Knowing when to use a NewSQL database, and when not to, is a strong signal in interviews.

Most candidates default to either PostgreSQL or DynamoDB for every question.

Being able to articulate when a distributed SQL database is the right tool, and which specific one, shows genuine depth.

For structured practice on database selection in interviews, the Grokking the System Design Interview course includes problems that require exactly this kind of reasoning.

And for a quick refresher before an interview, the System Design Interview Crash Course covers database trade-offs in a condensed format.

If you want a comprehensive set of practice problems and mock interviews covering database decisions and other system design topics, the System Design Interview resource page brings together everything you need in one place.

Conclusion: Key Takeaways

• NewSQL databases solve a real problem. They give you horizontal scalability with ACID transactions and strong consistency. But they add complexity, cost, and operational overhead. Use them only when you genuinely need what they offer.

• Spanner is the gold standard for consistency. TrueTime gives it the strongest consistency guarantees of any distributed database. But it is expensive and locked to Google Cloud.

• CockroachDB is the most versatile. PostgreSQL compatibility, multi-cloud support, and mature geo-partitioning make it the best general-purpose choice for distributed OLTP. The trade-off is higher write latency from serializable isolation.

• TiDB is the HTAP champion. If you need transactions and analytics on the same data without a separate warehouse, TiDB is the only option. Its modular architecture offers fine-grained scaling but requires more operational expertise.

• Your SQL dialect matters. PostgreSQL teams should look at CockroachDB. MySQL teams should look at TiDB. Teams starting fresh or committed to Google Cloud should consider Spanner.

• Most systems do not need NewSQL. A well-configured PostgreSQL or MySQL instance with read replicas handles more traffic than most people think. Do not reach for a distributed SQL database because it sounds impressive. Reach for it only when you have genuinely outgrown single-region relational databases or need global distribution with strong consistency. Premature adoption of NewSQL adds operational complexity that a team of two or three engineers is not equipped to handle.