Bigtable vs Cassandra: Similar Data Models, Different Operating Boundaries
Bigtable and Cassandra can model the same query-oriented wide rows, but only Cassandra makes storage-engine health, replica convergence, and software lifecycle part of your team’s production system.
Situation
Both databases reward schemas built around partition-local access. Bigtable sorts rows by row key and supports atomic operations within one row. Cassandra hashes the CQL partition key across a token ring and orders rows inside a partition by clustering columns. Both can serve entity histories, counters, and time-series workloads when keys distribute load.
The resemblance stops at the operating boundary. Bigtable exposes a managed cluster, row-key and column-family controls, application profiles, and service metrics. Cassandra exposes nodes, disks, commit logs, memtables, SSTables, compaction, repair, topology, and release upgrades. That control can be a requirement; it is never free.
The Problem
A migration or greenfield review often compares node counts or headline latency while holding correctness and labor implicit. That produces a false equivalence. The useful question is: does the organization need Cassandra’s deployment and topology control enough to own its background work, or does Bigtable’s managed boundary satisfy the application’s locality and consistency requirements?
Assume a representative workload rather than a universal benchmark: append-heavy device histories, 1 KB mutations, 30-day TTL, reads bounded to one device and time window, replication across two failure domains, and a documented tolerance for stale remote reads. Replace these assumptions with production traces before approval.
Storage and Failure Ownership
flowchart TD
A["Application mutation"] --> B{"Operating model"}
B -->|Managed service| C["Bigtable tablet and distributed storage"]
B -->|Self-managed database| D["Cassandra commit log and memtable"]
C --> E["Service rebalances tablets and storage"]
D --> F["Flush to immutable SSTables"]
F --> G["Compaction and repair consume capacity"]
E --> H["Team owns row-key and app-profile correctness"]
G --> I["Team owns convergence and storage health"]
Bigtable: Managed Infrastructure Does Not Mean Schema-Free
Bigtable rows are stored in lexicographic order. Exact keys, prefixes, and bounded ranges are efficient; arbitrary filters can require broad scans. A timestamp-first row key can produce a hotspot, so time-series designs normally put a distributing entity or bucket before time.
Bigtable automatically splits tablets and can autoscale nodes using CPU and storage targets. These controls address capacity, not a single hot range. Google’s prescribed design loop is to test the schema and inspect Key Visualizer plus hottest-node metrics.
With replication, clusters maintain independent copies and inter-cluster propagation is eventual. App profiles determine routing. Multi-cluster routing favors availability and locality, but Bigtable does not allow single-row transactions with that routing policy. Single-cluster routing to the same cluster can provide read-your-writes and can enable single-row transactions. An architecture document must name the app profile and the behavior expected during failover.
Cassandra: The Storage Engine Is Part of the Application SLO
Cassandra records a mutation in the commit log and memtable, then flushes immutable SSTables. Updates, deletes, and TTL expiry create new versions or tombstones rather than modifying data in place. Reads may consult multiple SSTables until compaction rewrites them. Compaction therefore consumes read, write, CPU, and temporary disk capacity while controlling read amplification and reclaiming obsolete data.
Cassandra 5.0 documents Unified Compaction Strategy as the recommended choice for most new workloads. It does not eliminate the need to observe pending compactions, SSTable counts, disk headroom, and latency. TWCS remains relevant for mostly immutable TTL time series; LCS targets read-heavy or update-heavy workloads; each should be load-tested with the actual deletion and retention pattern.
Replication also requires repair. Hinted handoff and read repair are best-effort convergence mechanisms; Cassandra’s anti-entropy repair is the mechanism documented to guarantee eventual convergence. A production design needs a repair cadence, alerting, failure-domain-aware scheduling, and evidence that repair completes inside the tombstone-safety window.
Consistency Is a Configuration, Not a Product Label
Bigtable provides atomic mutations within one row. In replicated instances, consistency depends on routing. Concurrent writes to the same cell identity in different clusters are resolved deterministically using server-side time, so multi-cluster write designs must accept or prevent last-writer-wins conflict resolution.
Cassandra chooses consistency per operation. With replication factor RF, acknowledged writes are visible to subsequent reads when the selected levels guarantee quorum intersection—commonly W + R > RF for the applicable replica set. LOCAL_QUORUM provides that intersection only within the local datacenter; it does not make a remote datacenter synchronously current. Lightweight transactions use Paxos for linearizable compare-and-set behavior, at a higher coordination cost. Cassandra also uses mutation timestamps for last-write-wins reconciliation; clock synchronization is a correctness dependency.
Do not label Bigtable “strong” or Cassandra “eventual” without the routing, replication, and operation details. State the invariant and demonstrate it during packet loss, replica unavailability, and coordinator retries.
In Practice
The documented pattern is that both products push data-model correctness to the application, while Cassandra adds storage lifecycle and convergence duties.
For the assumed TTL history workload, the engineering action is to prototype the same logical query in each system. In Bigtable, test a distributed entity-and-time row key and observe hotspots during the largest tenant burst. In Cassandra, test partition sizes, tombstone scans, compaction throughput, disk headroom, and repair duration across the full retention cycle—not only a short ingest benchmark.
The result should be a measured operating envelope. Bigtable is favored if the query is naturally a row-key range and managed Google Cloud operations are acceptable. Cassandra is favored only when deployment portability, infrastructure control, custom topology, or database-level tunable consistency justifies continuous specialist ownership. The learning is that “same data model” does not imply the same risk transfer.
Production Acceptance Tests
- Remove a failure domain while maintaining the declared consistency level.
- Drive the hottest real partition or row-key prefix, not uniformly random test keys.
- Run TTL expiration long enough to observe actual compaction and tombstone behavior.
- Measure P99 latency while Bigtable rebalances or Cassandra repairs and compacts.
- Restore into isolation, validate counts and checksums, then exercise application reads.
- Prove upgrades with mixed versions and a rollback boundary before production rollout.
Where It Breaks
| Choice | Failure mode | Gate before adoption |
|---|---|---|
| Bigtable | Required query is not a key, prefix, or bounded range | Scan-volume measurement or a maintained alternate representation |
| Bigtable | Multi-cluster routing is assumed to be immediately consistent | App-profile-specific staleness and failover test |
| Cassandra | Repair falls behind or has no owner | Repair completion SLO and overdue-repair paging |
| Cassandra | Compaction consumes disk and I/O headroom | Full-retention load test with failure reserve |
| Cassandra | Large or hot partitions dominate a node | Partition-size and key-frequency budgets with alerts |
| Either | TTL is treated as free deletion | Observe expiry, reclamation lag, and read impact |
What to Do Next
- Problem: Similar wide-column APIs obscure different failure ownership.
- Solution: Compare schema locality, consistency topology, and recurring operational work together.
- Proof: Test hotspots, expiry, failover, repair, rebalance, restore, and upgrades against an explicit SLO.
- Action: Select Cassandra only with funded operational ownership; select Bigtable only after proving row-key and routing correctness.