Understanding the tradeoffs between these two approaches is essential for choosing the right system and for diagnosing problems when they occur.
| Feature | Spanner (TrueTime) | CockroachDB (HLC) |
|---|---|---|
| Source of Truth | GPS receivers + Atomic Clocks | NTP + Logical Counters |
| Uncertainty Window | Tiny (< 7ms, hardware-bounded) | Variable (~250–500ms, NTP-dependent) |
| Consistency Mechanism | Commit Wait: Pause writes until uncertainty passes | Causality Tracking: Advance clocks via message passing |
| Hardware Requirement | Google-owned data centers only | Any commodity hardware (cloud, on-prem, laptop) |
| Write Latency Floor | ~14ms minimum per write (2× uncertainty) | No fixed floor; uncertainty restarts add variable overhead |
| Failure Mode | None from clock skew (hardware prevents it) | Node self-terminates if clock drifts > max_offset |
| Uncertainty Restarts | Not needed (Commit Wait eliminates ambiguity) | Possible when writes fall in the uncertainty window |
| Operational Complexity | Managed by Google (Cloud Spanner) | Operator must monitor NTP health on all nodes |
When Does Each Approach Win?
Choose Spanner/TrueTime when:
- You need the absolute lowest possible write latency floor (14ms is predictable and bounded)
- You are already in the Google Cloud ecosystem
- You cannot tolerate uncertainty restarts under any circumstances
Choose CockroachDB/HLC when:
- You need to run on commodity hardware or multiple cloud providers
- You can accept occasional uncertainty restarts (they are transparent to the application)
- You need an open-source, self-hostable solution
- Your NTP infrastructure is well-maintained and monitored
The Deeper Lesson
Both approaches are solving the same fundamental problem — you cannot have external consistency without some mechanism to bound clock uncertainty. TrueTime bounds it with hardware. HLC bounds it with a combination of logical clocks and a configurable safety threshold. Neither approach is universally superior; they represent different points on the cost/complexity/portability tradeoff curve.