There is a specific kind of meeting that ends with the words “we should shard.” The traffic chart is climbing, the write master is sweating, and someone has just calculated that the next hardware order is going to cost more than the rewrite. That is the moment most teams either commit to a six-month migration or quietly stop growing. There is a third option, and it lives in a project you have probably heard of but never quite trusted. The third option is TiDB, and it is worth a serious look before you sign the sharding-check.
The argument is not really about TiDB’s feature list. It is about what TiDB does not make you throw away. TiDB speaks the same wire protocol MySQL does, which means the day you switch is the day you change a hostname in your connection string. Your ORM, your client library, your monitoring, your slow-query log format, and most of your application code all keep working. The work that used to be a database migration becomes a host swap, and the storage layer underneath handles the rest. Horizontal scale without rewriting the parts of your stack that already work is the actual pitch, and it is the part that most introductions to TiDB bury under architecture diagrams.
What TiDB actually is, in plain English
TiDB is a query front end that sits in front of a fleet of storage nodes. The storage layer is called TiKV, and it is what holds the rows. A separate component, Placement Driver, watches the cluster and rebalances ranges of data across nodes as the cluster grows or shrinks. You do not see any of this from your application. The application sends normal SQL and gets normal results back.
The pieces you will see in the documentation:
- The TiDB server itself, which is stateless and easy to scale horizontally
- TiKV, the distributed row store
- Placement Driver, the coordinator that tracks where ranges live
- TiUP, which is the install and cluster management tool
That is the picture. Your application does not need a new driver. Your ORM keeps working. Your slow-query log keeps the format you already parse. The wiring you already trust keeps being the wiring you trust.
Why this matters when MySQL starts to hurt
Most applications do not need TiDB. If your entire dataset lives comfortably on one box and your writes stay under a few thousand per second, MySQL on a single host is hard to beat. The trouble starts when you hit one of three ceilings: write throughput has nowhere left to go on a single master, the working set no longer fits in one machine’s RAM or disk, or you need writes in multiple regions for latency or compliance reasons.
The conventional fixes each carry their own tax. Application-level sharding means rewriting every query path that touches the database. A managed proxy like ProxySQL helps with reads but does not solve write scaling. Migrating to PostgreSQL with partitioning changes the wire protocol and forces a real port. Each of those projects is measured in months of engineering and years of operational baggage.
TiDB’s claim is that you skip most of that cost by staying on the MySQL protocol. The application does not know it is talking to a cluster. The migration, when you eventually do it, is a connection-string change and a controlled cutover.
There is a real cost to the architecture, and pretending otherwise makes the writing useless. TiDB is not faster than a single MySQL host. The query has to traverse the coordinator and hop to the right node, and that round trip shows up as latency. For typical OLTP at thousands of writes per second, the difference is small. For million-write-per-second workloads, you have to measure carefully. Test it with your real workload before you bet the budget.
Installing TiDB on Linux with TiUP
TiUP is the official installer and the fastest path to a working setup on Ubuntu, Debian, or RHEL. The flow is short enough to fit in one terminal session:
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bashrc
tiup playground
That command spins up the full set of components on your laptop and starts a TiDB server listening on port 4000. Point your existing MySQL connection string at that port, run your test suite, and see what happens. If the tests pass, you have just demonstrated that your application is compatible with TiDB without writing a line of new code.
For production, TiUP handles multi-node clusters with the same pattern. You describe the topology in a YAML file, run tiup cluster deploy, and TiUP takes care of placement, replication, and rolling restarts. The first time you do this end-to-end, budget an afternoon. The second time, budget an hour. By the third time, you will not need the documentation.
When TiDB is the right call, and when it is overkill
Pick TiDB when your MySQL is genuinely bottlenecked on write scaling, when your dataset has outgrown a single host, or when you need multi-region writes without building a custom replication layer. It is also a smart pick for small teams that want horizontal scale without hiring a dedicated database engineer to manage sharding.
Skip TiDB when your data fits comfortably on one host, when reads dominate writes by a wide margin (just add replicas), or when your main workload is heavy OLAP. TiDB ships a columnar engine called TiFlash for analytics, but for multi-year historical reporting, a dedicated warehouse will serve you better.
Trade-offs and operational costs
The protocol compatibility is the win. It is also the source of most of the surprises. A few honest limits are worth naming before you commit.
- Single-row latency is higher than MySQL on one host, because the query has to traverse the coordinator. For OLTP at thousands of writes per second the gap is small. For high-throughput tiny writes, plan to measure.
- Some MySQL features are partial: certain stored procedures, advanced SQL modes, and edge-case replication behaviors do not behave identically. Read the compatibility matrix before betting on a feature you depend on.
- Operating a distributed SQL database is more work than operating one MySQL host. TiUP reduces the friction, but you still own placement, scaling, backups, and rolling upgrades across multiple nodes.
- TiFlash handles hybrid OLTP/OLAP workloads well, but it is not a substitute for a proper warehouse. Use it for recent analytics, not for years of historical reporting.
How to try it without burning the weekend
The cheapest evaluation path is tiup playground on your laptop. Point your existing MySQL connection string at port 4000, run your test suite, and see what breaks. Most of the time, nothing breaks, and that is the actual point. If your application talks to MySQL cleanly today, it will talk to TiDB cleanly tomorrow. The only question left is whether the operational tradeoff is worth the horizontal scale you get in return.
Once the local check passes, the next step is a small production-shaped cluster on three or five nodes. TiUP handles the deploy, and you can run a representative write workload through the cluster to see the latency you actually get on real hardware. From there, the migration plan looks the same as any other database swap: replicate in, dual-write for a window, cut reads over, then cut writes. The wire-protocol compatibility means your application code does not change at any point in that plan, and that is the part that turns a six-month migration into a six-week one.