TiDB

Writing rule: each feature = what it is + why it's genuinely good + what happens when pushed to the edge.

1. Disaggregated compute and storage: second-level scaling of the stateless SQL layer The real strength: TiDB Server is fully stateless — it only parses, optimizes, and executes; compute and storage scale independently — add TiDB nodes when reads are heavy, TiKV nodes when writes are heavy. This is the most fundamental fork from OceanBase's "unified" architecture: scaling compute in cloud-native elastic scenarios requires no data movement. Edge truth: what's second-level is compute; storage scale-out (adding TiKV) relies on PD to migrate and redistribute Regions, consuming IO and network — doing it during peak hours is like "changing the engine mid-flight"; and leader switches on hot Regions during migration cause latency spikes. What's fast is "adding machines," not "data being in place".
2. TiFlash real-time HTAP: dual row/column engines The real strength: TiKV's row store runs OLTP, TiFlash's columnar store runs OLAP, with the same data replicated in real time via Raft Learner and the optimizer routing automatically — one SQL interface serves both transactions and analytics, eliminating the entire "T+1 ETL to the warehouse" pipeline. The typical pattern at companies like Dewu (得物): sharded MySQL for point lookups, TiDB for non-sharded queries and complex analytics. Edge truth: see Deep Waters #4 — Learner replication is async; a "strongly consistent read" returns "some committed version," not "the latest"; under write bursts the learner lags and HTAP query latency blows up directly; the optimizer's routing can pick the wrong engine. HTAP is T+seconds, not T+0.
3. Percolator distributed transactions: cross-node ACID The real strength: two-phase commit based on the Google Percolator paper gives natively ACID cross-Region/cross-node transactions — no need for the application layer to cobble together "eventual consistency." That's a generational advantage over MySQL sharding (which has no distributed transactions across shards). Edge truth: see Deep Waters #2 — the 2PC tax is paid per Region crossed; the 100MB default per-transaction limit and 6MB per-row limit are hard-wired into the architecture (v6.5+ switched to session memory quotas; v8.0 bulk DML bypasses it); distributed transactions on hot rows are lock-wait amplifiers. With a poorly designed transaction model, distributed transactions are slower than sharding.
4. MySQL protocol compatibility + migration toolchain The real strength: protocol-level compatibility with MySQL 5.7 — drivers, ORMs, Navicat/DBeaver are plug-and-play; DM handles MySQL→TiDB full + incremental migration, TiCDC handles reverse/heterogeneous replication, Lightning/BR handle bulk import/export. The cognitive cost of migration for MySQL teams is the lowest among Chinese distributed databases. Edge truth: see Deep Waters #7 — the remainder of "95% compatibility" is stored procedures, triggers, events, full-text indexes, GIS, XA, CTAS, etc. (each listed as unsupported in the official compatibility docs); AUTO_INCREMENT semantics differ subtly from MySQL (batch allocation; not guaranteed monotonic across TiDB instances) — copying a MySQL schema verbatim runs straight into write hotspots. What's compatible is "the protocol and common syntax," not "behavioral parity."
5. Fully open source with a global ecosystem The real strength: Apache 2.0, the kernel fully public on GitHub, TiKV a CNCF graduated project; top-ranked among Chinese databases globally on DB-Engines; complete Chinese/English docs, AskTUG community, and TiDB Dashboard observability toolchain. For teams expanding overseas, going multi-cloud, or unwilling to be locked into a single vendor, that's a structural advantage over OB/TDSQL. Edge truth: what's open-sourced is the code, not the operational capability — deep-waters problems (hotspots, TSO bottlenecks, TiCDC lag) ultimately require reading source code or buying vendor support; the official roadmap footnote admits "features may vary across subscription tiers," so production-grade SLA still costs money. And: when community-edition users hit a kernel-level bug, no matter how fast it's fixed, they must upgrade themselves — and upgrading is itself a deep water (see the complaint list).

Each entry = mechanism + what happens when pushed to the edge + what it means for your decision. Evidence types are labeled.

Deep Waters #1: TSO — the "free" global clock isn't free

