Distributed Systems 10 Sep 2026 34 min read

When the answer is wrong, not late: ten years of CockroachDB read from its own record

How CockroachDB and the company that builds it changed between 2016 and 2026, reconstructed from 73 dated defect advisories, 187 dated design records and the release tags at which whole layers appear and disappear.

A decade of one distributed database company read from artefacts nobody edits for effect: technical advisories with affected version ranges, design records with a status field including the rejected ones, and dependency manifests fetched at eighteen release tags. It gives an architect a dated method for auditing any vendor, a failure taxonomy for mature stateful systems, and the specific technique this company used to catch the failures its monitoring could not see.

The finding that surprised me

The public design-record process was retired between the February and May 2024 releases and moved to an internal wiki, while a competing vendor's public design directory kept growing through August 2026.

What you get out of it

  • The failure surface moved: fourteen advisories about wrong query results appear between 2021 and 2023 and none after, while silent data-fidelity defects in backup, import and change feeds continue into 2026.
  • Nearly every correctness advisory sits at one seam: an optimisation that skips work meets a concurrent structural change, and the result is a success response covering an absence.
  • The layers taken in-house (storage engine at v20.1, admission control at v21.2, store liveness at v24.3) are the ones whose failure modes could not be observed or arbitrated from outside; C and C++ submodules fell from nine to four.
  • Runtime switches are abundant but rarely aligned to the failure you get: 387 documented cluster settings, yet 37 of 73 advisories offer no remedy other than upgrading every node.
  • The tool that matches the vanished wrong-answer class is a differential oracle, running each generated query again with optimiser rules disabled and comparing results, first present at the v21.2 and v22.2 tags.

Scope

Why this, now. Every architect is being asked to assess a stateful vendor whose availability story is already good, and the residual risk in those systems is correctness, which no status page reports.

What it does not cover. No engineering blogs, talks, papers, peer benchmarks or cost figures: the session's network policy reached code hosts only, so every source is a repository artefact, and the guide covers the product architecture rather than the CockroachDB Cloud service.

Open the field guide → Self-contained: it loads nothing at read time, follows your system theme, and prints cleanly.