What CockroachDB Teaches Us About the Coherence Budget
Published on: February 24, 2026
Before we talk about any specific database, we need to establish the physics.
When a complex system requires n sequential coordination steps to synthesize a truth - and each step carries a physical error rate epsilon (cache misses, network partitions, version skew, clock drift) - the coherence of the final result follows a geometric decay:
Phi = (1 - epsilon)^n
This is the Coherence Budget. It is not a metaphor. It is the inescapable probability mathematics of compounding error across physical boundaries.
If epsilon = 0.003 (99.7% reliability per step - elite engineering), the math is unforgiving. At n = 50 steps, (0.997)^50 = 0.86, meaning 14% degradation. At n = 83 steps, (0.997)^83 = 0.78, meaning 22% degradation. At n = 100 steps, (0.997)^100 = 0.74, meaning 26% degradation.
Two variables. Two strategies. You can minimize epsilon (make each step more reliable). Or you can minimize n (reduce the number of steps). Most distributed systems focus exclusively on the first strategy.
As I explain in Chapter 1, your brain chose the second strategy 500 million years ago. It burns 55% of its metabolic budget keeping semantically related concepts physically adjacent - not to minimize epsilon, but to eliminate n entirely.
CockroachDB uses the Raft consensus protocol to ensure data is safely stored across multiple machines. This is excellent engineering for distributed reliability.
Here is what Raft requires: Every write needs consensus.
In steady-state, Raft achieves agreement with a single network round-trip to each replica, requiring a majority to respond positively. CockroachDB optimizes this further with "pipelined consensus writes" that overlap network calls.
But the physics remains: n is greater than or equal to 1 for every single write.
You cannot write to CockroachDB without at least one consensus round. That round crosses physical network boundaries. Each boundary crossing has epsilon greater than 0.
CockroachDB's MultiRaft system optimizes by managing all of a node's ranges as a group - nodes only exchange heartbeats once per tick regardless of how many ranges they share. This is brilliant engineering to minimize epsilon per coordination.
But n remains at least 1. For every write. Always.
Here is where the physics becomes concrete.
Google Spanner uses TrueTime - GPS receivers and atomic clocks in every data center. This achieves clock uncertainty of approximately 7 milliseconds in 99.9% of measurements. Spanner can use "commit-wait" to handle uncertainty because 7ms is short enough to wait.
CockroachDB uses NTP-synchronized clocks. This achieves clock uncertainty of approximately 100-250 milliseconds. CockroachDB explicitly "refrains from commit-waits" because waiting 100-250ms per transaction would be unacceptable.
Instead, CockroachDB "dynamically adjusts transaction timestamps upward when conflicts occur within the uncertainty window."
What does this mean for the Coherence Budget?
CockroachDB's epsilon for time-sensitive operations is measurably higher than Spanner's. Not theoretically. Measurably. The uncertainty window is 14-35x larger.
This is not a criticism of CockroachDB. They made a reasonable trade-off: work without specialized hardware (atomic clocks) and accept higher epsilon in exchange for accessibility. But the trade-off is real. epsilon is not zero. epsilon is measurable. And epsilon compounds.
CockroachDB stores data in "ranges" - contiguous chunks of key-value data replicated across nodes. As your data grows, ranges split.
Here is what their own documentation states:
"Reducing the number of ranges a transaction touches minimizes Raft coordination overhead."
Read that again. They are telling you that n matters.
When a transaction touches multiple ranges, the coordination compounds. Each range has its own Raft group. Each Raft group requires its own consensus round. Cross-range transactions multiply n.
A simple transaction touching one range: n = 1. A complex transaction touching five ranges: n = 5. An analytical query scanning hundreds of ranges: n scales accordingly.
As your data grows, n grows. This is not a bug. This is the architecture. CockroachDB is honest about it - they provide configuration options to tune range sizes and minimize cross-range transactions.
But the physics is clear: scale increases n.
CockroachDB excels at multi-region deployment. Their documentation is explicit about the physics:
"In a CockroachDB cluster spread across multiple geographic regions, the round-trip latency between regions will have a direct effect on your database's performance."
"Write latency will be increased by at least as much as the round-trip time to the nearest region."
They have optimized brilliantly. Geo-partitioning can reduce latency by up to 50% for region-specific queries. Proper leaseholder placement can reduce p99 transaction latency by over 50%.
Notice the language: reduce by 50%. Not eliminate. Reduce.
When you write to a multi-region CockroachDB cluster, the steps compound. First, local Raft consensus (n = 1). Second, cross-region replication (n = 2+). Third, if the transaction touches data in another region, n multiplies further.
Multi-region is multi-n. The geographic distribution that provides resilience also increases the coordination steps. Each step crosses a physical boundary. Each boundary has epsilon greater than 0.
Let me be absolutely clear: CockroachDB is excellent engineering.
They have attacked epsilon with everything available:
Pipelined consensus writes - Overlap network calls to reduce per-write latency. This minimizes the time cost of each consensus round without eliminating the round itself.
Hybrid Logical Clocks - Combine physical timestamps with logical ordering to handle clock uncertainty without atomic clocks. This manages epsilon within the constraints of commodity hardware.
MultiRaft optimization - Batch heartbeats across ranges to reduce coordination overhead. This minimizes epsilon per range without reducing the number of ranges.
Leaseholder placement - Put the decision-maker for each range close to where reads happen. This reduces latency for reads without eliminating the consensus requirement for writes.
Geo-partitioning - Keep region-specific data in that region. This reduces cross-region n without eliminating it for global operations.
Every single optimization is an attack on epsilon or a reduction of n within the constraints of their architecture.
This is what makes CockroachDB valuable: They have pushed the Codd architecture to its physical limits. They have shown exactly how far you can minimize epsilon while accepting n greater than 0.
Here is the question CockroachDB's architecture cannot answer:
What if n could equal zero?
CockroachDB's architecture assumes data will be distributed. That distribution requires coordination. That coordination requires consensus rounds. Those rounds are n.
They can make each round faster (reduce latency). They can make each round more reliable (reduce epsilon). They can reduce unnecessary rounds (minimize n).
But they cannot eliminate n. The architecture is built on the premise that related data is separated and must be coordinated.
This is the Codd inheritance. Edgar Codd's relational model (1970) separated data into normalized tables to eliminate redundancy. When you need to synthesize a truth from separated data, you JOIN. Every JOIN is coordination. Coordination across physical boundaries is n.
CockroachDB is Codd at scale. Codd distributed globally. Codd with Raft consensus and hybrid logical clocks and geo-partitioning.
But still Codd. S does not equal P. Semantic meaning is separated from physical position. And that separation costs n.
The question is not "Can CockroachDB reduce epsilon?" They have proven they can.
The question is "What architecture achieves n = 0?"
Because when n = 0:
Phi = (1 - epsilon)^0 = 1
The coherence budget becomes infinite. Trust Debt drops to zero. Verification becomes instant.
Your brain does not use Raft consensus.
When you think "coffee," your visual cortex (brown liquid), olfactory cortex (bitter aroma), motor cortex (grasping warm mug), and emotional centers (morning comfort) all activate within 10-20 milliseconds.
They can do this because they are physically adjacent.
Through Hebbian learning ("neurons that fire together, wire together"), your brain has reorganized itself so that semantically related concepts are spatially co-located. The meaning IS the position. S = P = H.
Your brain achieves n = 0 by making coordination unnecessary.
When semantic neighbors are physical neighbors, there is nothing to coordinate. No consensus rounds. No cross-region replication. No range splits. The address carries the semantics.
As I explain in Chapter 1: "If a JOIN were truly a simple, deterministic, zero-cost operation, the human brain would not need Hebbian learning. It would not burn one-fifth of all the energy in your body just to keep related ideas physically next to each other in the cortex."
But it does. Because n matters. Because (1 - epsilon)^n is unforgiving. Because the only way to escape geometric decay is to change the geometry.
We are not claiming CockroachDB is bad. We are not claiming Spanner is bad. These are remarkable engineering achievements that have pushed distributed systems to their physical limits.
We are asking a different question:
Is there an architecture where position equals meaning?
Where semantic neighbors are physical neighbors by construction?
Where n = 0 is not an optimization target but an architectural guarantee?
Where the Coherence Budget equation locks at Phi = 1?
The Fractal Identity Map (FIM) is our attempt to answer this question. It abandons Codd's normalization. It makes the address carry the semantics. It achieves zero-hop addressing by making position equal identity.
CockroachDB proves the Coherence Budget is real by showing how hard elite engineers must work to fight it. Their architecture is a monument to minimizing epsilon.
But as scale increases, n always wins.
Unless you change the architecture.
CockroachDB Architecture: See CockroachDB Replication Layer for official Raft consensus documentation. Life of a Distributed Transaction explains how transactions coordinate across nodes. Transaction Pipelining covers how pipelined consensus writes reduce latency. Multi-Region Overview details geographic distribution and its latency implications.
Clock Synchronization: Living Without Atomic Clocks is CockroachDB's own explanation of their clock strategy versus Spanner. 4 Architectural Differences Between Spanner and CockroachDB provides a direct comparison from CockroachDB. Use of Time in Distributed Databases offers academic analysis of clock synchronization approaches.
The Coherence Budget: Unity Principle (Chapter 1) contains the full derivation of Phi = (1 - epsilon)^n. The Razor's Edge (Chapter 0) explains why 0.3% is the empirical ceiling. We Killed Codd, Not God covers the database heresy that broke AI. The Ethics of Latency explains why Codd's normalization makes coordination expensive.
The Question Remains Open
CockroachDB answered: "How do we minimize epsilon in a distributed Codd architecture?" The answer is excellent. The engineering is world-class. But the question we are asking is different: "What architecture achieves n = 0?" That question requires abandoning the premise that related data should be separated. It requires making position equal meaning. It requires S = P = H.
๐งฎ A | ๐ B | โฑ๏ธ C | ๐ D | ๐ E | ๐ F | ๐ง G | ๐ง H | โ I | ๐ J
Elias Moosman is the founder of ThetaDriven and author of "Tesseract Physics: Fire Together, Ground Together." This essay examines what CockroachDB's architecture teaches us about the Coherence Budget - and the question it leaves unanswered. Connect on LinkedIn or reach out at elias@thetadriven.com.
Ready for your "Oh" moment?
Ready to accelerate your breakthrough? Send yourself an Un-Robocallโข โข Get transcript when logged in
Send Strategic Nudge (30 seconds)