• Mechanism: PD's TSO service hands out globally monotonic timestamps (physical_ms << logical_bits | logical_counter); every transaction's start_ts/commit_ts must be fetched from PD; the TiDB client uses TSFuture async batch prefetching so it doesn't block the read/write hot path in real time.
• Pushed to the edge:
  • The official tuning docs admit: TSO becomes the bottleneck under high-frequency small transactions — in a measured case, TSO wait exceeded 1/4 of execute time (under read-committed isolation every statement fetches a TSO; since v6.0 tidb_rc_read_check_ts reduces TSO fetches).
  • The official mitigations are themselves "downgrades": tidb_low_resolution_tso (reads cached timestamps — may read seconds-old stale data), merging small transactions, tidb_tso_client_rpc_mode=PARALLEL/PARALLEL-FAST (v8.4+, trading 2–4x RPCs for lower latency).
  • PD high availability relies on an embedded etcd 3-node Raft; timestamping is unavailable during leader elections (~3 seconds, per community notes 社区共识); when TiDB can't get a TSO it raises 9001 PD server timeout (the TiDB background worker errors if it can't obtain a safepoint within 100 seconds).
  • Cross-datacenter deployments put TSO RPC latency straight onto the bill: in an official example, same-datacenter TSO wait was ~206µs, rising to 3.12ms across datacenters (different AZs in the same region).
  • The official roadmap lists "microservicizing PD's routing functions (stateless, avoiding PD becoming a cluster resource bottleneck)" as a future direction — the vendor itself admits PD risks becoming a bottleneck.
• What it means for your decision: POCs must stress the "high-frequency small transaction" model and watch Grafana's PD TSO Wait/RPC dashboards; cross-AZ/cross-datacenter deployments must budget TSO latency into P99; low-resolution TSO is an explicit consistency-for-latency trade-off, not a free optimization.
• Sources: official docs (performance-tuning-config.md, performance-tuning-methods.md, error-codes.md, tidb-roadmap.md); community consensus (MVCC/TSO technical analyses).

Deep Waters #2: the Percolator 2PC tax — paid per Region crossed

• Mechanism: optimistic transactions (the default) do two phases at commit: prewrite writes locks on all keys (carrying start_ts), then fetch commit_ts to commit the primary key and asynchronously clear locks on the other keys; pessimistic transactions (tidb_txn_mode='pessimistic') lock on write.
• Pushed to the edge:
  • Hard ceilings (official transaction-overview.md): 6MB max per row; 100MB default per transaction (txn-total-size-limit, configurable up to 1TB), with transaction memory amplification up to 2–3x; since v6.5 it's counted toward session memory governed by tidb_mem_quota_query; since v8.0, DML with tidb_dml_type="bulk" is exempt — but that's a "bypass," not an "elimination."
  • Exceeding the limit errors out directly: 8004 transaction too large, 8005 Write Conflict, txnStartTS is stale; under pessimistic transactions, SELECT FOR UPDATE hitting a write conflict doesn't retry — it rolls back with 8002 directly, and the application must redo the entire transaction itself.
  • A single transaction holds locks up to max-txn-ttl (default 1 hour); expired locks may be cleared by other transactions, failing the commit; long transactions also stall GC (default 10 minutes), causing MVCC old versions to pile up and space to bloat.
  • Hot rows + distributed transactions = a disastrous combination: in flash-sale inventory-deduction scenarios, optimistic-transaction conflict retries waste the whole transaction's work — you must switch to pessimistic transactions; but pessimistic lock waits then slow the whole pipeline.
• What it means for your decision: ETL/bulk writes must be split into batches (official FAQ, verbatim: large transactions "stall the Raft replication pipeline underneath"); POCs must stress-test with realistic transaction models (including hot rows), not just single-table point lookups; the "hundreds of thousands of rows per transaction" pattern brought over from MySQL is the #1 trap.
• Sources: official docs (transaction-overview.md, error-codes.md, tidb-configuration-file.md, the older FAQ).

Deep Waters #3: Region hotspots — the first line of the schema determines the ceiling

