TiDB splits SQL, metadata, and storage into separate services
A TiDB cluster uses stateless TiDB servers for the MySQL-facing SQL layer, PD servers for metadata and scheduling, and TiKV nodes for transactional storage. TiFlash is an optional columnar store for analytical work on replicated data. This separation lets operators add compute or storage capacity independently. It also changes the unit of ownership: adopting TiDB means running a database system with several coordinated services, rather than replacing one MySQL process with one TiDB process.
The repository we measured contained 7,638 files and about 1,699,559 lines of source in a 151.1 MB checkout. It includes the SQL server plus backup, restore, import, planning, execution, and test code, while TiKV, PD, and TiFlash live in related projects. Seven CI workflow files, a Dockerfile, and a tests directory were present. That source footprint is consistent with TiDB's role as one major component in a larger distributed database platform.
TiUP Playground is a local trial, while production starts larger
The self-managed quick start labels TiUP Playground as a non-production path. Its default starts 1 TiDB, 1 TiKV, 1 PD, and 1 TiFlash instance, with Dashboard and Grafana endpoints. A more representative local topology uses 2 TiDB, 3 TiKV, and 3 PD instances; PingCAP recommends at least 10 GiB of memory and 4 CPU cores for that command. Data disappears on cleanup unless the playground starts with a persistent tag.
Building the checked-out source was a heavier exercise. Our install succeeded in 119 seconds and pulled 964 packages. The build then completed successfully in 385 seconds on 3 CPUs and 8 GB of RAM. Those numbers describe repository development, rather than a TiUP binary installation or a running cluster. They still matter for contributors: a clean build consumed more than 6 minutes before tests began, so iteration speed and CI capacity need planning.
What happened when we ran it
Our unprivileged Go 1.24 Debian sandbox cloned commit 049e0e2 with no secrets. Installing 964 packages took 119 seconds, and the build passed in 385 seconds. The test command then ran for the full 900-second allowance and timed out. Its summary at that point reported 4 passed and 2 failed out of 6. A timed-out partial run cannot establish the state of the full TiDB test suite, but it does establish that our bounded run did not pass.
The log tail identified github.com/pingcap/tidb/br/pkg/utils as failed after 61.226 seconds. It showed informational messages about log backup task counts and warnings about TiKV configuration, then a plain FAIL; it did not expose the failing assertion or cause. Other lines showed passing utility subpackages and packages with no test files. We cannot explain the 2 failures from that tail. The useful decision point is that this commit built, while the measured test slice needed more than 900 seconds and ended non-green.
MySQL compatibility excludes procedures, triggers, and native replication
TiDB accepts MySQL clients and supports common MySQL 5.7 and 8.0 syntax, which reduces application migration work. The compatibility guide also lists firm gaps: stored procedures, functions, triggers, events, user-defined functions, FULLTEXT indexes in self-managed TiDB, spatial data types, and several other features are unsupported. TiDB does not implement the MySQL replication protocol. PingCAP supplies Data Migration for inbound MySQL replication and TiCDC for outbound change streams instead.
That compatibility audit belongs before the 119-second install or 385-second build. Search schemas, migrations, and application SQL for unsupported features, then exercise transaction semantics and query plans with production-shaped data. The README's claim that many applications need little or no code change is plausible for ordinary driver usage. It is not a blanket promise for every MySQL workload. TiDB also defaults to snapshot isolation, so teams relying on a particular isolation behavior should test it explicitly.
Production high availability starts with 2 TiDB and 3 TiKV nodes
PingCAP's v8.5 hardware guide lists minimum production counts of 2 TiDB, 3 PD, and 3 TiKV instances. Its reference configuration assigns TiDB servers 16 or more CPU cores and 48 GB of memory, TiKV nodes 16 or more cores and 64 GB, plus SSD storage and 10-gigabit networking. TiFlash adds another 2 instances at a much higher reference size. Actual sizing still depends on workload, capacity, and availability targets.
Our 151.1 MB checkout and 964 installed packages cover only the code environment we tested. A production rollout also needs topology management, network ports, certificates, user accounts, backups, restore drills, alerting, and failure-domain placement. TiUP automates deployment and routine cluster actions, while operators remain responsible for those choices. Small teams should compare that burden with TiDB Cloud or a simpler managed MySQL service before buying servers for a topology whose capacity they do not need.
v8.5.8 and September activity show current maintenance
TiDB v8.5.8 was released on August 27, 2026, and the repository was pushed on September 3. GitHub showed 40,483 stars and 6,898 combined issues and pull requests when fetched; that combined count is not a bug count. Issue activity was current on September 3: a monitored flaky-test report was closed after it had not reproduced recently, and a new moderate server-admission report was opened. The release notes include fixes across TiDB, TiKV, PD, TiFlash, backup, and change-data capture.
TiDB deserves a trial when horizontal SQL scaling and mixed transaction and analytics work solve an existing problem. Our 385-second build passed, but the 900-second test run stopped with 4 passed and 2 failed out of 6, so contributors should reproduce the BR utility failure with a longer diagnostic run. Application teams should start with TiUP Playground, complete the MySQL compatibility audit, and model the full production topology. If that sounds disproportionate, the workload is probably still better served by one conventional database.