Choosing Between Sharding Middleware and NewSQL Distributed Databases: An Objective Comparison

What Makes NewSQL Databases Advanced?

Based on the classification in Pavlo’s SIGMOD paper, first‑generation NewSQL architectures (e.g., Spanner, TiDB, OceanBase) differ from middleware‑based sharding solutions (e.g., Sharding‑Sphere, Mycat, DRDS) which are considered a second class of distributed databases.

The author argues that middleware + relational DB sharding is indeed a distributed architecture because storage is distributed and horizontal scaling is possible, though it repeats SQL parsing and planning work, making it less efficient.

Distributed Transactions

NewSQL systems still face the CAP theorem; they do not magically break its constraints. Google Spanner achieves a high probability of being in a CA state by using a private global network and a highly reliable operations team.

Two‑phase commit (2PC) remains the core of most NewSQL transaction implementations, but optimizations such as Percolator’s timestamp oracle, MVCC, and snapshot isolation reduce lock contention and move part of the commit work to asynchronous paths, improving performance over classic XA.

Nevertheless, 2PC still incurs extra network round‑trips, GID acquisition, and log persistence, which can become a bottleneck in high‑concurrency scenarios like batch bank transfers.

HA and Multi‑Active Deployments

Traditional master‑slave replication suffers from data loss under network partitions; modern NewSQL databases adopt Paxos or Raft‑based multi‑replica protocols, providing automatic leader election, strong consistency, and sub‑30‑second failover.

While these protocols can be applied to traditional RDBMS (e.g., MySQL Group Cluster), true geo‑distributed active‑active setups are limited by network latency, making them impractical for latency‑sensitive OLTP workloads.

Horizontal Scaling and Sharding

NewSQL databases embed automatic sharding, region splitting, and load‑aware rebalancing, relieving DBAs from manual key design and migration work. In contrast, middleware‑based sharding requires upfront key selection, routing rules, and careful capacity planning.

However, built‑in sharding strategies may not align with domain models, potentially causing distributed transactions when related entities are placed on different shards.

Distributed SQL Support

Both approaches support single‑shard SQL, but NewSQL offers richer cross‑shard capabilities (joins, aggregations) thanks to global statistics and cost‑based optimization, whereas middleware often relies on rule‑based optimization and may lack efficient cross‑shard query execution.

Storage Engine

Traditional RDBMS use B‑Tree engines optimized for disk‑based random reads, while NewSQL typically adopts LSM‑tree storage, converting random writes into sequential writes for higher write throughput at the cost of more complex read paths.

Maturity and Ecosystem

NewSQL is still evolving, with strong adoption in internet companies but limited penetration in highly regulated sectors like banking, where proven RDBMS ecosystems, tooling, and DBA expertise dominate.

For organizations that prioritize throughput, rapid data growth, and reduced operational overhead, NewSQL may be attractive; for those that need proven stability, low latency, and deep compatibility with existing tooling, middleware‑based sharding remains a safer choice.

Conclusion

The article provides a checklist of questions (e.g., need for strong consistency, growth predictability, scaling frequency, DBA skill set) to guide the decision between NewSQL and sharding middleware, emphasizing that no solution is a silver bullet and the final choice depends on specific business and technical constraints.