Stored procedures and triggers block a direct MySQL migration
Before pointing a MySQL application at TiDB, check whether it uses triggers. PingCAP's MySQL compatibility guide lists triggers and stored procedures as unsupported. TiDB suits teams that need SQL transactions across machines and want to keep their MySQL drivers. I'd leave a comfortably sized MySQL deployment alone until there's a specific capacity or availability problem to solve.
The source gives you some sense of the commitment: our checkout contained 7,735 files, roughly 1,753,932 lines of source, and occupied 156.6 MB. TiDB is written primarily in Go, with an English README and English documentation. Apache-2.0 licensing is a useful reason to consider it when you need source access and permission to modify the database. The license doesn't reduce the work of understanding a distributed system.
What happened when we ran it
Our run installed 964 packages in 177 seconds and built TiDB successfully in 374 seconds. We cloned commit d09ecd3 on October 9, 2026, using an unprivileged Debian container with 3 CPUs, 8 GB of RAM, the golang:1.24-bookworm image, and no secrets. These measurements describe working with the repository. They provide no database throughput, query-latency, or failover result, so they can't tell you how a production cluster will handle your traffic.
The test step timed out at 900 seconds. The captured go test summary reported 4 passed and 2 failed out of 6, a partial result rather than a census of TiDB's entire suite. The log tail names github.com/pingcap/tidb/br/pkg/utils as failed after 54.533 seconds. Nearby utility subpackages passed, while other packages had no test files. A successful compiler run therefore came with an unfinished, failing test run.
Immediately before FAIL, the log shows backup-task counters increasing and decreasing, followed by warnings about TiKV's garbage-collection ratio and RocksDB background jobs. It doesn't show the failing assertion or explain either reported failure. Blaming a missing Debian package, insufficient memory, or a database defect would exceed that evidence. Our scan also found 7 CI workflow files, a Dockerfile, and a tests directory. Those files establish that checks exist, without changing the outcome we captured.
SQL servers, PD, and TiKV have separate jobs
TiDB's SQL servers accept client connections and plan queries; TiKV stores transactional data. Placement Driver, usually shortened to PD, manages cluster metadata and scheduling. That separation lets you expand SQL capacity independently of storage. It also gives your operations team several services to understand when a query stalls. The architecture guide makes those responsibilities clear, which matters more to an adopter than the README's broad performance claims.
The 156.6 MB checkout we measured isn't the footprint of a deployed database cluster. The README also describes TiFlash, a column-oriented store that receives replicas from TiKV for analytical queries. This is TiDB's strongest reason to look beyond straightforward transactional scaling: reporting can use a different storage layout while transactions keep their row-oriented store. TiFlash adds another component to operate. Whether that arrangement improves your own reports still needs a workload evaluation.
TiUP Playground discards data unless you ask it to persist
PingCAP's local playground guide warns that its default trial cleans up cluster data. Use a persistent tag if you want to keep your work between sessions. Playground binds to localhost by default, and the documented SQL connection uses the root account. It's a sensible way to explore SQL behavior before choosing a deployment route. Our 374-second source build measures a different path from this downloaded-binary playground.
For a lasting deployment, TiUP manages a topology describing the services and their hosts. Its production deployment guide covers SSH access and environment checks. You'll need database accounts and a security configuration, plus decisions about storage, backups, and monitoring. Self-managed deployment doesn't require a TiDB Cloud account. Cloud is a separate route recommended by the README; choose it if you'd rather have PingCAP operate the infrastructure, then assess its service terms separately.
MySQL replication tooling needs a separate migration decision
TiDB doesn't implement MySQL's native replication protocol. PingCAP documents Data Migration for moving MySQL data into TiDB and TiCDC for outgoing changes, including a MySQL destination. Existing replication automation therefore needs its own review. Search deployment scripts as well as application SQL for dependencies on the current database. Keeping a driver doesn't mean keeping every operational tool.
Our 964-package install is a contributor's cost, separate from the adoption decision. If your database still fits comfortably on a conventional server, MySQL is my first alternative. If you've committed to scaling existing MySQL servers through sharding, compare Vitess, whose project centers on clustering MySQL. TiDB earns the extra evaluation when its distributed transactions and independently scalable services address a problem you can name. Choosing it merely to prepare for hypothetical growth buys work immediately.
October pushes and issue activity show ongoing maintenance
The repository's last push was October 14, 2026. GitHub listed 40,642 stars and 7,319 open issues and PRs, and its latest-release endpoint returned v7.5.8, published September 17. The issue queue was active too: issue 71966, opened October 14, reports a panic during statement rollback after cancellation. A linked pull request proposes a fix. That is a reported defect under active discussion, with no established connection to our sandbox failure.
I'd shortlist TiDB for a team already facing distributed SQL requirements and able to own its cluster. The 900-second timeout leaves contributors with a concrete follow-up: isolate the BR utility failure and capture the missing assertion before trusting this commit's checks. Application adopters should start with their stored procedures, replication dependencies, and hardest queries. If those reveal more migration work than the scaling problem justifies, stay with MySQL.