Who TiDB is for#
SaaS teams outgrowing one MySQL primary
Use TiDB when transactional data needs to scale horizontally without a full application rewrite.
Skip if:
Your database fits comfortably on one managed PostgreSQL or MySQL instance.
Teams combining transactional and analytical queries
Run operational queries and analytical workloads closer together when a separate warehouse adds too much latency or complexity.
Skip if:
You only need a managed warehouse for offline analytics.
The problem it solves#
Traditional single-node databases become hard to scale when data growth, regional availability, and analytics pressure arrive at the same time. Teams either shard manually, split transactional and analytical systems, or buy a managed distributed database that limits infrastructure control.
How it solves it#
Distributed SQL with ACID transactions
TiDB uses distributed transaction protocols to keep SQL consistency across nodes, making it suitable for workloads that outgrow one primary database server.
Horizontal scale without downtime
The architecture separates compute and storage, so teams can add nodes or resize resources as traffic grows.
HTAP and MySQL compatibility
TiDB targets both transactional and analytical workloads while preserving a MySQL-compatible SQL surface for many applications.
Strengths and trade-offs#
Strengths
- MySQL-compatible distributed scaleTiDB is attractive when teams want distributed SQL behavior without abandoning the MySQL ecosystem.
- One platform for transactions and analyticsHTAP positioning helps teams avoid immediately splitting operational and analytical data into separate systems.
Trade-offs
- -Operationally more complex than managed databasesRunning TiDB means understanding placement, storage, PD, TiKV, upgrades, and observability.
- -Not needed for ordinary app databasesA standard PostgreSQL or MySQL deployment is simpler if the workload does not require distributed scale.
TiDB vs alternatives#
TiDB vs Aurora and Spanner
TiDB is better when teams need MySQL-compatible distributed SQL with self-hosting and HTAP capabilities. Aurora is easier for managed MySQL or PostgreSQL scaling inside AWS, while Spanner is stronger for globally managed consistency with Google Cloud operations. TiDB fits teams that want distributed SQL control without abandoning familiar SQL patterns.
Install and self-host#
```bash curl --proto =https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh && tiup playground ```What it's built on#
- Languages
- Go
- Databases
- MySQL
FAQ#
Is TiDB compatible with MySQL?
TiDB provides a MySQL-compatible SQL interface, which helps teams migrate applications that already use MySQL patterns.
Can TiDB replace Aurora?
TiDB can replace Aurora when distributed SQL, self-hosting, or HTAP behavior matter more than AWS-managed convenience. Aurora is simpler for managed relational workloads inside AWS.
What is TiKV in TiDB?
TiKV is the distributed key-value storage layer used by TiDB. It works with TiDB and placement driver components to provide distributed storage and coordination.
Similar open-source tools#
YugabyteDB
Open source distributed SQL database for cloud-native apps
ClickHouse
Fast open source column-oriented database for analytics
Trino
High-performance distributed SQL query engine for big data
DBeaver
Free open-source database management tool for SQL databases.
ThingsBoard
Open source IoT platform for device management and dashboards
MindsDB
Delegate reports, inbox cleanup, and workflow tasks to an AI agent