Evidence ledger
26 sources
Checked 06 Oct 2026
Evidence ledger
One row per claim in Correctness, then cost, then neighbours: ten years of TiDB, read from its own design record: who published it, what grade it carries, when it was written, when the link was last checked, and the quote or figure it rests on. Nothing in the guide is cited from memory, so anything not in this table is not in the guide.
Topic: which constraint binds a shared transactional database next, read from ten years of one company's own design record. The subject is PingCAP's TiDB, TiKV and PD, 2017 to 2026.
Network constraint for this session: outbound access reached code hosts only (github.com,
raw.githubusercontent.com). Every artefact below was read in this session, either from a clone
made here (pingcap/tidb docs tree, pingcap/docs release notes, tikv/rfcs in full) or by
fetching the file or issue page directly. The two papers were read from PDF mirrors in a public
GitHub repository and converted with pdftotext in this session. PingCAP's engineering blog,
docs.pingcap.com, conference recordings and every customer incident report were unreachable and
are therefore absent, not overlooked. There are consequently no blog, talk or casestudy
rows, and the failure rows are severity-critical bug reports rather than customer postmortems.
Release-note files are cited at their GitHub path because docs.pingcap.com was unreachable; the file is the source the published page is built from.
All links checked 2026-10-06. One row per claim. Quotes are copied, not paraphrased.
| # | Org | Title | Tier | Published | Checked | URL | Claim taken from it | Supporting quote or figure |
|---|---|---|---|---|---|---|---|---|
| 1 | PingCAP | tidb README | source | master, retrieved 2026-10-06 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/README.md | The product's own statement of what it guarantees | "an open-source, cloud-native, distributed SQL database designed for high availability, horizontal and vertical scalability, strong consistency, and high performance" |
| 2 | PingCAP / CNCF | tikv README | source | master, retrieved 2026-10-06 | 2026-10-06 | https://github.com/tikv/tikv/blob/master/README.md | The lineage claimed for the transaction and replication model, and the stated scale | "The design of TiKV ('Ti' stands for titanium) is inspired by some great distributed systems from Google, such as BigTable, Spanner, and Percolator"; "can easily scale to 100+ TBs of data"; "The transaction model is similar to Google's Percolator with some performance improvements"; "Similar to Google's Spanner, TiKV supports externally-consistent distributed transactions"; "TiKV is a graduated project of the [Cloud Native Computing Foundation]" |
| 3 | PingCAP | TiDB 1.0 release notes | vendor | 2017-10-16 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-1.0-ga.md | Where the decade starts: the first GA is about compatibility and the optimiser | "On October 16, 2017, TiDB 1.0 is now released! This release is focused on MySQL compatibility, SQL optimization, stability, and performance." |
| 4 | PingCAP | TiDB 3.0 GA release notes | vendor | 2019-06-28 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-3.0-ga.md | Pessimistic locking arrives as an experiment, two years after GA | "Support the pessimistic transaction mode (Experimental)"; "Release date: June 28, 2019" |
| 5 | PingCAP | TiDB 3.0.8 release notes | vendor | 2019-12-31 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-3.0.8.md | The compatibility capitulation: the default transaction mode changes | "Update the default value of the tidb_txn_mode variable from \"\" to \"pessimistic\" when a new cluster is created" |
| 6 | PingCAP | TiDB 5.0 release notes | vendor | 2021-04-07 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-5.0.0.md | Measured gains from async commit and clustered index, and the MPP claim | "the average latency decreases by 41.7% from 12.04ms to 7.01ms"; "in the TPC-C tpmC test, TiDB's performance, with clustered index enabled, improves by 39%"; "TiDB 5.0 MPP shows 2 to 3 times of speedup over Greenplum 6.15.0 and Apache Spark 3.1.1" |
| 7 | PingCAP | TiDB 6.0.0-DMR release notes | vendor | 2022-04-07 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-6.0.0-dmr.md | In-memory pessimistic locks ship with lock loss as an accepted outcome | "pessimistic transactions store pessimistic locks in TiKV memory as much as possible, instead of writing pessimistic locks to disks or replicating to other replicas ... however, there is a low probability that a pessimistic lock will be lost"; "reduce latency by 10% and increase QPS by 10%" |
| 8 | PingCAP | TiDB 6.1.0 release notes | vendor | 2022-06-13 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-6.1.0.md | Raft Engine becomes the default log store, with its measured effect | "Raft Engine can reduce TiKV I/O write traffic by up to 40% and CPU usage by 10%, while improving foreground throughput by about 5% and reducing tail latency by 20% under certain loads" |
| 9 | PingCAP | TiDB 6.6.0 release notes | vendor | 2023-02-20 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-6.6.0.md | The partitioned Raft KV engine is introduced, experimental, with a PB-scale promise | "each Region uses an independent RocksDB instance, which can easily expand the storage capacity of the cluster from TB to PB and provide more stable write latency and stronger scalability" |
| 10 | PingCAP | TiDB 7.4.0 release notes | vendor | 2023-10-12 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-7.4.0.md | The last release note that mentions the new engine, still before GA | "TiDB Lightning now supports the new Partitioned Raft KV architecture, as part of the near-term GA of the architecture" |
| 11 | PingCAP | TiDB 7.1.0 release notes | vendor | 2023-05-31 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-7.1.0.md | Resource control reaches GA and is framed as the foundation of multi-tenancy | "Resource Control becomes generally available (GA)"; "This feature significantly enhances the stability of multi-application clusters and lays the foundation for multi-tenancy"; "you can combine multiple small and medium-sized applications from different systems into a single TiDB cluster" |
| 12 | PingCAP | TiKV RFC 0023: Hibernate Region | adr | undated, merged RFC | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0023-hibernate-raft.md | Why idle regions became a CPU problem | "an idle cluster with many regions can waste a lot of CPU time to send useless heartbeats and tick for routine checks. In an online cluster with tens of thousands of regions, enlarging the interval between ticks can usually lead to better performance." |
| 13 | PingCAP | TiKV RFC 0082: Dynamic size region | adr | undated, tracking issue 11515 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0082-dynamic-size-region.md | The proposed change of scale unit, and why region count was the cost | "instead of 96MiB, we set the max region size to 10GiB (before compression)"; "This is the first step that we try to support PiB scale cluster"; "Hibernated region needs extra time to renew its lease, which lead to high tail latency" |
| 14 | PingCAP | TiKV RFC 0093: Physical isolation between Region | adr | undated, tracking issue 12842 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0093-rocksdb-per-region.md | One LSM tree per region, and the deletion of the local write-ahead log | "Make every region stores its own data in an isolated LSM tree"; "Every tablet writes its own WAL can bring random writes, so we better disable WAL"; "Now that WAL is disabled, every state can be lost." |
| 15 | PingCAP | TiKV RFC 0077: In-memory pessimistic locks | adr | undated, tracking issue 11452 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0077-in-memory-pessimistic-locks.md | Locks stop being replicated because losing them is survivable, with the projected gain | "it is still safe if some pessimistic locks are lost at the time of committing the transaction"; "This change expects to reduce disk write bandwidth by 20% and reduce the latency of pessimistic locking by 50% according to preliminary tests on the TPC-C workload." |
| 16 | PingCAP | TiKV RFC 0112: Apply Raft Log Before Persistence | adr | tracking issue 16717, 2024 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0112-apply-raftlog-before-persistence.md | Cloud disk jitter is the stated reason for applying before the local write lands | "In the cloud environment, we have encountered performance issues with disk IO latency jitters"; "waiting for the persistence of the current instance is unnecessary"; the bound moves "from min(committed, persisted) to committed" |
| 17 | PingCAP | TiKV RFC 0067: Substitute rocksdb write stall | adr | tracking issue 10137, 2021 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0067-substitute-rocksdb-write-stall.md | Flow control is taken away from the storage engine and moved up to the scheduler | "we need to turn off the write stall mechanism of RocksDB, and add a limiter in the very beginning of TiKV to throttle write flow more smoothly"; "16MB/s will be set for max_delayed_write_rate by default"; "We can tolerate long-time higher request duration, while latency spike is not what we want." |
| 18 | Cockroach Labs | Pebble: differences from RocksDB | adr | undated, master | 2026-10-06 | https://github.com/cockroachdb/pebble/blob/master/docs/rocksdb.md | A second organisation reached the opposite conclusion about throttling | "Artificial delays increase write latencies without a clear benefit. Writes stalls in an open loop system would indicate that writes are generated faster than the system could possibly handle, which adding artificial delays won't solve."; "Pebble doesn't add artificial delays to user writes" |
| 19 | PingCAP | TiKV RFC 0091: Online Unsafe Recovery | adr | tracking issue 10483 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0091-online-unsafe-recovery.md | The documented price of recovering from majority loss | "There must be something lost after a TiKV cluster recovers from that"; "Committed writes can be lost, so linear consistency of Raft can be broken"; "For a given transaction, it can be partially committed, so Data Integrity can be broken" |
| 20 | PingCAP | TiKV RFC 0115: Circuit breaker | adr | tracking issue pd/8678 | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/0115-circuit-breaker.md | The control plane's own metastable failure mode, and the protection shipping off by default | "the PD leader can become overwhelmed during certain failure conditions, leading to a 'retry storm' or other feedback loop scenarios. Once triggered, PD transitions into a metastable state and cannot recover autonomously"; tidb_cb_pd_metadata_error_rate_threshold_pct "Default value: 0" |
| 21 | PingCAP | TiKV design doc: Queue Fairness in the Unified Read Pool | adr | undated, in rfcs/text | 2026-10-06 | https://github.com/tikv/rfcs/blob/master/text/queue-fairness.md | Background work is demoted below every tenant's foreground work | "Background tasks (GC, compaction, statistics) use LOW group_priority regardless of their resource group's configured priority"; "When queue is full, new tasks are rejected with ServerIsBusy" |
| 22 | PingCAP | TiKV RFC PR 121: region level isolation (closed unmerged) | source | opened 2025, closed 2026-04-14 | 2026-10-06 | https://github.com/tikv/rfcs/pull/121 | Isolation at the region level was argued for and rejected in favour of query-level control | Reviewer @glorv (2025-12-22) questioned whether region-level fairness solves the problem and suggested "query level resource control"; @v01dstar (2026-01-05) warned it "might be counter-productive for complex queries"; @jiadebin (2026-01-06): "when the system is not overloaded, the excessive pursuit of region-level fairness in business hotspot scenarios may harm the performance of critical business operations" |
| 23 | PingCAP | tikv coprocessor split-check config | source | master, retrieved 2026-10-06 | 2026-10-06 | https://github.com/tikv/tikv/blob/master/components/raftstore/src/coprocessor/config.rs | What the region-size redesign actually shipped as | "In version < 8.3.0, the default split size is 96MB. In version >= 8.3.0, the default split size is increased to 256MB"; DEFAULT_BUCKET_SIZE: ReadableSize::mb(50); enable_region_bucket defaults to false |
| 24 | PingCAP | tikv raftstore config defaults | source | master, retrieved 2026-10-06 | 2026-10-06 | https://github.com/tikv/tikv/blob/master/components/raftstore/src/store/config.rs | Hibernation is still on by default in 2026, and the unpersisted-apply gap is bounded | hibernate_regions: true; max_apply_unpersisted_log_limit: 1024; raft_store_max_leader_lease: ReadableDuration::secs(9) |
| 25 | PingCAP | TiDB design document process | adr | undated, master | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/README.md | The record exists because the process requires it, and what counts as accepted | "The design document is accepted or rejected when at least two committers reach consensus and no objection from the committer." |
| 26 | PingCAP | Proposal: Reduce Data inconsistencies | adr | 2021-09-22 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2021-09-22-data-consistency.md | Inconsistency was frequent enough to justify permanent in-path assertions | "TiDB occasionally encounters data index inconsistencies"; impacts include "Data Loss: Data written cannot be read"; "It is very difficult for support engineers to locate data index inconsistencies when they occur." |
| 27 | PingCAP | Proposal: Keyspace | adr | 2022-12-07 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2022-12-07-keyspace.md | Multi-tenancy implemented as a key prefix, with a hard ceiling | "we introduce a new concept referred to as Keyspace to describe the logical isolation among different business scenarios within a TiKV cluster"; "The max keyspace id is 16777216, no new keyspaces can be created after the maximum keyspace id has been reached." |
| 28 | PingCAP | Global Resource Control in TiDB | adr | 2022-11-25 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2022-11-25-global-resource-control.md | Admission control was missing, and the unit of control is the billing unit | "Currently, TiDB lack of global admission control limits the request from the SQL layer to the storage layer"; "this resource control mechanism can be used by Resource Manage in the future of TiDB Cloud. Users can pay for the actual usage."; "TiKV uses the dmclock algorithm to ensure the fairness between different resource groups." |
| 29 | PingCAP | Runaway Queries Management | adr | 2023-06-16 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2023-06-16-runaway-queries-management.md | Per-request deadlines do not bound a query, so the system kills statements by elapsed time | "we already have the deadline mechanism pushed down to the TiKV layer that one coprocessor request would not execute in TiKV more than 60s by default. But a runaway query may not cost too much time on one single coprocessor request"; ACTION = (DRYRUN|COOLDOWN|KILL) |
| 30 | PingCAP | Pipelined DML | adr | 2024-01-09 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2024-01-09-pipelined-DML.md | The abandoned workaround for large transactions, and the limit that forced it | "A config item that controls the txn size txn-total-size-limit ... default 100MB"; of the earlier batch-dml feature: "It has been deprecated and not suggested for use because it is unsafe and highly prone to corrupt data." |
| 31 | PingCAP | TiDB Global Memory Arbitrator | adr | 2025-04-15 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2025-04-15-global-memory-arbitrator.md | Memory becomes a scheduled resource, with killing as the designed safety valve | "replaces the original optimistic posteriori method with a pessimistic scheduling model (subscription-first-then-allocation)"; "When facing an OOM Risk, the arbitrator will use the KILL method to protect the memory safety." |
| 32 | PingCAP | Active-Active Deployment design | adr | 2025-11-05 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2025-11-05-active-active.md | Across clusters, the decade's founding guarantee is given up on purpose | "This design provides eventual consistency, and any write conflicts are resolved using the Last Write Wins (LWW) strategy."; "the solution does't provide global transactional consistency" |
| 33 | PingCAP | TiDB TopRU | adr | 2026-01-19 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2026-01-19-topru-design.md | Observability is now organised around the billing unit | "Next-gen TiDB Cloud charges by RU (Request Unit). When cluster RU consumption is abnormal or reaches the limit, users need to quickly identify high RU-consuming SQLs" |
| 34 | PingCAP | Query-Level Per-Store Coprocessor Request Limiter | adr | 2026-07-29 | 2026-10-06 | https://github.com/pingcap/tidb/blob/master/docs/design/2026-07-29-query-level-per-store-cop-request-limiter.md | The current frontier: bounding one statement's fan-out onto one store | "The limit applies after client-go selects the actual target TiKV store"; tidb_query_cop_store_limit "The default is 15; 0 disables the statement-level per-store limit." |
| 35 | PingCAP | Issue 44619: data index inconsistent after DDL owner change | postmortem | opened 2023-06-13 | 2026-10-06 | https://github.com/pingcap/tidb/issues/44619 | An ownership change during an index build leaves half the index missing | Title: "data index inconsistent after DDL owner change several times (at least twice)"; reported check output "table count 10,008,00 != index(idx1) count 4,666,669"; labelled severity/critical, affects 7.1.x LTS |
| 36 | PingCAP | Issue 52914: data inconsistency during adding index with replace into | postmortem | opened 2024-04-26 | 2026-10-06 | https://github.com/pingcap/tidb/issues/52914 | Concurrent DML against the backfill phases breaks the index, found by a schema fuzzer | Concurrent REPLACE INTO during index creation "before import and before merge stages"; found through fuzz testing (schrddl) with failpoint injection; severity/critical; affects 6.5.x, 7.1.x, 7.5.x and 8.1.x LTS |
| 37 | PingCAP | Issue 54897: admin check failed after injected DDL owner network partition | postmortem | opened 2024-07-25 | 2026-10-06 | https://github.com/pingcap/tidb/issues/54897 | The same class reappears under a deliberately injected partition, and is backported to four LTS lines | Title quotes the user-visible error: "Error 8223 (HY000): data inconsistency in table"; reproduction used distributed task mode with an injected "ddl owner network partition during adding index"; impacts 6.5, 7.1, 7.5 and 8.1 LTS |
| 38 | PingCAP | Issue 55808: lightning didn't ingest all kv after tikv is down longer than 810s | postmortem | opened 2024-09-03 | 2026-10-06 | https://github.com/pingcap/tidb/issues/55808 | A dependency outage longer than a fixed retry budget silently truncates an index build | Title: "data inconsistency in table (lightning didn't ingest all kv) after tikv is down longer than 810s"; failure observed during a rolling restart; affects v7.1.x, v7.5.x, v8.1.x |
| 39 | Ongaro and Ousterhout | In Search of an Understandable Consensus Algorithm | paper | draft of 2013-10-07 | 2026-10-06 | https://github.com/papers-we-love/papers-we-love/blob/main/distributed_systems/in-search-of-an-understandable-consensus-algorithm.pdf | The guarantee that makes local persistence optional | "Raft guarantees that committed entries are durable and will eventually be executed by all of the available state machines." |
| 40 | Corbett et al. (Google) | Spanner: Google's Globally-Distributed Database | paper | OSDI 2012 | 2026-10-06 | https://github.com/papers-we-love/papers-we-love/blob/main/datastores/spanner-google%27s-globally-distributed-database.pdf | The property TiKV claims lineage from and the 2025 cross-cluster design drops | Spanner provides "externally consistent [16] reads and writes, and globally-consistent reads across the database at a timestamp" |
| 41 | PingCAP | TiDB 8.5.8 release notes | vendor | 2026-08-27 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-8.5.8.md | The evidence cutoff for the release-note corpus | "Release date: August 27, 2026" |
| 42 | PingCAP | TiDB 8.3.0 release notes | vendor | 2024-08-22 | 2026-10-06 | https://github.com/pingcap/docs/blob/master/releases/release-8.3.0.md | Dating the shipped region-size change | "Release date: August 22, 2024" |
Derived counts (computed in this session, method stated)
| # | What | Value | Method |
|---|---|---|---|
| D1 | Release-note bullets across the whole corpus that mention an inconsistency involving data or indexes | 148 | grep over all 208 files in the releases/ directory of pingcap/docs at master for lines matching inconsisten together with data or index, then manual classification |
| D2 | Of those, bullets whose trigger is in the online schema-change path | 36 | keyword classification on the same set (add index, DDL, schema, reorg, partition, upgrade); the largest single class |
| D3 | Design documents in pingcap/tidb/docs/design |
136 files, dated 2018-07-01 to 2026-09-09 | directory listing of the clone |
| D4 | TiKV RFCs merged into tikv/rfcs/text |
46 | directory listing of the clone |
| D5 | Closed-unmerged RFC pull requests in tikv/rfcs |
23 | GitHub PR filter is:pr is:closed is:unmerged on the repository |
| D6 | Design documents whose subject is resource governance or tenancy | 0 before 2021, 12 from 2021 onward, 4 of the 10 filed in 2026 | filename keyword classification (resource, runaway, memory, keyspace, limiter, arbitrator, topru, quota, background-task); crude, and 28 of 136 documents fall in no class |
| D7 | Ratio between the region size proposed in RFC 0082 and the default that shipped | 10 GiB proposed, 256 MB shipped, about 2.5% of the proposed value, against a 96 MB starting point | RFC 0082 text and the SPLIT_SIZE constant in the shipped config |