핵심 요약
- A single-node database runs out of runway when write throughput outgrows one machine, or when analytics start competing with production traffic.
- TiDB splits into four components that scale independently: a stateless SQL layer, PD, TiKV, and TiFlash.
- HTAP closes the OLTP/OLAP split, so a dashboard query and a checkout transaction hit the same live data.
- Migration runs as a four-step sequence with Dumpling, TiDB Lightning, and DM, and MySQL compatibility usually makes cutover a connection-string change.
A single-node relational database runs out of runway the moment write throughput outpaces what one machine can handle, or the moment analytics queries start competing with production traffic for the same resources. At that point, teams either shard manually, stand up a separate OLAP system and pipe data into it, or look for a database that does both without the extra moving parts. 티DB is a distributed SQL database built for that third option: it handles transactional and analytical workloads, known as Hybrid Transactional and Analytical Processing (HTAP), on the same cluster, while staying compatible with the MySQL protocol.
Where Traditional SQL Databases Run Out of Runway
Traditional SQL databases such as MySQL, PostgreSQL, and Oracle have run production workloads for decades. They provide strong ACID guarantees and mature tooling, which is why they remain the default choice for most new applications. The friction shows up later: horizontal scaling isn’t native to these systems, so growth past a single server’s capacity means manual sharding, read replicas, or a costly move to bigger hardware.
Architecture: Single-Node vs Distributed by Design
Traditional relational databases run as a single logical unit: one primary handles writes, and scaling means adding CPU, memory, or disk to that one machine. TiDB splits the system into four components that scale independently. The TiDB server is a stateless SQL layer that parses queries and builds execution plans. The Placement Driver (PD) manages cluster metadata and data placement. TiKV is a distributed, Raft-replicated key-value store that holds transactional data. TiFlash is a columnar engine that holds a real-time replica of the same data for analytical queries.
Because TiDB decouples storage from compute, you add TiKV or TiFlash nodes to scale capacity without touching the SQL layer. See the TiDB architecture diagram for the full component layout. TiDB also speaks the MySQL protocol, so most existing queries, ORMs, and drivers work against it without rewrites.
How TiDB Solves the OLTP/OLAP Split
The scaling problem that opens this piece has a second half. Once a team outgrows one database, they usually end up running two: an OLTP system for transactions and a separate OLAP warehouse for analytics, with an ETL pipeline between them that adds latency and one more thing to maintain.
TiDB’s HTAP design closes that gap directly. TiKV serves transactional reads and writes with row-based storage, while TiFlash keeps a columnar, real-time replica of the same tables. TiDB’s optimizer routes analytical queries to TiFlash automatically, so a dashboard query and a checkout transaction run against the same live data with no nightly batch job in between.
Migrating From a Traditional Database to TiDB
Moving an existing MySQL-compatible database to TiDB follows a repeatable sequence.
1. Export the schema and data with Dumpling, which also records the source database’s binlog position for the next step.
2. Bulk-load the export into TiDB with TiDB Lightning, which imports large datasets fast by writing key-value pairs straight to TiKV.
3. Replicate ongoing changes with TiDB Data Migration (DM), which reads the source binlog from the position Dumpling recorded and keeps TiDB in sync until cutover.
4. Cut over application traffic once replication lag reaches zero, then decommission the old database or keep it as a rollback target.
Because TiDB speaks the MySQL protocol, this sequence typically requires no query rewrites, only a connection-string change and validation against your existing test suite.
Real-World Result: MNC Bank
MNC Bank migrated its core transaction processing to TiDB and measured the result directly: 10x higher throughput, 50% lower latency, and 85% faster backups compared to its previous relational setup. Those gains trace back to the same architectural split described above. Horizontal scaling carries the throughput, HTAP handles latency-sensitive reporting, and distributed backups no longer lock a single primary.
When the Comparison Actually Matters
A single-node relational database is still the right call for many workloads. The decision point is whether you’re hitting a scaling ceiling, running analytics against production data, or planning ahead for either.
TiDB’s MySQL compatibility means testing that decision costs you no rewrite. Start with a free TiDB Cloud Starter cluster and run your own schema against it before committing to a migration.
TiDB vs Traditional SQL FAQs
What Is the Main Difference Between TiDB and a Traditional SQL Database?
TiDB scales horizontally by adding nodes, where traditional SQL databases scale vertically on a single machine. It also separates storage (TiKV, TiFlash) from the SQL layer, so each scales independently. And it runs OLTP and OLAP on one cluster through HTAP, where most traditional databases need a separate analytics system.
Can I Run TiDB With My Existing MySQL Application Without Rewriting Queries?
Usually. TiDB implements the MySQL wire protocol, so existing drivers and ORMs connect without changes, and most standard SQL and MySQL syntax runs unmodified. Some MySQL-specific features have partial support or none, including stored procedures. Check the MySQL compatibility docs before migrating.
Does TiDB Support HTAP Without a Separate Analytics Database?
Yes. TiFlash holds a real-time columnar replica of TiKV’s data, and the query optimizer routes analytical queries to TiFlash automatically. Keeping analytics current needs no ETL pipeline and no nightly batch job.
How Long Does Migrating From a Traditional Database to TiDB Typically Take?
Small datasets can move in hours using Dumpling and TiDB Lightning alone. Larger datasets typically use Lightning’s physical import mode (backend = local) for the bulk load, then DM for incremental sync. Total timeline usually depends more on validation and cutover planning than on the data transfer itself.