NewSQL becomes relevant when a team no longer wants to choose between SQL ergonomics, ACID guarantees, and the pain of manual sharding. This chapter is about that expensive stage of growth.
In practice, it helps you see when distributed SQL actually removes architectural pain, and when data locality, inter-region latency, and transaction cost still dominate the design.
In interviews and engineering discussions, it is especially useful when you need to compare NewSQL against PostgreSQL plus sharding and NoSQL under concrete product constraints rather than vendor slides.
Practical value of this chapter
Global ACID fit
Identify where NewSQL preserves SQL+ACID under horizontal scale without manual sharding complexity.
Region-aware design
Model data locality and inter-region RTT so transactional paths do not pay unnecessary latency.
Cost of consistency
Balance strong consistency benefits against latency, throughput, and infrastructure cost.
Interview comparison
Compare NewSQL with Postgres+sharding and NoSQL using business constraints instead of vendor messaging.
Decision frame and editorial focus
Chapter focus
NewSQL DBMS class, distributed SQL, and the cost of strict transactions
Workload profile
The focus is transactional SQL at horizontal and often regional scale where one classic node no longer scales cleanly.
Good fit
Distributed SQL is justified when strong guarantees matter more than simplicity and the team accepts latency, coordination, and operations cost.
Boundary and risk
Key risks are hot keys, cross-region transactions, consensus cost, rebalancing, and the illusion of free sharding.
Connect next
Always validate the choice against a PostgreSQL/MySQL baseline, distributed transactions, and multi-region architecture.
Primary source
NewSQL (Wikipedia)
A compact historical overview of NewSQL as an attempt to combine SQL, ACID, and horizontal scale.
TiDB docs
TiDB Architecture
Official TiDB architecture overview: TiKV, PD, the SQL layer, and HTAP components.
NewSQL is usually considered when a team wants to keep SQL and ACID semantics, but workload has already outgrown comfortable single-node OLTP limits. In this chapter we compare three practical implementations: TiDB, CockroachDB and YDB.
The goal is not to choose one universal winner, but to map workload, transaction constraints, and operational context to the most suitable engine.
What NewSQL usually means in practice
SQL and ACID without manual sharding
The DBMS takes responsibility for transaction coordination, data placement, and load balancing.
Strong consistency as a default posture
The baseline objective is correctness under failures, not only peak write throughput.
Higher operational complexity than classic OLTP
Distributed SQL requires disciplined key design, observability, and capacity planning.
Shared architectural pattern
NewSQL architecture map
SQL compute separated from KV storage
One comparison frame for three designs: where SQL lives, how data is distributed, and where consistency cost appears.
MySQL-compatible path to distributed SQL
TiDB separates compute, metadata, and storage: SQL nodes accept requests, PD manages placement, TiKV stores data, and TiFlash adds an analytical path.
What to check
Best fit
Main risk
Measure
TiDB vs CockroachDB vs YDB
Core architecture
- TiDB: TiDB SQL nodes + TiKV on Raft + PD; HTAP path through TiFlash.
- CockroachDB: Single binary model: SQL + KV + Raft ranges in one cluster.
- YDB: Tablets and actors, shared-nothing design, with compute and storage split by layers.
Multi-region model
- TiDB: Placement policies exist, but regional and zonal topology still needs explicit tuning.
- CockroachDB: Strong built-in focus on geo-partitioning and data-locality policies.
- YDB: Multi-AZ and multi-region setups depend on cluster topology and domain configuration.
Compatibility and ecosystem
- TiDB: MySQL-compatible wire protocol and DDL; convenient for MySQL migration paths.
- CockroachDB: PostgreSQL wire compatibility and PostgreSQL-like SQL workflows.
- YDB: Own SQL dialect and APIs with strong integration into YDB/Yandex Cloud ecosystem.
Primary strengths
- TiDB: Balanced OLTP and operationally close HTAP analytics with practical MySQL migration support.
- CockroachDB: Strong global OLTP story with automated failover in multi-region environments.
- YDB: High-load transactional workloads, auto-sharding, and row+column tables in one platform.
Operational risks
- TiDB: Requires careful hot-region management and key-design discipline; HTAP adds operational complexity.
- CockroachDB: Cross-region transactions add latency, and schema/key design strongly affects write cost.
- YDB: Needs a mature distributed-operations model and strong partitioning practices.
| Criteria | TiDB | CockroachDB | YDB |
|---|---|---|---|
| Core architecture | TiDB SQL nodes + TiKV on Raft + PD; HTAP path through TiFlash. | Single binary model: SQL + KV + Raft ranges in one cluster. | Tablets and actors, shared-nothing design, with compute and storage split by layers. |
| Multi-region model | Placement policies exist, but regional and zonal topology still needs explicit tuning. | Strong built-in focus on geo-partitioning and data-locality policies. | Multi-AZ and multi-region setups depend on cluster topology and domain configuration. |
| Compatibility and ecosystem | MySQL-compatible wire protocol and DDL; convenient for MySQL migration paths. | PostgreSQL wire compatibility and PostgreSQL-like SQL workflows. | Own SQL dialect and APIs with strong integration into YDB/Yandex Cloud ecosystem. |
| Primary strengths | Balanced OLTP and operationally close HTAP analytics with practical MySQL migration support. | Strong global OLTP story with automated failover in multi-region environments. | High-load transactional workloads, auto-sharding, and row+column tables in one platform. |
| Operational risks | Requires careful hot-region management and key-design discipline; HTAP adds operational complexity. | Cross-region transactions add latency, and schema/key design strongly affects write cost. | Needs a mature distributed-operations model and strong partitioning practices. |
Fast scenario-based selection
Global SaaS with active multi-region writes
Often CockroachDB
A good fit when locality policies, region-failure survivability, and predictable geo-failover are critical.
Growth from MySQL toward distributed SQL without fully rewriting the solution
Often TiDB
Useful when MySQL compatibility, incremental migration, and OLTP+HTAP in one platform are priorities.
High-load transactional services in Yandex Cloud ecosystem
Often YDB
A common fit when managed/native YDB integration and auto-sharding are key requirements.
Standard regional OLTP without hard scale-out pressure
Often not NewSQL
If PostgreSQL/MySQL already meets workload and SLA, distributed SQL can add unnecessary complexity.
Recommendations
Start with a key design document: partition key, transaction boundaries, and expected hot keys.
Measure p95/p99 latency under node/AZ failures and network partitions, not only steady-state throughput.
Separate local and cross-region transaction paths explicitly to control latency and cost.
Build observability around shard/range/tablet behavior: skew, rebalance, retries, and lock contention.
Common mistakes
Treating NewSQL as a silver bullet and migrating schemas without redesigning key strategy.
Ignoring transaction boundaries and allowing frequent cross-shard or cross-region writes.
Comparing engines only with synthetic benchmarks, without failure and rebalance behavior.
Choosing distributed SQL when single-node OLTP already satisfies workload and SLA.
References
Related chapters
- Database Selection Framework - Selection criteria that make it clear when NewSQL justifies its extra complexity.
- YDB: distributed SQL database and architecture - Detailed YDB internals: tablets, auto-sharding, transactional guarantees, and operational trade-offs.
- CockroachDB: distributed SQL database and architecture - Detailed CockroachDB internals: ranges, leaseholders, Raft replication, and data-locality policies.
- PostgreSQL: history and architecture - A baseline comparison with classic OLTP architecture and scenarios where NewSQL is unnecessary.
- Distributed Transactions: 2PC and 3PC - Background on transaction coordination, latency trade-offs, and why distributed commit is never free.
- Multi-region and global systems - Geo-distributed architecture practices: locality, failover, and latency-aware design.