TiDB

Distributed database infrastructure, honestly reviewed. No marketing fluff — just what you’re actually signing up for when you deploy TiDB.

TL;DR

• What it is: Open-source (Apache 2.0) distributed SQL database from PingCAP — MySQL-compatible, horizontally scalable, designed for workloads that have outgrown a single MySQL or MariaDB instance [README].
• Who it’s for: Engineering teams at companies that are hitting hard write-scaling ceilings on MySQL — think 10TB+ databases, billions of rows, multi-hundred-thousand QPS peaks. Not a tool for non-technical founders. This is infrastructure for engineers [1][4].
• Cost savings: The self-hosted tier is free. The comparison isn’t really Zapier-style SaaS pricing — it’s “pay for a few VMs instead of paying Amazon Aurora or CockroachDB’s cloud margins” [4][README].
• Key strength: MySQL protocol compatibility is genuine. A 25TB Bling/LWSA production migration worked “almost immediately without extensive rewrites” — their engineer spun up a local cluster on a Saturday and it connected to their existing application [1].
• Key weakness: This is not a database you hand to a non-technical person. Deployment requires Kubernetes fluency or significant Linux infrastructure experience. The operational surface area is large [README][1].

---

What is TiDB

TiDB (pronounced “tie-dee-bee” — “Ti” for Titanium) is an open-source distributed SQL database built by PingCAP. The GitHub repository sits at 39,885 stars under an Apache 2.0 license, written in Go [README].

The core pitch: MySQL compatibility combined with horizontal scalability that a monolithic MySQL instance can never provide. You connect to TiDB with the same MySQL wire protocol, use the same ORM, run the same SQL — but underneath, data is distributed across a cluster of nodes using the Raft consensus protocol, and you can add capacity by adding nodes rather than upgrading to a bigger single machine [README].

TiDB’s architecture separates compute from storage. The TiDB server layer handles SQL parsing and query planning. TiKV handles row-based storage. TiFlash is a separate columnar engine that replicates from TiKV in real time, enabling analytical queries on live transactional data without ETL — what PingCAP calls HTAP (Hybrid Transactional/Analytical Processing) [README].

The project is backed by PingCAP, a funded company (Series D) that runs TiDB Cloud as their managed SaaS offering. The open-source core is genuinely Apache 2.0 — no “Fair-code” restrictions, no commercial use limitations [README].

Companies using TiDB in production include LinkedIn, Pinterest, Square, and Databricks [homepage]. The Databricks quote is worth noting: “We chose TiDB for two reasons. Firstly, it is 99% compatible with MySQL, which reduced our overhead with migration. Second, is the scalability.” [homepage]

---

Why people choose it

The most instructive data point comes from Bling (part of LWSA Group), a Brazilian SaaS ERP with 300,000 daily active users [1]. Their situation before TiDB:

• 25TB per database instance, tables with 2–5 billion rows
• 15 replicas (8 full, 7 partial) managing peaks of 350,000 QPS
• MariaDB instances running 190 vCPUs and 1TB RAM — and still struggling
• Schema changes on large tables taking over 50 hours using online tools like gh-ost

They evaluated Amazon Aurora first: ruled out because it can’t scale writes horizontally — the exact bottleneck they needed to solve. They invested six months on Vitess before walking away from it: required disruptive data model changes, significant application rewrites, eventual consistency risks, and no clean rollback path to standard MySQL [1].

The TiDB decision happened differently. An engineer, frustrated with Vitess’s complexity, spun up a TiDB cluster on a weekend. Connected the existing application. It worked. No rewrites [1]. That’s the repeating pattern in TiDB adoption stories: MySQL compatibility isn’t marketing copy, it’s an actual migration lever.

From the CockroachDB migration context [4], companies also land on TiDB when leaving distributed SQL platforms that have become too expensive or too operationally complex. TiDB sits in a category that also includes YugabyteDB and CockroachDB — all three offer distributed SQL with horizontal scaling — but TiDB is the only one in that group with MySQL (not PostgreSQL) compatibility as its primary interface, which matters enormously for MySQL shops [4].

---

Features

Core distributed SQL:

