An e-commerce platform hit the wall at 200M orders — single-node MySQL could no longer handle their HTAP workload (real-time analytics alongside OLTP) without affecting transaction latency. After evaluating CockroachDB and YugabyteDB, they chose TiDB 8.0. Analytics queries that previously caused 400ms OLTP latency spikes now run in isolation on TiFlash replicas.
TiDB 8.0 is a meaningful maturity milestone: stronger MySQL compatibility, Resource Group isolation, improved TiFlash performance, and better operational tooling. This guide covers when TiDB 8.0 is the right choice and how to deploy it.
- TiDB 8.0 achieves ~99.9% MySQL 8.0 syntax compatibility — most applications work without code changes.
- TiFlash columnar replicas provide HTAP: run analytics without separate ETL pipelines.
- Resource Groups in 8.0 isolate OLTP and analytics workloads within the same cluster.
- Choose TiDB when you need horizontal write scaling, distributed transactions, or HTAP — not for simple read-scaling.
TiDB 8.0 Architecture
TiDB separates compute from storage. TiDB nodes handle SQL parsing and execution; TiKV nodes handle distributed key-value storage with Raft consensus; TiFlash nodes provide columnar replicas for analytical queries.
tiup playground v8.0.0 --tiflash 2 --kv 3 --db 2 --pd 1HTAP with TiFlash
ALTER TABLE orders SET TIFLASH REPLICA 1;
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE, PROGRESS
FROM information_schema.TIFLASH_REPLICA WHERE TABLE_SCHEMA = 'ecommerce';
SELECT /*+ READ_FROM_STORAGE(TIFLASH[orders]) */
date_trunc('hour', created_at) AS hour, sum(total_amount) AS revenue
FROM orders WHERE created_at >= '2025-01-01'
GROUP BY 1 ORDER BY 1;Use EXPLAIN to verify TiFlash is selected. Look for ExchangeSender and TableFullScan with tiflash in the plan. Add the hint explicitly if it falls back to TiKV.
Resource Groups in TiDB 8.0
CREATE RESOURCE GROUP rg_oltp RU_PER_SEC = 10000, PRIORITY = HIGH, BURSTABLE;
CREATE RESOURCE GROUP rg_analytics RU_PER_SEC = 2000, PRIORITY = LOW;
ALTER USER 'app_user' RESOURCE GROUP rg_oltp;
ALTER USER 'analyst' RESOURCE GROUP rg_analytics;
SELECT RESOURCE_GROUP_NAME, TOTAL_RU_CONSUMED, TOTAL_KV_REQUEST_COUNT
FROM information_schema.RESOURCE_GROUPS_HISTORY;When to Choose TiDB 8.0
| Requirement | TiDB 8.0 | Single-node MySQL |
|---|---|---|
| Horizontal write scaling | ✓ Native | ✗ Requires sharding |
| Distributed ACID transactions | ✓ Built-in | ✗ Not supported |
| HTAP | ✓ TiFlash | ✗ Separate systems |
| Simple read scaling | Overkill | ✓ Read replicas |
| Single-region, <1TB data | Overkill | ✓ Right size |
TiDB does not enforce foreign key constraints identically to MySQL. FK syntax is supported but enforcement behavior differs — test thoroughly if your application relies on FK constraints for data integrity.
- TiDB 8.0 is production-ready for teams that have outgrown single-node MySQL and need horizontal write scaling or HTAP.
- TiFlash eliminates the ETL pipeline for analytics — data is available in real-time without separate infrastructure.
- Resource Groups in 8.0 prevent analytics from affecting OLTP latency.
- Do not choose TiDB for simple read scaling — read replicas on MySQL or PostgreSQL are simpler and cheaper.
Working with JusDB on TiDB
JusDB helps teams evaluate TiDB for their specific workload, size clusters correctly, and migrate from single-node MySQL with minimal downtime. We've deployed TiDB clusters handling 50K+ TPS for e-commerce and fintech clients.