• Mechanism: data is split into Regions by key range (256MiB default since v8.5); Regions are the basic unit of Raft replication and scheduling; AUTO_INCREMENT IDs funnel all new writes into the "last Region" — a tail hotspot.
• Pushed to the edge:
  • The official docs (auto-increment.md) explicitly warn: "Using AUTO_INCREMENT may cause hotspot issues in production; AUTO_RANDOM is recommended instead." In TiDB, AUTO_INCREMENT is allocated by each TiDB Server in cached batches (30k per batch by default) and is not guaranteed monotonic across instances — semantically different from MySQL to begin with.
  • Every scattering technique has a cost: SHARD_ROW_ID_BITS only works on implicit-rowid tables, and setting it too large amplifies RPC counts and CPU/network overhead (official docs, verbatim); AUTO_RANDOM (5 random bits + 59 auto-increment bits) solves write hotspots but IDs are no longer sequential — no longer "auto-incrementing"; time-ordered PKs (created_at prefix) are tail hotspots too.
  • Community-tested (MySQL vs TiDB POC, 2026-09): in single-node read-heavy scenarios MySQL TPS led TiDB by 58%–81%, with the conclusion "Single-node read-heavy: MySQL leads overwhelmingly; TiDB's fixed architectural cost has no workaround" — every query goes through RPC + multi-replica + RocksDB; that's an architecture tax tuning can't erase.
  • v8.5 raised the default Region from 96MiB to 256MiB (official performance report: OLTP inserts +27%, Analyze +45% — vendor claim, cited for architecture-evolution reference only, not used as a verdict basis) — essentially "trading coarser scheduling granularity for lower management overhead"; but for small-table, query-heavy workloads, large Regions may instead concentrate hotspots (the official blog recommends smaller Regions for such workloads).
• What it means for your decision: PK design is the #1 priority in TiDB schema design — breaking up hotspots after launch is effectively a rewrite; POCs must stress-test with a realistic ID-generation strategy + realistic write distribution; read-heavy workloads with <100GB of data may be faster and cheaper on single-node MySQL — the community-consensus "not suitable" profile.
• Sources: official docs (auto-increment.md, troubleshoot-hot-spot-issues.md cited), official v8.5 performance analysis, community-tested (MySQL vs TiDB POC).

Deep Waters #4: TiFlash's "real-time" — the async truth of Learner replication

• Mechanism: TiFlash is a read-only replica of TiKV that replicates data asynchronously via the Raft Learner protocol; reads on TiFlash are consistency-checked against the Raft log index — they return only "the synced committed version," guaranteeing "some consistent snapshot," not "the latest."
• Pushed to the edge:
  • Learner lag under write bursts is the norm: the data version TiFlash reads lags behind TiKV, so HTAP queries' "real-timeness" degrades to T+seconds or even T+minutes — while the business believes it's doing "real-time analytics."
  • The optimizer's automatic routing (TiKV vs TiFlash) can pick wrong: stale statistics and cost-estimation bias send OLAP queries into TiKV full table scans, or point lookups into TiFlash; tidb_enforce_mpp can force it, but that's treating the optimizer as decoration.
  • TiFlash is read-only: all writes must go through TiKV first — on the write-amplification path TiFlash is merely a "spectator"; a TiFlash node failure doesn't affect OLTP, but HTAP queries degrade directly.
  • Resource isolation is a "recommendation," not the default: when TiFlash and TiKV are co-deployed, large analytical queries' CPU/IO crowds out OLTP — official guidance recommends dedicated TiFlash nodes, meaning HTAP costs an extra set of machines.
• What it means for your decision: think of TiFlash as a "seconds-latency real-time warehouse," not "zero-latency"; HTAP POCs must stress OLTP writes and OLAP queries simultaneously and watch the learner lag metric; for pure OLAP heavy-query workloads, ClickHouse/Doris usually offer better price-performance 社区共识.
• Sources: official architecture (TiFlash Raft Learner mechanics), community technical analyses (TiFlash consistent-read internals); "co-deployment resource contention" is community consensus.

Deep Waters #5: write bursts → RocksDB write stall → flow control rejects writes

• Mechanism: each TiKV has two RocksDB instances (data/raft stores Raft logs, data/db stores real data); writes first pass the scheduler for transactional consistency checks, then enter raftstore (Store threads replicate → Apply threads persist).
• Pushed to the edge:
  • When RocksDB compaction can't keep up with writes (pending compaction bytes pile up), write stall triggers — per the official troubleshooting docs: before v5.2, clients got ServerIsBusy, rejecting all writes (a QPS cliff); since v5.2, a flow-control mechanism instead: it first delays write requests, soft-pending-compaction-bytes-limit (default 192GiB) starts rejecting some writes, and hard-pending-compaction-bytes-limit (default 1024GiB) rejects all writes.
  • This is TiDB's version of "error 4030": the harder you write, the heavier the compaction debt — eventually repaid in the form of "rejected writes." More easily triggered on SATA SSDs (official advice: when disk throughput tops out, either switch to NVMe or trade CPU for disk with higher-compression-ratio algorithms).
  • Cross-datacenter adds another layer: Raft quorum acknowledgment means writes must sync to at least 2 datacenters; the old official FAQ recommends <5ms cross-datacenter latency; same-city dual datacenters (<3ms) can run active-active writes, while remote sites (20ms dedicated lines) can only do DR — write latency strongly correlates with physical distance; that's a tax Raft writes into the architecture.
  • Community-tested (cross-IDC+GCP POC): cross-region TPS drops, but "always 0 errors" — no deadlocks, no write conflicts — cross-region optimistic locking means "slower but still correct," in contrast to MySQL primary-replica cross-region, where "conflicts are resolved manually."
