101
0/273
Loading content...
Database selection is one of the most consequential architectural decisions you'll make. The wrong choice can mean years of painful migrations, performance problems, or unnecessary complexity. The right choice provides a foundation that scales with your business.
TiDB is a powerful database, but it's not the right choice for every scenario. Like any technology, it has sweet spots where it excels and anti-patterns where alternatives are better suited.
In this page, we'll develop a rigorous framework for evaluating TiDB. We'll examine:
The goal isn't to convince you to use TiDB—it's to help you make an informed decision.
By the end of this page, you will have a clear decision framework for evaluating TiDB, understand the specific characteristics that make TiDB the right (or wrong) choice, and be able to articulate the tradeoffs to stakeholders with confidence.
TiDB excels in specific scenarios where its architecture provides clear advantages over alternatives. Let's examine these sweet spots in detail.
1. MySQL at Scale:
This is TiDB's core value proposition. If you have:
TiDB is often the strongest choice because:
Real-world signal: You're discussing or implementing application-level sharding, and your team is dreading the complexity.
2. Hybrid OLTP/OLAP Requirements:
If you need:
TiDB's HTAP capability (TiFlash) provides unique value:
Real-world signal: You're maintaining both a MySQL database and a data warehouse (Redshift, Snowflake, BigQuery) for analytics on the same data.
| Scenario | Indicator | TiDB Advantage | Alternative Risk |
|---|---|---|---|
| MySQL at Scale | Sharding discussions | Transparent horizontal scaling | Years of sharding complexity |
| HTAP Requirements | ETL to data warehouse | Real-time analytics, no ETL | Stale data, pipeline maintenance |
| Cross-Region Transactions | Multi-DC requirements | Distributed transactions | Complex custom solutions |
| High Availability | 99.99%+ uptime needed | Automatic failover via Raft | Manual failover procedures |
| Growing Fast | 10x growth in 2 years | Scale-out architecture | Repeated painful migrations |
3. Predictable Scaling Path:
If your organization:
TiDB's architecture means you can start small and grow:
Real-world signal: You've migrated databases multiple times as you've grown, and you want to stop.
4. Strong Consistency with High Availability:
If you need:
TiDB's Raft-based replication provides:
Real-world signal: You're designing for financial transactions, inventory systems, or anything where consistency is non-negotiable.
If you're currently on MySQL and hitting limits, TiDB is often the path of least resistance. The MySQL compatibility means most applications work with minimal changes, and your team's MySQL expertise transfers directly. This is TiDB's strongest competitive advantage.
TiDB isn't the right choice for every scenario. Understanding when alternatives are better helps you avoid costly mismatches between technology and requirements.
1. Small-Scale Workloads:
If your data is:
Consider instead: Vanilla MySQL or PostgreSQL
Why: TiDB's distributed architecture adds operational complexity. If you don't need distributed features, the simpler option is better. A well-tuned single-node MySQL can handle significant workloads.
Threshold consideration: TiDB becomes compelling when single-node databases require complex optimizations to keep up, or when you're considering sharding.
2. Latency-Critical Workloads:
If you need:
Consider instead: Single-node databases, Redis, or specialized solutions
Why: TiDB's distributed architecture adds latency overhead. Even fast operations require network round-trips to TiKV. For most applications (10-50ms is fine), this is not an issue. For extreme latency requirements, it matters.
| Scenario | TiDB Limitation | Better Alternative | Reasoning |
|---|---|---|---|
| Small datasets (<100GB) | Operational complexity not justified | MySQL, PostgreSQL | Simpler is better when scale isn't needed |
| Sub-ms latency required | Distributed overhead | Single-node DB, Redis | Eliminate network hops |
| Heavy PostgreSQL usage | MySQL compatibility, not PostgreSQL | CockroachDB, Citus | Direct PostgreSQL compatibility |
| Pure analytics (no OLTP) | HTAP complexity | ClickHouse, BigQuery | Purpose-built OLAP |
| Document-centric data | Relational model | MongoDB, DynamoDB | Native document model |
| Extreme write volume only | Raft overhead | Cassandra, ScyllaDB | Write-optimized architecture |
3. PostgreSQL Ecosystem:
If you're:
Consider instead: CockroachDB (PostgreSQL wire protocol), Citus (PostgreSQL extension), Aurora PostgreSQL
Why: TiDB is MySQL-compatible, not PostgreSQL-compatible. While SQL is similar, the ecosystems differ. If you're committed to PostgreSQL, a PostgreSQL-compatible option is more natural.
4. Pure Analytics (No OLTP):
If you:
Consider instead: ClickHouse, Snowflake, BigQuery, Databricks
Why: TiDB's HTAP is powerful when you need both OLTP and OLAP. If you only need OLAP, purpose-built analytics databases are more efficient and often more cost-effective.
5. Write-Heavy Without Transactions:
If you:
Consider instead: Cassandra, ScyllaDB, DynamoDB
Why: TiDB's Raft-based replication ensures consistency but adds write latency. For write-only workloads where eventual consistency is acceptable, leaderless databases can achieve higher throughput.
Distributed databases are more complex to operate than single-node databases. If you don't need distributed features, that complexity is pure overhead. Be honest about whether your scale justifies distribution.
Let's compare TiDB directly against common alternatives across specific dimensions.
TiDB vs MySQL (Single-Node):
| Dimension | MySQL (Single-Node) | TiDB | Winner |
|---|---|---|---|
| Simplicity | Simple to operate | Distributed complexity | MySQL |
| Scalability | Limited to single node | Horizontal scaling | TiDB |
| High Availability | Requires setup (replication, failover) | Built-in via Raft | TiDB |
| Latency | Lower (local operations) | Higher (distributed) | MySQL |
| Cost (small scale) | Lower | Higher (more nodes) | MySQL |
| Cost (large scale) | Expensive instances + sharding overhead | Linear scaling | TiDB |
| Analytics | Limited | TiFlash HTAP | TiDB |
Bottom line: Use MySQL when single-node is sufficient. Migrate to TiDB when MySQL limits your growth or you need HTAP.
TiDB vs CockroachDB:
| Dimension | CockroachDB | TiDB | Winner |
|---|---|---|---|
| SQL Compatibility | PostgreSQL | MySQL | Depends on your stack |
| Distributed Transactions | Excellent | Excellent | Tie |
| HTAP Capability | Limited | TiFlash | TiDB |
| Geo-Partitioning | Strong | Improving | CockroachDB |
| Cloud-Native | Designed for K8s | Supports K8s | CockroachDB (slightly) |
| Community Size | Smaller | Large (especially Asia) | TiDB |
| Managed Options | Cockroach Cloud | TiDB Cloud | Tie |
Bottom line: Choose based on compatibility (MySQL vs PostgreSQL) and analytics needs (TiDB wins for HTAP).
TiDB vs Aurora MySQL:
| Dimension | Aurora MySQL | TiDB | Winner |
|---|---|---|---|
| MySQL Compatibility | Very high | High (some differences) | Aurora (slightly) |
| Managed Service | Fully managed by AWS | TiDB Cloud or self-managed | Aurora (if AWS-only) |
| Scaling Writes | Single writer instance | Horizontal write scaling | TiDB |
| Read Replicas | Up to 15 read replicas | Unlimited TiKV nodes | TiDB |
| Cost at Scale | Expensive at large scale | More predictable | TiDB |
| HTAP | Limited | TiFlash | TiDB |
| Multi-Cloud | AWS only | Any cloud or on-prem | TiDB |
Bottom line: Aurora is great for AWS-native, moderate-scale MySQL workloads. TiDB wins for horizontal write scaling, HTAP, and multi-cloud requirements.
TiDB vs Vitess:
| Dimension | Vitess | TiDB | Winner |
|---|---|---|---|
| Architecture | MySQL sharding layer | Native distributed DB | Different approaches |
| Underlying DB | Actual MySQL instances | TiKV (new storage) | Depends on needs |
| Cross-Shard Queries | Limited | Full support | TiDB |
| Transactions | Limited across shards | Distributed transactions | TiDB |
| MySQL Feature Support | Full MySQL | Most MySQL | Vitess |
| Operational Complexity | High (managing MySQL fleet) | Lower (unified system) | TiDB |
Bottom line: Vitess is appropriate if you need exact MySQL compatibility and can live with sharding limitations. TiDB provides easier cross-shard operations and distributed transactions.
Every database has tradeoffs. The best choice depends on your specific requirements, existing investments, and team expertise. Don't chase theoretical perfection—choose the practical right fit for your situation.
Before committing to TiDB, systematically evaluate your readiness. This checklist covers the key areas to assess.
1. Compatibility Assessment:
COMPATIBILITY CHECKLIST════════════════════════════════════════════════════════════════════ □ SQL SYNTAX REVIEW ├── Run application queries against TiDB test cluster ├── Check for MySQL-specific syntax not supported ├── Review stored procedures (consider alternatives) └── Test EXPLAIN plans for critical queries □ DATA TYPE VERIFICATION ├── Review use of unsigned integers ├── Check ENUM/SET usage ├── Verify JSON operations └── Test spatial data (if used) □ TRANSACTION PATTERNS ├── Review transaction sizes (TiDB limits ~100MB default) ├── Check for xa transactions (not supported) ├── Test pessimistic vs optimistic mode └── Verify isolation level requirements □ AUTO_INCREMENT BEHAVIOR ├── Identify code relying on sequential IDs ├── Plan for AUTO_RANDOM if needed └── Update ordering logic if based on ID □ FEATURE USAGE ├── Stored procedures: Plan application-layer alternatives ├── Triggers: Implement in application layer ├── Events/Scheduler: Move to external scheduler └── Full-text search: Evaluate TiDB support or external (ES)2. Operational Readiness:
3. Performance Validation:
Before migration, establish a performance baseline and validate TiDB meets requirements:
1234567891011121314151617181920212223242526272829303132333435
-- 1. Establish current MySQL baseline-- Capture slow query log, identify top queries -- 2. Set up TiDB test cluster with production-like data-- Use TiDB Data Migration (DM) to sync from MySQL -- 3. Run representative queries and compare -- Critical read pathEXPLAIN ANALYZESELECT * FROM users WHERE id = 12345;-- Compare execution time vs MySQL -- Critical write pathBEGIN;INSERT INTO orders (...) VALUES (...);INSERT INTO order_items (...) VALUES (...);COMMIT;-- Measure distributed transaction overhead -- Analytical queries (TiFlash)EXPLAIN ANALYZESELECT customer_id, SUM(amount) FROM orders WHERE created_at >= '2024-01-01'GROUP BY customer_id;-- Verify TiFlash is used and performance is acceptable -- Concurrent transaction test-- Use sysbench or custom load generator-- Measure p99 latency, throughput at expected load -- 4. Hotspot detectionSELECT * FROM information_schema.tidb_hot_regions;-- Identify potential hot regions before production4. Risk Mitigation:
Development and staging environments often don't reveal issues that appear at production scale. Use production data volumes and traffic patterns for validation. Synthetic benchmarks can be misleading.
Let's examine how real organizations have approached the TiDB decision, applying the framework we've discussed.
Example 1: E-Commerce Platform (✓ Chose TiDB)
Situation:
Decision Factors:
Result:
DECISION PATTERN: E-Commerce (Chose TiDB)════════════════════════════════════════════════════════════════════ BEFORE (MySQL Sharded) AFTER (TiDB)───────────────────────────────────────────────────────────────── Application Layer Application Layer │ │ ▼ ▼┌─────────────────┐ ┌─────────────────┐│ Shard Router │ │ Load Balancer ││ (Custom Logic) │ │ (Standard) │└────────┬────────┘ └────────┬────────┘ │ │ ┌─────┴─────┬─────────┐ ┌───────┴───────┐ ▼ ▼ ▼ ▼ ▼┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐│MySQL │ │MySQL │...│MySQL │ │ TiDB │ │ TiDB ││Shard1│ │Shard2│ │Shard50│ │Server│ │Server│└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │ │ │ │ │ └────────────────────┘ └───────┬───────┘ │ ▼ Cannot join across shards ┌─────────────────────┐ Complex routing logic │ TiKV Cluster │ Each shard = maintenance │ (Automatic Dist) │ └─────────────────────┘ │ ▼ ┌─────────────────────┐ ETL Pipeline (nightly) ────► │ TiFlash (HTAP) │ to Data Warehouse ELIMINATED │ (Real-time) │ └─────────────────────┘Example 2: SaaS Analytics Platform (✗ Chose ClickHouse Instead)
Situation:
Decision Factors:
Result:
Example 3: Financial Services (✓ Chose TiDB)
Situation:
Decision Factors:
Result:
Example 4: Mobile Gaming Backend (✗ Chose Cassandra Instead)
Situation:
Decision Factors:
Result:
Notice how each decision maps back to the framework: workload characteristics (OLTP, OLAP, write-heavy), consistency requirements (strong, eventual), existing investments (MySQL expertise), and scale requirements (current and projected). Apply this same pattern to your decisions.
Let's synthesize everything into a practical decision framework you can apply.
Step 1: Assess Your Current State
TIDB DECISION FRAMEWORK════════════════════════════════════════════════════════════════════ STEP 1: CURRENT STATE ASSESSMENT───────────────────────────────────────── Questions to answer:□ What database(s) do you use today? → MySQL? PostgreSQL? Something else? → TiDB advantage is strongest for MySQL shops □ What is your current data size and growth rate? → <100GB and stable? → Single-node probably fine → >1TB or growing 50%+/year? → Distributed worth considering □ Are you hitting limits today? → Sharding discussions? → Strong TiDB signal → Performance issues? → May be solved with tuning first → High availability gaps? → TiDB helps □ What is your consistency requirement? → Strong (financial, inventory)? → TiDB appropriate → Eventual acceptable? → More options available STEP 2: WORKLOAD ANALYSIS───────────────────────────────────────── Categorize your workload: OLTP Only (transactions, low latency):├── MySQL is sufficient for scale? → Stay├── Need horizontal scaling? → TiDB└── PostgreSQL ecosystem? → CockroachDB OLAP Only (analytics, aggregations):├── No OLTP component? → ClickHouse, Snowflake, BigQuery└── Not worth HTAP complexity for pure analytics HTAP (both workloads on same data):└── Strong TiDB signal → TiFlash provides unique value STEP 3: EVALUATE FIT───────────────────────────────────────── ┌─────────────────────────────────────────┐ │ START HERE │ └────────────────┬────────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Are you hitting MySQL/PG limits? │ └────────────────┬────────────────────────┘ │ ┌────────────┴────────────┐ │ │ ▼ NO ▼ YES ┌──────────────────┐ ┌──────────────────────┐ │ Single-node is │ │ Do you need HTAP? │ │ probably fine. │ │ (analytics on live │ │ Consider TiDB │ │ transactional data) │ │ when limits hit. │ └──────────┬───────────┘ └──────────────────┘ │ ┌────┴────┐ │ │ ▼ YES ▼ NO ┌─────────────┐ ┌─────────────────┐ │ TiDB is │ │ MySQL stack? │ │ strong │ │ → TiDB │ │ choice │ │ PostgreSQL? │ │ (TiFlash) │ │ → CockroachDB │ └─────────────┘ └─────────────────┘ STEP 4: VALIDATE───────────────────────────────────────── □ Run compatibility analysis on your SQL□ Benchmark with production-like data□ Train team on TiDB operations□ Plan migration strategy (gradual recommended)□ Establish rollback capabilityThe best database is the one that fits your requirements with minimal complexity. TiDB has impressive features, but features you don't need are overhead. Choose based on your actual needs, not theoretical capabilities.
We've explored TiDB comprehensively—from MySQL compatibility to horizontal scalability, HTAP capabilities, and now the decision framework for when to use it. Let's consolidate the key insights:
TiDB is a Strong Choice When:
Consider Alternatives When:
Final Thought:
Database selection is a consequential decision, but it's not irreversible. Many organizations start with simpler solutions and migrate when they outgrow them. The key is making an informed choice based on current requirements while understanding the migration path.
TiDB provides a powerful option for organizations that need MySQL-compatible distributed SQL with real-time analytics. For those organizations, it can be transformative. For others, it may be the right choice in the future—but not today.
Make the decision that's right for your situation, with your eyes open to both the benefits and the costs.
You've completed the TiDB module! You now understand TiDB's MySQL compatibility, horizontal scalability architecture, HTAP capabilities with TiFlash, and have a framework for evaluating whether TiDB is the right choice for your system. Use this knowledge to make informed database decisions that will scale with your organization.