A DBA Put 11 Systems on the Scale: Distributed Databases Lost Every Time
Distributed database marketing pushes teams toward sharding they don't need. This hands-on evaluation shows how to measure your own systems and arrive at a defensible 'no' before spending on extra nodes, licenses, and operational overhead.
When a colleague suggested moving the new order creation platform to a distributed database, the annual capacity planning meeting ballooned into a 40-minute argument with no conclusion. The DBA was handed a one-page decision paper. The result is a practical framework that first dismantles the word "distributed" into four distinct usages: native sharding, the shard-plus-proxy pattern (still single-node underneath), multi-tenant virtualization on a cluster, and running the distributed system as a single node. Half the teams claiming to have gone distributed are actually on the multi-tenant mode with no sharding at all.
The comparison table across dimensions like read/write scaling, latency, consistency, reliability, and cost shows that shared-storage centralization (the Oracle RAC style) achieves the highest consistency and low latency, while native distributed suffers on latency and costs more overall. The author then maps common business scenarios: core transactions with high concurrency and simple statements fit either distributed sharding or centralized shared storage; CRM/ERP with complex queries favor centralized; data warehouses and HTAP workloads justify native distributed. Across their own 11 systems, including a core transaction DB under 1TB with 3,000 peak concurrency and a planned order platform projecting 2TB and 8,000 concurrent, none meet the common threshold for distribution (TB-scale data and 10k concurrency). The conclusion: no system requires distribution.
The paper ends with three decision questions: will data stably exceed 10TB in three years with concurrency clearly above 10k; is there a definite Oracle RAC replacement requirement; is the workload already cloud-native with elastic spikes? Only if the first is true does distribution become mandatory. The DBA also reviews KingbaseES (KES) for centralized selection, highlighting Oracle compatibility, a shared-storage cluster for RAC replacement, multi-model support for relational, document, time-series, and vector data, and domestic CPU/OS certification. The final advice: decide on architecture before choosing a product.
Reducing an emotionally charged architectural debate to three measurable thresholds is a practical antidote to vendor-driven hype.
Treating 'distributed' as a single category obscures that most real deployments are multi-tenant or single-node, letting teams pay distributed license costs without receiving distributed capabilities.
The comparison table shows shared-storage centralized can match distributed on read scaling while achieving higher consistency and lower latency, making it a strong best-of-both-worlds option for core transactions.