• What it means for your decision: write-intensive workloads must monitor compaction/flow-control metrics (pending compaction bytes) and plan write throttling; disk choice directly determines the write ceiling — SATA on TiDB is "usable but may demand its tax at any time"; for active-active architectures, check dedicated-line latency before discussing the design.
• Sources: official docs (tidb-troubleshooting-map.md flow-control section, performance-tuning-methods.md write path, the older FAQ on active-active), community-tested.

Deep Waters #6: DDL, GC, and upgrades — the triple ops pitfall

• Mechanism: DDL is online and async (multi-state transitions); GC cleans MVCC old versions every 10 minutes by default; upgrades run via TiUP rolling restarts.
• Pushed to the edge:
  • DDL historically executed serially (single DDL owner); v6.2 introduced a concurrent DDL framework, but the v6.2→v6.5 upgrade once stalled when the KV queue changed to a table queue (the official upgrade FAQ has a dedicated section: plugin loading, kill -9, and DDL owner changes can all stall upgrades).
  • v6.3 introduced metadata locks, enabled by default in v6.5: DDL on tables with uncommitted transactions gets blocked — "online DDL" ≠ "DDL anytime"; ADD INDEX during peak hours may queue indefinitely.
  • information schema is changed (error-8027-class scenarios): SQL errors out directly when a TiDB Server's schema version lags — the root cause is often network jitter between TiDB and PD.
  • Long transactions / stuck TiCDC drag the GC safepoint: MVCC old versions can't be deleted and disk space keeps bloating — the classic confusion of "deleted data but space not freed"; the root cause is often GC being stuck behind some slow consumer.
  • Community case (Dewu (得物) upgrade practice, v5.3.3→v7.5.x): in the v4.x era, TiKV nodes auto-restarted after running >2 years; before v6.5, TiCDC frequently lagged/OOMed; after upgrading, the v7.5 optimizer gravitated toward full table scans for a while (a 21.5-billion-row table took 60s to time out on a full scan vs 0.4s with a forced index) — fixed via tidb_opt_prefer_range_scan / SPM bindings: "upgrade ≠ faster; execution plans may regress first."
  • In-place upgrades don't support rollback, and large version jumps require incremental upgrades with doubled jitter; Dewu ultimately adopted "migration-based upgrades" exclusively (new cluster + TiCDC sync), at the cost of double the machines.
• What it means for your decision: run DDL only off-peak and check for long transactions first; rehearse upgrades fully in test environments and prepare SPM/binding contingencies; GC monitoring (safepoint advancement) is a routine inspection item; write "upgrade windows" into the annual ops budget.
• Sources: official docs (upgrade-tidb-using-tiup.md upgrade FAQ, tidb-troubleshooting-map.md DDL section, error-codes.md); community-tested (Dewu upgrade practice, late 2025).

Deep Waters #7: the deep waters of MySQL compatibility — the remaining 5% of "95% compatibility"

• The official compatibility doc (mysql-compatibility.md) explicitly lists as unsupported: stored procedures/functions, triggers, events, UDFs, full-text indexes, GIS/spatial types, XA syntax, CREATE TABLE AS SELECT, SKIP LOCKED, descending indexes, CHECK/CHECKSUM/REPAIR/OPTIMIZE TABLE, HANDLER, column-level privileges, LATERAL derived-table execution.
• Pushed to the edge:
  • Traditional systems (ERP/finance/telecom billing) are exactly the heavy users of stored procedures + triggers + events — migrating such systems to TiDB isn't "changing a config" but "rewriting business logic"; migration cost jumps straight from "low" to "high."
  • Foreign key constraints long an experimental feature (introduced in v6.x), less mature than MySQL — workloads relying on FKs for data integrity need re-evaluation.
  • Character sets limited to ascii/latin1/binary/utf8/utf8mb4/gbk/gb18030; lower_case_table_names and similar behave differently; SELECT ... FOR UPDATE has optimistic semantics (conflicts checked at commit) rather than MySQL's locking semantics — "same syntax, different semantics" is the most expensive trap.
  • Counterexample: internet businesses (no stored procedures, mostly auto-increment/Snowflake-ID PKs) do migrate smoothly — how treacherous compatibility is depends entirely on how much the workload depends on MySQL's exotic features.
