Choosing Between Sharding Middleware and NewSQL Distributed Databases: Advantages, Trade‑offs, and Use Cases

During recent technology exchanges, the author often receives questions about how to choose between sharding (分库分表) with middleware and NewSQL distributed databases, and notes that many online opinions are overly biased without considering specific environments.

What makes NewSQL databases advanced?

The author references the Pavlo et al. SIGMOD paper to classify NewSQL architectures: first‑generation designs like Spanner, TiDB, and OceanBase, and second‑generation middleware solutions such as Sharding‑Sphere, Mycat, and DRDS.

Middleware‑based sharding (including SDK and proxy forms) does create a distributed architecture because storage is distributed and horizontal scaling is possible, but the author questions whether it is a "pseudo" distributed database.

From an architectural perspective, middleware adds redundant SQL parsing and execution‑plan generation, which is inefficient compared to native NewSQL designs. Hence, in this article, "NewSQL" refers specifically to the new‑architecture databases.

A simple diagram (shown below) contrasts the two architectures.

Traditional databases are disk‑oriented; NewSQL leverages memory‑centric storage and concurrency control for higher efficiency.

Middleware repeats SQL parsing and optimization, leading to lower efficiency.

NewSQL’s distributed transaction layer is optimized beyond XA, offering better performance.

NewSQL stores data using Paxos or Raft multi‑replica protocols, achieving true high availability (RTO < 30 s, RPO = 0) compared with traditional master‑slave setups.

NewSQL natively supports automatic sharding, migration, and scaling, reducing DBA workload and being transparent to applications.

The author then examines each claimed advantage in detail.

Distributed Transactions

Distributed transactions are a double‑edged sword. The CAP theorem still limits distributed databases: guaranteeing strong consistency inevitably sacrifices either availability or partition tolerance.

Google Spanner, the archetype for many NewSQL systems, claims to be "practically CA" because it operates on a private global network that minimizes partitions and relies on a highly capable operations team.

Recommended reading: Eric Brewer’s article on Spanner, TrueTime, and CAP theory.

Two‑phase commit (2PC) provides ACID guarantees but incurs network overhead, logging, and latency, especially across many nodes. NewSQL implementations (e.g., Google Percolator) use timestamp‑oracle‑based MVCC and snapshot isolation to reduce lock contention and make part of the commit asynchronous, improving performance over classic XA.

SI (optimistic locking) may cause many aborts under hotspot workloads and offers isolation weaker than repeatable read.

Nevertheless, 2PC’s extra steps (GID acquisition, prepare‑log persistence) still cause noticeable performance loss, particularly in high‑throughput scenarios like batch bank transfers.

Most NewSQL vendors claim full distributed‑transaction support, yet practical guidance still advises minimizing cross‑shard transactions.

HA and Multi‑Active Deployments

Traditional master‑slave replication, even semi‑synchronous, can lose data under extreme conditions. Modern solutions adopt Paxos or Raft multi‑replica protocols (e.g., Spanner, TiDB, CockroachDB, OceanBase) to achieve automatic leader election, high reliability, and fast failover.

These protocols can also be applied to classic RDBMS; MySQL Group Replication is an example.

Implementing production‑grade consensus algorithms requires handling many failure modes and optimizations such as multi‑Paxos, batching, and asynchronous I/O.

Geographic multi‑active deployments are limited by network latency; high‑latency links make true active‑active OLTP impractical.

Scale, Sharding Mechanisms, and Horizontal Expansion

While Paxos solves availability, it does not address scaling; built‑in sharding is essential. NewSQL databases embed automatic range‑based or hash‑based sharding, hotspot detection, and online rebalancing (e.g., TiDB’s region split at 64 MiB).

In contrast, middleware‑based sharding requires upfront design of split keys, routing rules, and manual scaling procedures, increasing application complexity.

Online scaling with middleware is possible via asynchronous replication and read‑only phases, but it demands tight coordination between middleware and the underlying DB.

However, generic sharding strategies may not align with domain models, leading to distributed transactions for many business operations (e.g., banking transactions spanning customer, account, and ledger tables).

Distributed SQL Support

Both approaches handle single‑shard SQL well. NewSQL, being a unified database, offers richer cross‑shard capabilities such as joins, aggregations, and cost‑based optimization (CBO) thanks to global statistics.

Middleware relies on rule‑based optimization (RBO) and often lacks full cross‑shard support, limiting complex queries.

NewSQL typically supports MySQL or PostgreSQL protocols, while middleware can proxy many database protocols, offering broader SQL compatibility.

Storage Engine

Traditional engines use B+‑tree structures optimized for disk access; random writes cause tree splits and degrade performance. NewSQL engines often adopt LSM‑tree designs, converting random writes into sequential writes for higher write throughput, at the cost of slightly slower reads.

Additional optimizations (SSD, caching, Bloom filters) mitigate read penalties, but overall latency may still be higher than single‑node RDBMS due to replication and transaction overhead.

Maturity and Ecosystem

Evaluating distributed databases requires multidimensional testing: feature completeness, community health, monitoring tools, DBA skill availability, SQL compatibility, performance, HA, online DDL, and more.

NewSQL products have matured enough for many internet‑scale workloads but remain less battle‑tested than decades‑old relational databases, which boast extensive tooling, talent pools, and proven stability.

Enterprises with strict risk tolerance (e.g., banks) may prefer middleware‑based sharding for its lower technical barrier, while fast‑moving internet companies may adopt NewSQL to avoid the operational overhead of manual sharding.

Other features such as online DDL, data migration tools, and operational utilities are omitted for brevity.

Conclusion

Readers should assess whether NewSQL’s promised benefits address genuine pain points: strong consistency, unpredictable data growth, frequent scaling, throughput‑centric workloads, application transparency, and available DBA expertise.

If two to three of these criteria are affirmative, NewSQL is worth considering despite its learning curve.

Otherwise, traditional sharding with middleware remains a lower‑risk, lower‑cost solution that leverages existing RDBMS ecosystems.

Ultimately, no solution is perfect; the choice depends on domain characteristics, architectural preferences, and organizational readiness.