A DBA Put 11 Systems on the Scale: Distributed Databases Lost Every Time
Centralized vs. Distributed: How I Re-Weighed All 11 Systems I Have on Hand
Last month at the annual capacity planning meeting, a colleague casually asked: should the new order middle platform go straight to a distributed database? That single sentence turned into a forty-minute discussion with no conclusion. After the meeting, my manager assigned me a task. He said, turn the centralized-versus-distributed choice into a one-page document so we can make a call next time.
I've been a DBA for over a decade and have seen this question cycle through many times. Honestly, by 2026 it's become harder to answer than before, because domestic (Chinese) databases have evolved into multiple flavors within each category. Both "centralized" and "distributed" now contain very different sub-types. Calling something "distributed" hides a lot of variation.
The process of writing that one-pager was essentially weighing all 11 of our business systems. This post records how I did it, for anyone facing the same confusion.
@[toc]
1. First, Dissect the Word "Distributed"
After taking the assignment, my first move was not to look at products. It was to break apart the term.
Usually, what people call "distributed" is actually a mix of at least four distinct things:
- Native distributed: Data is truly sharded and spread across multiple nodes. Cross-node transactions are handled by the database itself.
- Shard-plus-proxy: Underneath is still a single-node database. A middleware layer sits on top for routing and aggregation.
- Multi-tenant mode: One distributed cluster hosts many tenants, each running its own business. Data may or may not be sharded.
- Single-node mode: You bought a distributed database but use it as a single node without sharding.
The last two usages are sometimes called "pseudo-distributed" in the industry. I don't like that term, but the phenomenon is real. In teams I've interacted with, half of those claiming "we've gone distributed" are actually in tenant mode, consolidating dozens of separate single-node databases into one cluster without sharding the data.
That's not necessarily bad. Tenant mode can unify the tech stack and utilize underlying resources. But it comes with costs: resource redundancy, poor management flexibility, fault propagation within the cluster, and scaling that isn't as strong as expected. The key is knowing what you bought. If you spent distributed money for single-node usage, that bill needs to be laid out openly.
The centralized side also splits into at least three variants: single-node, primary-standby, and shared storage. Shared storage is similar to Oracle RAC, where multiple instances attach to the same storage. Historically, few domestic databases offered this, so everyone used primary-standby. That's changing. Some vendors are now pushing shared-storage clusters, e.g., Kingbase's shared-storage cluster targeting Oracle RAC scenarios, and DM's DMDSC.
2. Lay Out the Bill: A Comparison Table
After dissecting the terms, I built a comparison table. Too many forms make a mess, so I picked four representative ones.
| Dimension | Distributed (native) | Distributed (tenant/single-node usage) | Centralized (shared storage) | Centralized (primary-standby) |
|---|---|---|---|---|
| Read scaling | High | Medium | High | High/Medium |
| Write scaling | High | Medium/Low | High (Scale Up) | Low |
| Latency | Not an advantage (more layers, longer path) | Medium | Low | Low |
| Data consistency | Medium/High | Medium | Very high (single copy) | Medium |
| Reliability | High | Medium/Low | Very high | Medium |
| Design/dev adaptation | Need to consider shard keys, cross-node issues | Low | Low | Low |
| Overall cost | High | High | Medium | Medium/Low |
In this table, the two rows most easily overlooked are latency and consistency.
Latency first. When people talk about distributed, it's always throughput and scalability. Rarely latency. Distributed architectures have more layers and longer paths. A SQL from the app goes through routing, coordination, and cross-node transfer. Latency is naturally not an advantage. For most businesses, a few milliseconds doesn't matter. But for core transactions that are acutely latency-sensitive, the millisecond-level jitter from cross-node operations is unacceptable.
Consistency second. What kind of data consistency is the best? Actually, it's not replicating data. With only one copy, all reads and writes hit that copy, so there's no cross-copy synchronization. Centralized shared storage works on this idea. Strictly speaking, data is also redundant at the storage layer, but that's solved at a lower level. For the database layer, it's a single copy. So you'll find that shared-storage architecture can achieve "very high" consistency and reliability. That's no coincidence.
Another bill to count is money. I've heard more than one team complain that after going distributed, the total cost is even higher than the old IOE architecture. More hardware nodes, pricier software licenses, development adaptation investment, and expanded operations staffing. All adds up. In recent years, many distributed vendors have started offering "single-node integration" capabilities, essentially making up for this bill.
After finishing my table, I also threw all seven usage modes into one table for a second comparison, from architecture, performance, and consistency through cost. Refer to it alongside mine for a fuller picture:
3. Classify Business Scenarios, Don't Take Sides for Products
With the table in hand, the key step is to weigh each of your own systems against it.
I referenced common industry abstractions of typical business scenarios and built this scenario-architecture matching table:
| Scenario | Concurrency | Statement complexity | Latency requirement | Suitable architecture |
|---|---|---|---|---|
| Core transaction | High | Simple | Very low | Distributed (shard+proxy) / Centralized (shared, primary-standby) |
| E-commerce | High | Simple | Low | Distributed / Centralized |
| CRM / SCM / ERP | Medium | Complex | Medium | Centralized (shared, primary-standby), tenant mode works for smaller volumes |
| Data warehouse | Low | Very complex | High | Distributed (native) / Centralized for small-medium scale |
| HTAP | Medium | Complex | Medium | Distributed (native) / Centralized (shared) |
Note: "suitable" doesn't mean "must". Only ultra-large core transaction systems really need distributed's scaling capability. Medium-large cores work fine with centralized, and the shared-storage mode is more secure. Conversely, CRM/ERP systems have medium data and concurrency but complex business computation. Centralized's advantage is clear. The more you rely on in-database computation, the less you should scatter data everywhere.
Then I went through the company's 11 systems one by one. Two examples:
Core transaction database: Two databases, both under TB level, peak concurrency around 3,000. No capacity issues in the past five years. Classification: centralized, give budget to Scale Up, don't go distributed. If centralized suffices and you still force distributed, the extra money is effectively thrown away.
Planned order middle platform: Expected data volume 2TB in three years, peak concurrency 8,000. Neither touches the starting line for distributed. Industry consensus is that TB-scale data and 10k-level concurrency are the entry point for evaluating distribution, not the finish line. If you don't reach both, centralized is the more rational choice.
After weighing all 11 systems, the conclusion was already out. Not one requires distribution. What really needs study is how to choose within centralized. Is plain primary-standby enough, or should we go for a shared-storage cluster?
4. Homework Done on KingbaseES (KES)
Once business classification was done, I focused on KingbaseES (KES) at the product level. The reason is simple: our problem is how to choose within centralized, and Kingbase's product line includes centralized, distributed, and shared-storage clusters all in one family. Having the selection space inside one ecosystem has practical value for us.
Several points I liked, based on our team's actual situation:
First, migration cost. Half our legacy systems run on Oracle. When choosing a domestic database, Oracle compatibility directly determines migration effort. Public material claims Kingbase KES has fairly complete support for key features like PL/SQL packages, autonomous transactions, and cursor loops. In actual migration projects, over 95% of stored procedures run with minor adjustments. We can't take that number on faith; we need to verify it in a POC. But it signals the right direction.
Second, shared-storage cluster. We have a payment-related system that will eventually replace Oracle RAC. That requirement can be solved within a centralized framework. Kingbase RAC-style shared-storage clusters are built to match RAC usage habits, so latency characteristics and operational practices continue. This is a key conclusion for my one-pager: A RAC replacement need is not a reason to go distributed. It's a technical branch within centralized.
Third, mixed business forms. Beyond relational data, we also have document-style customer service records and time-series data from device reporting. AI work now needs vector search. Kingbase is relatively advanced in multi-model fusion, with relational, document, time-series, and vector data in one product system. For companies with mixed business forms, this capability can reduce maintaining several specialized databases.
Fourth, Xinchuang adaptation. Domestic CPUs covered: Kunpeng, Phytium, Hygon, and Loongson. Operating systems: Galaxy Kylin, UnionTech UOS all in the adaptation list. Many of our downstream clients are government-enterprise. This isn't a bonus point; it's the baseline.
Here are two SQL queries I used to inventory database sizes. They run directly on KES:
-- Size of each database, largest first
SELECT datname,
sys_size_pretty(sys_database_size(datname)) AS db_size
FROM sys_database
ORDER BY sys_database_size(datname) DESC;
-- Top 10 largest tables in the current database
SELECT relname,
sys_size_pretty(sys_total_relation_size(oid)) AS total_size
FROM sys_class
WHERE relkind = 'r'
ORDER BY sys_total_relation_size(oid) DESC
LIMIT 10;
These SQLs look simple, but at a capacity planning meeting, the numbers they produce are more useful than any PPT I've prepared.
5. Three Questions to Make the Call
Finally, I condensed the decision into three questions on the page:
- Will data volume stably exceed 10TB within three years? Is there a clear expectation of concurrency above 10,000? If neither, go centralized without hesitation.
- Is there a definite Oracle RAC replacement need? If yes, evaluate shared-storage clusters within a centralized framework. Don't jump to distributed because of this.
- Is the business already stable on the cloud? Is load volatility high? If yes, cloud-native is worth looking at. If not, you won't use cloud-native's elasticity and will just pile on an extra layer of complexity.
After the three questions, the conclusion for the order middle platform was set: start centralized, reserve a path to evolve toward a shared-storage cluster. There was basically no debate in the meeting, because every number was weighed from our own systems.
After the meeting broke up, I wrote a sentence in my notebook. I'll pass it on to peers struggling with the same choice: Decide the architecture first, then choose the product. If you get the architecture wrong, all the parameter comparisons, POC tests, and migration work that follow are wasted.
There is no best database, only the one that matches your business shape over the next three years.