Order Read/Writes Expose Where KingbaseES Centralized and Distributed Architectures Diverge
Evaluating distributed databases by node count instead of request paths produces POC failures and wasted migrations. Mapping transactional writes, tenant-keyed reads, and global reports early tells you whether shared-storage RAC, distributed TDC, or a single centralized instance is the right baseline.
A payment debits an account, writes a ledger row, and updates order status in one transaction; a month-end report aggregates all tenants by time. The first needs atomic multi-table commit, the second needs a wide scan. Splitting these two access shapes before counting nodes clears up architecture evaluation.
KingbaseES core is centralized, RAC adds shared-storage multi-write nodes, and TDC distributes data and compute. Each changes what you must verify: RAC puts storage bandwidth at the center, TDC demands that distribution keys match real request parameters. The article walks through payment SQL, tenant-key queries, full-tenant reports, and hot-spot analysis, showing how each workload determines whether a single tenant key, composite indexes, or a mixed-load POC makes sense.
The core method is to test with the same request set, adjust one variable at a time, and measure P95/P99, lock waits, connection recovery, and resource usage while checking business results for duplicates. Only then do numbers justify a centralized, RAC, or TDC choice.
The centralized-versus-distributed decision is framed as a data-organization and access-path question, making node count a secondary metric that often misleads capacity planning.
Putting tenant-key validation and hot-spot analysis before any POC turns an architectural debate into a concrete checklist, which is more reliable than relying on vendor claims about node scaling.
The insistence on testing mixed workloads and idempotent retry paths reflects a mature understanding that distributed databases shift cost from query execution to routing and cross-node coordination.