• MySQL 8.0 protocol compatibility — existing apps typically connect without code changes [README][1]
• ACID transactions via two-phase commit across distributed nodes — strong consistency, not eventual [README]
• Horizontal scaling by adding TiKV nodes; vertical scaling by resizing existing nodes; compute and storage scale independently [README]
• Raft consensus for high availability — data stored in multiple replicas, automated failover, geographic replica placement for disaster tolerance [README]
• No manual sharding — the system handles data distribution transparently [homepage]

HTAP (hybrid workloads):

• TiKV: row-based storage for OLTP workloads [README]
• TiFlash: columnar storage that replicates from TiKV in real time via Multi-Raft Learner protocol [README]
• Run analytical queries on live transactional data without building a separate ETL pipeline [README]
• TiDB Server coordinates query routing across TiKV and TiFlash automatically [README]

Deployment and operations:

• TiUP: the CLI tool for local testing and cluster management [README]
• TiDB Operator: Kubernetes operator for production deployments [README]
• TiDB Cloud: fully-managed SaaS with a free tier, no credit card required [README]
• Point-in-time recovery (PITR), automated backups [homepage]
• Request Unit (RU)-based autoscaling — no manual capacity planning on the serverless tier [homepage]

Security (Cloud Dedicated):

• Customer-Managed Encryption Keys (CMEK) — your own AWS KMS or Azure Key Vault key controls data at rest [2]
• Data encrypted using your key; backups encrypted with the same key [2]
• If you revoke the key, data becomes inaccessible — full tenant control [2]

Data migration tooling:

• DM (Data Migration): replicates from MySQL/MariaDB to TiDB
• TiCDC: change data capture for downstream consumers
• Physical import mode for large datasets — up to 110 MiB/s migration speed on Google Cloud [3]

---

Pricing: SaaS vs self-hosted math

TiDB Cloud tiers (their managed SaaS):

• Serverless / Starter: Free tier, no credit card. Shared infrastructure, suitable for development and small workloads [homepage]
• Flex (usage-based): Consumption pricing per Request Unit and storage — exact per-RU rates not published in standard flat-fee format; billed by actual compute consumed [homepage]
• Dedicated: Dedicated infrastructure, private networking, higher SLAs. Enterprise pricing [homepage]

The pricing model is consumption-based on the serverless tier, not a flat monthly fee — closer to how DynamoDB or Firestore bill than how a traditional database subscription works.

Self-hosted (Community / Self-Managed):

• Software license: $0 (Apache 2.0) [README]
• Infrastructure: a TiDB production cluster realistically needs 3+ TiKV nodes (for Raft quorum) plus TiDB server nodes plus a PD (Placement Driver) node. Minimum viable production: 6–9 VMs. On Hetzner or Contabo that’s $30–80/month in infrastructure
• Kubernetes management overhead if you use TiDB Operator
• Optional: consulting from certified PingCAP partners (Mydbops and similar firms charge per engagement) [5]

Comparison framing:

The relevant cost comparison isn’t against Zapier — it’s against what you’d pay for equivalent managed database capacity:

• Amazon Aurora MySQL at 25TB scale with high QPS: easily $2,000–$10,000+/month depending on instance sizes and read replicas
• CockroachDB Cloud: $0.095/vCPU-hour on serverless, scales fast at high QPS
• TiDB self-hosted at 25TB scale: the Bling team was running 190-vCPU MariaDB instances — equivalent bare metal or VMs cost significantly less than managed Aurora at the same resource level, with the added benefit of horizontal scaling rather than vertical limits [1]

For smaller teams: TiDB Cloud’s free tier covers development and low-traffic production. You’re not paying until you need dedicated or high-RU workloads.

---

Deployment reality check

This is not a weekend side-project database. Honest assessment of what deploying TiDB self-hosted requires:

For local testing:

• tiup playground spins up a single-node cluster in minutes [README]
• Suitable for development, not production

For production on Kubernetes:

• TiDB Operator automates cluster management — rolling upgrades, scaling, backup scheduling [README]
• Minimum topology: 3 PD nodes, 3 TiKV nodes, 2+ TiDB server nodes
• Persistent volumes, network policies, resource limits all need configuration
• If you’ve never run a stateful workload on Kubernetes, budget weeks not hours

For production without Kubernetes:

• TiUP cluster management works on bare Linux
• Still requires careful topology planning, firewall rules between components, and monitoring setup
• The Bling team had a dedicated engineering team handling the migration [1]

What can go sideways:

• TiFlash (the columnar engine for analytics) adds another layer of operational complexity — it’s a separate process that needs its own storage and resource allocation
• Schema changes at 10TB+ scale, while better than MySQL’s 50-hour gh-ost runs, still require care
• The Raft quorum requirement means you need an odd number of TiKV replicas for proper HA — under-provisioning here leaves you with no actual failover guarantee
• Consulting firms like Mydbops exist precisely because self-managed TiDB at scale is not trivial — they position their certified PingCAP engineers as a service for a reason [5]

TiDB Cloud as an escape hatch: For teams that want the TiDB capabilities without the operational burden, the managed Cloud offering handles all of this. The free tier genuinely requires no credit card [README]. The trade-off is that you’re back to a SaaS dependency — though with a vendor who has an Apache 2.0 open-source escape valve if pricing becomes problematic.

Realistic time to production for a team with Kubernetes experience: 1–2 weeks including topology design, testing, and migration dry runs. For a team without Kubernetes experience: budget a month or hire someone who has done it before.

---

Pros and Cons

Pros

• Apache 2.0 license, full stop. Not “fair-code,” not “source-available,” not “community edition with commercial restrictions.” Apache 2.0 means you can embed it, fork it, resell it, build products on top of it [README]. This matters if you’re building infrastructure products.
• MySQL compatibility is real. The Bling case study — 25TB, 350K QPS, works without app rewrites — is the strongest evidence available. This isn’t checkbox compatibility [1].
• HTAP eliminates a common data pipeline. Running analytical queries on live transactional data from TiFlash removes the need to build a separate ETL from OLTP to analytics storage. This is a genuine architectural simplification [README].
• Horizontal write scaling. Adding TiKV nodes distributes write load. Aurora, RDS, and standard MySQL replicas can only scale reads this way — writes always funnel to one primary [1][4].
• Strong consistency across distributed transactions. Unlike Vitess (which Bling rejected due to eventual consistency risks), TiDB maintains ACID guarantees across distributed nodes [1][README].
• 39,885 GitHub stars. This is a mature, heavily-used project with active development, not an experimental tool [README].
• Free tier on TiDB Cloud. Real clusters for development with no credit card [README].
• CMEK support. Full customer-managed encryption key control on Cloud Dedicated — AWS KMS and Azure Key Vault [2].

Cons

• Not a tool for non-technical teams. If you don’t have engineers who understand database internals, replication, and distributed systems, this is the wrong choice. The operational surface area is large. [README][1]
• Minimum production cluster is 6–9 nodes. You cannot run TiDB in production meaningfully on a single VPS. The Raft quorum requirement means 3 TiKV replicas minimum. This is legitimate infrastructure, with legitimate infrastructure costs.
• MySQL compatibility has gaps. The README says “99% compatible” — but that 1% surfaces in specific SQL features, stored procedures with certain patterns, and edge cases in large-scale deployments. Not a blocker for most apps, but budget time to find where the gaps are.
• TiFlash adds complexity. If you want the HTAP capabilities, you’re managing a second storage engine, second resource allocation, and second set of operational concerns. You can ignore it, but then you’re not getting a key differentiator.
• Kubernetes expertise required for production. TiDB Operator is the production deployment path. If your team doesn’t run Kubernetes, you’re either learning it or using TiDB Cloud.
• No community-edition equivalent of TiDB Cloud’s CMEK, branching, or enterprise features. These are cloud-only or enterprise-licensed.
• Consulting market exists for a reason. The existence of PingCAP-certified consulting firms [5] is a signal that production TiDB is non-trivial to operate correctly.

---

Who should use this / who shouldn’t

Use TiDB if:

• You’re running MySQL or MariaDB and you’re hitting write-scaling limits — schema changes taking hours, replication lag under write load, single-instance CPU or I/O saturation.
• Your table sizes are in the billions of rows or your database is measured in terabytes.
• You need HTAP: analytical queries on live transactional data without a separate data warehouse pipeline.
• You want Apache 2.0 licensing — not fair-code, not source-available — for a distributed SQL database you can embed or build products on.
• You have Kubernetes engineers on your team, or you’re comfortable with TiDB Cloud managed.
• You need to escape CockroachDB pricing while keeping distributed SQL capabilities [4].

Skip it (stay on managed MySQL/PostgreSQL) if:

• Your database is under 1TB and your write QPS is comfortable on a single instance.
• You don’t have engineers who can operate distributed database infrastructure.
• You need a database this week — the migration and operational learning curve is measured in weeks, not hours.