• What it means for your decision: step one of migration assessment is sweeping for "which MySQL-proprietary features are in use," rather than declaring compatibility after a few CRUD statements pass; POCs must include a presence/absence checklist for stored procedures/triggers/full-text search, etc.
• Sources: official docs (mysql-compatibility.md); community consensus (migration guides, high-frequency AskTUG questions).

The good deserves depth too. Each entry = why it's true + edges and limits.

1. Smooth MySQL migration — "swap the database, keep the stack"
   • Why it's true: protocol-level compatibility with MySQL 5.7 means zero changes to JDBC/ORM/middleware; DM supports full + incremental (binlog) migration; Lightning handles TB-scale initial loads; the community has many complete runbooks for "zero-downtime MySQL→TiDB cutovers."
   • Edges and limits: what's smooth is "the protocol and common syntax" — Deep Waters #7's incompatibility list stands untouched; AUTO_INCREMENT semantic differences require PK rework; large transactions must be batched. Migration cost depends on "how many of MySQL's exotic features you use," not on the database itself. And DM's own pitfalls (large-binlog-file position handling, bad-connection retries) must be factored into migration risk.
   • Sources: official docs (dm/dm-overview.md, mysql-compatibility.md); community consensus. Observed version: v8.5.
2. Online horizontal scaling — "just add machines"
   • Why it's true: disaggregated compute/storage + PD auto-scheduling — data auto-rebalances after adding TiKV/TiDB nodes, with no downtime and no manual sharding; with v8.5's default 256MiB Regions, scheduling overhead drops further (official claim: OLTP inserts +27% — vendor claim, for reference only, not used as a verdict basis).
   • Edges and limits: what scales is "capacity and throughput ceiling," not "instant speedup" — during Region migration, IO/network is consumed by rebalancing traffic, so scaling up during peak hours may slow things down before speeding them up; many paid 3 years of machine and ops tax for "100x future growth" while 3 nodes would have lasted indefinitely. Model the growth curve before talking scalability.
   • Sources: official v8.5 performance analysis; community consensus. Observed version: v8.5.
3. One-stop HTAP — "one cluster, two jobs"
   • Why it's true: TiFlash Learner real-time sync + optimizer auto-routing put OLTP and OLAP on the same SQL interface; the Dewu (得物) pattern (MySQL for point lookups, TiDB for complex queries/analytics) proves the real value of "eliminating the ETL pipeline."
   • Edges and limits: see Deep Waters #4 — "real-time" means seconds, not zero latency; TiFlash needs dedicated deployment to avoid starving OLTP of resources (extra machine cost); for pure OLAP heavy queries it loses on price-performance to ClickHouse/Doris. HTAP's sweet spot is "transactions + light analytics," not "data-warehouse replacement."
   • Sources: official architecture docs; community case (Dewu (得物)). Observed version: v7.5/v8.5.
4. Open source, HA reputation, and a global ecosystem
   • Why it's true: Apache 2.0 fully open source, highly active on GitHub, TiKV a CNCF graduated project; Raft multi-replica + official RPO=0/RTO≤30s claims; Chinese/English docs and the AskTUG community are friendly to teams at home and abroad — a structural difference vs. OB/TDSQL.
   • Edges and limits: RTO≤30s is automatic failover, not backup restore (TB-scale BR restores take hours, and restores also saturate cluster resources — official guidance says restore to a new cluster); open source ≠ "you can handle it yourself" — deep-waters problems ultimately require reading source code or buying subscription support; the DB-Engines ranking (~41st globally per third-party stats) measures popularity, not quality.
   • Sources: official docs; third-party stats (citing DB-Engines); community consensus. Observed version: v8.5.
