When to Use Each System
Understanding the architectural differences between Spanner, CockroachDB, and TiDB helps you choose the right tool for a given situation. Here is a practical decision framework:
Choose Google Spanner when:
- You are already on Google Cloud and need a fully managed, zero-ops database.
- You need the strongest possible global consistency guarantees (external consistency).
- You have a global user base and need sub-10ms read latency across continents.
- Budget is not a primary constraint (Spanner is expensive).
Choose CockroachDB when:
- You need a self-hosted or multi-cloud NewSQL database.
- Your team is familiar with PostgreSQL and wants protocol compatibility.
- You need strong consistency (serializable isolation) with horizontal write scalability.
- You want fine-grained control over data placement for compliance (e.g., GDPR).
Choose TiDB when:
- You are migrating from MySQL and want minimal application changes.
- You need to serve both transactional and analytical queries from one system (HTAP).
- You want to scale compute and storage independently.
- You are operating in an environment where MySQL ecosystem tooling is important.
Common Trade-offs and Failure Modes
Write latency: All NewSQL databases incur higher write latency than a single-node RDBMS because writes must be replicated to a quorum before committing. Expect 5–50ms for local replication and 50–200ms for cross-region replication.
Operational complexity: Self-hosted CockroachDB and TiDB require expertise to operate. Cluster upgrades, region failures, and rebalancing events require careful management. Managed cloud offerings (CockroachDB Serverless, Google Spanner) trade cost for operational simplicity.
Hot spots: Range-based sharding can create hot spots if your access pattern is sequential (e.g., auto-incrementing integer primary keys). All writes go to the last range. The solution is to use UUIDs or hash-prefixed keys to distribute writes evenly — but this sacrifices range scan efficiency.
-- Anti-pattern: sequential keys create write hot spots
CREATE TABLE events (id SERIAL PRIMARY KEY, ...);
-- Better: UUID distributes writes across ranges
CREATE TABLE events (id UUID DEFAULT gen_random_uuid() PRIMARY KEY, ...);
Key Point: No NewSQL database is universally superior. The right choice depends on your cloud strategy, existing technology stack, consistency requirements, and operational capacity. The hot-spot problem with sequential keys is a subtle but critical operational concern that catches many teams off guard.