NewSQL vs Sharding: Which Database Architecture Truly Wins?

The author compares NewSQL databases with middleware‑based sharding solutions, aiming to objectively present their strengths, weaknesses, and suitable scenarios.

NewSQL数据库先进在哪儿？

According to a SIGMOD paper, Spanner, TiDB, and OceanBase belong to the first new‑architecture class, while middleware solutions such as Sharding‑Sphere, Mycat, and DRDS belong to the second class.

Middleware + traditional relational databases constitute a distributed architecture because storage is also distributed and can achieve horizontal scaling, but they duplicate SQL parsing and execution‑plan generation, making them less efficient.

NewSQL databases improve on this by using memory‑centric storage, optimized distributed transactions, multi‑replica storage based on Paxos or Raft for true high availability, and built‑in automatic sharding that is transparent to applications.

分布式事务

NewSQL does not break the CAP theorem; Spanner claims "CA" by relying on a private global network that minimizes partition events.

In distributed systems you can know where work happens or when it finishes, but not both simultaneously; two‑phase commit is essentially an availability‑reducing protocol.

完备性

Two‑phase commit does not guarantee strict ACID under all failure scenarios; many NewSQL products have incomplete distributed‑transaction support.

性能

Traditional databases use XA, which incurs high network overhead and blocking; NewSQL often implements optimized two‑phase commit using atomic clocks, MVCC, and snapshot isolation, improving performance.

SI is optimistic locking; in hotspot scenarios it may cause many aborts, and its isolation level differs from repeatable read.

HA与异地多活

Modern systems adopt Paxos/Raft‑based multi‑replica storage with majority‑write rules, providing high reliability and fast failover, and this approach is also being applied to traditional databases such as MySQL Group Cluster.

Implementing a production‑grade consensus algorithm requires handling many failure modes and optimizations like multi‑Paxos or multi‑Raft.

Scale横向扩展与分片机制

NewSQL databases have built‑in sharding that automatically balances load, splits regions, and migrates data without application changes; middleware solutions require manual key design and routing.

Sharding can also achieve online scaling via asynchronous replication and read‑only phases, but it needs middleware and database coordination.

分布式SQL支持

NewSQL supports full cross‑shard joins, aggregations, and complex SQL thanks to built‑in statistics and cost‑based optimization; middleware often lacks these capabilities.

Middleware‑based systems rely on rule‑based optimization, limiting cross‑database query support.

存储引擎

Traditional databases use B‑Tree storage optimized for disk access; NewSQL often uses LSM trees, converting random writes to sequential writes for higher write throughput, though reads may be slower.

成熟度与生态

NewSQL is still maturing, widely adopted in internet companies for high‑throughput OLTP, while traditional relational databases have decades of stability, tooling, and DBA expertise, making them preferable for risk‑averse industries.

总结

When choosing between NewSQL and sharding, consider questions such as the necessity of strong consistency, unpredictable data growth, scaling frequency, throughput vs latency priorities, application transparency, and available DBA expertise.

If most answers are affirmative, NewSQL may be appropriate despite higher learning costs.

If only a few are affirmative, middleware‑based sharding offers a lower‑risk, lower‑cost solution.

Both approaches have trade‑offs; there is no perfect solution.