5. Observability toolchain — "distributed systems you can see"
   • Why it's true: TiDB Dashboard (heatmaps, Top SQL, slow queries), full Grafana dashboards (PD TSO, Raft, TiFlash-Summary), ADMIN SHOW DDL JOBS, etc. — first-tier observability among distributed databases; hotspot/slow-SQL diagnosis is systematic.
   • Edges and limits: more dashboards ≠ knowing how to read them — key metrics like TSO wait, pending compaction bytes, GC safepoint, and TiCDC checkpoint lag require DBAs who genuinely understand distributed principles; third-party inspection tooling comparisons still reveal metric gaps. Tools are amplifiers, not substitutes.
   • Sources: official docs (dashboard/monitoring docs); third-party comparison (TiDB monitoring/inspection gap analysis, 2026-09). Observed version: v8.5.

• One-line positioning: a distributed "upgrade capsule" built for the MySQL ecosystem — it absorbs sharding and ETL complexity into the database itself, at the cost of fixed architectural overhead, a higher hardware bar, and a steep ops learning curve.
• Good fit for:
  • Internet-scale businesses on the MySQL stack whose data volumes exceed single-node capacity (TB-scale and up) and who want to avoid sharding;
  • HTAP scenarios needing "transactions + second-level analytics" in one database (orders / risk control / behavioral analytics);
  • "Dual-run" architectures that consolidate multi-business data, push complex queries down to TiDB, and keep point lookups on MySQL;
  • Teams needing multi-cloud / overseas expansion that value full open source and no vendor lock-in.
• Not a good fit for:
  • Small databases <100GB — single-node MySQL is faster, cheaper, and less hassle;
  • Legacy systems heavily dependent on stored procedures/triggers/full-text indexes/GIS (migration = rewrite);
  • "De-O" Oracle-replacement Xinchuang (信创) scenarios (no Oracle compatibility);
  • Teams with no dedicated DBA hoping to "install and forget";
  • Pure OLAP heavy-query workloads (ClickHouse/Doris offer better price-performance).
• Migration cost:
  • MySQL → low-to-medium: protocol-compatible, DM full+incremental migration is mature; stored procedures/triggers need rewrites, auto-increment PKs should switch to AUTO_RANDOM, large transactions must be batched, complex SQL needs regression testing.
  • PostgreSQL → medium-to-high: no PG protocol compatibility; mostly application-layer rework.
  • Oracle → high: no Oracle compatibility mode; heavy Oracle features basically mean a rewrite; TiDB isn't on the shortlist for "de-O" scenarios.

• Versions & config: PingCAP official docs (tidb-configuration-file.md, incl. v9.0.0 config items; v8.4+ tidb_tso_client_rpc_mode)
• Transaction mechanics & limits: official transaction-overview.md (6MB/100MB history, v6.5 session memory quotas, v8.0 bulk DML), error-codes.md (8002/8004/8005/8025/8027/9001)
• TSO & performance tuning: official performance-tuning-config.md (high-frequency small-transaction TSO bottleneck, low-resolution TSO, parallel RPC), performance-tuning-methods.md (TSO wait share, cross-datacenter latency example)
• Compatibility: official mysql-compatibility.md (item-by-item unsupported list); auto-increment.md (AUTO_INCREMENT hotspot warning and AUTO_RANDOM recommendation)
• DDL/upgrades/BR/TiCDC: official upgrade-tidb-using-tiup.md (upgrade FAQ), tidb-troubleshooting-map.md (stuck DDL, RocksDB write-stall flow control, DM/TiDB Lightning failures), tidb-upgrade-migration-guide.md; TiFlow official design docs (TiCDC ResolvedTs/Owner/Capture mechanics)
• Roadmap: official tidb-roadmap.md (subscription-tier feature differences, unlimited-size transactions, PD routing microservicization, new TiCDC architecture; late-2024/mid-2025 plans, 2026 landing progress to-be-verified)
• Community-tested: Dewu (得物) TiDB upgrade practice (2025-11: v5.3.3→v7.5.x); MySQL vs TiDB POC (2026-09 update: single-node reads -58% to -81%, cross-region 0 errors)
• Community consensus (high-frequency AskTUG/CSDN/Juejin (掘金) topics): no TiDB for <100GB, AUTO_RANDOM instead of auto-increment, ClickHouse/Doris for pure OLAP, migration-based upgrades over in-place upgrades
• Next review: track "unlimited-size transactions" and "PD routing microservicization" after v9.0 GA; re-verify foreign key GA progress; re-verify the subscription-tier feature-difference matrix