Skip it (use PostgreSQL) if:

• You need PostgreSQL-specific features (JSONB, full-text search, PostGIS, logical replication to specific consumers).
• Your stack is already deep in the PostgreSQL ecosystem.

Skip it (use YugabyteDB) if:

• You’re on PostgreSQL and need horizontal scaling — YugabyteDB is the MySQL-to-PostgreSQL equivalent in the distributed SQL space [4].

Skip it (use TiDB Cloud) if:

• You want TiDB capabilities without the operational burden. The free tier removes the deployment barrier entirely.

---

Alternatives worth considering

• YugabyteDB — PostgreSQL-compatible distributed SQL. Architectural peer to TiDB, different protocol surface (PostgreSQL vs. MySQL). Open core with enterprise options [4].
• CockroachDB — PostgreSQL-compatible distributed SQL. Strong on multi-region consistency. Pricing at scale is a known reason companies leave it; TiDB is explicitly on the list of alternatives they evaluate [4].
• Amazon Aurora (MySQL) — fully managed, MySQL-compatible, significantly better than RDS. But: no horizontal write scaling, tightly coupled to AWS, costs grow fast at scale [1].
• Vitess — MySQL sharding layer, not a new database. More surgical than TiDB — you keep MySQL under the hood. The Bling team rejected it due to required application rewrites and eventual consistency trade-offs [1]. Worth evaluating if you want to stay on MySQL storage precisely.
• Google Cloud Spanner — global scale, strong consistency, fully managed. Proprietary, expensive, Google Cloud lock-in. For enterprises already committed to GCP infrastructure [4].
• PostgreSQL (self-managed) — mature, reliable, massive ecosystem. For teams that conclude they don’t actually need distributed SQL and want to simplify [4].
• PlanetScale — MySQL-compatible serverless database built on Vitess. Good for smaller-scale MySQL workloads that need branching and schema management; less suited for the 25TB OLTP use case TiDB targets.

For an engineering team hitting MySQL scaling limits, the realistic shortlist is TiDB vs. Vitess vs. Aurora. TiDB if you want to eliminate the application layer complexity of sharding. Vitess if you want to preserve MySQL storage exactly. Aurora if you want AWS to manage everything and you’re not hitting write-scaling ceilings.

---

Bottom line

TiDB is a serious distributed database that solves a real problem: what do you do when a single MySQL instance can’t keep up, and you don’t want to rewrite your application? The MySQL compatibility story is genuine — the Bling case study at 25TB, 350K QPS, working without code changes is a concrete data point, not marketing [1]. The Apache 2.0 license is a genuine differentiator from CockroachDB and the “fair-code” alternatives. The HTAP capabilities, if you need them, eliminate an architectural layer that most growing data teams end up building eventually.

The honest caveat: this is not a tool that belongs in the “escape expensive SaaS” category for a non-technical founder. It belongs in the “escape expensive cloud database bills” category for an engineering team that has outgrown MySQL and needs horizontal write scaling without a full rewrite. If that’s your problem — and it’s a very specific, very painful problem when you have it — TiDB is one of the strongest open-source options available. If it’s not your problem, there are simpler databases that will serve you better.

---

Sources

1. PingCAP Blog — MySQL to TiDB Migration: How Bling Scaled a 25TB Database. https://www.pingcap.com/blog/mysql-to-tidb-migration-how-bling-scaled-25tb-database/
2. TiDB Docs — Encryption at Rest Using Customer-Managed Encryption Keys on Azure. https://docs.pingcap.com/tidbcloud/tidb-cloud-encrypt-cmek-azure/
3. TiDB Docs — TiDB Cloud Release Notes in 2023. https://docs.pingcap.com/tidbcloud/release-notes-2023/
4. 85ideas.com — 6 Platforms Companies Explore When Moving Away From CockroachDB. https://85ideas.com/blog/6-platforms-companies-explore-when-moving-away-from-cockroachdb/
5. Mydbops — TiDB Consulting Services. https://www.mydbops.com/tidb/consulting-service

Primary sources:

• GitHub repository and README: https://github.com/pingcap/tidb (39,885 stars, Apache 2.0 license)
• Official website and homepage: https://www.pingcap.com
• TiDB Cloud pricing: https://tidbcloud.com/pricing