KingbaseES's Single Kernel Powers Seven Deployment Shapes: From Single Node to Distributed Clusters
Scaling from a single node to a distributed cluster becomes a module addition, not a migration, which removes a major cost barrier for teams growing a database. But the documented limits—no SSI, no async events, and a 200% response hit on conflicting operations—set clear boundaries for where that convenience stops.
KingbaseES's centralized family spans four shapes, each with its own RTO/RPO trade-offs: single-node has RTO over 10 minutes on node failure, ClusterWare primary-standby takes a minute-plus to switch, RWC read-write separation holds RTO under a minute, and RAC shared-storage multi-active also stays under a minute. All claim RPO 0 and no application rewrites.
The RWC failover runs through seven rigid steps: reconnect confirmation, isolation, an election with hard criteria (log position, priority, node_id), majority check, network ping to trusted gateways, VIP/arping takeover, and a watchdog layer with repmgrd and kbha. The documentation even gives formulas for switchover time.
Distributed clusters come from stacking four modules on the same kernel: sharding management, distributed execution, distributed transactions, and global transaction consistency. That avoids the sharding-middleware route, keeping the SQL execution path identical. Costs hinge on storage, app migration, maintenance, and recovery time; the documentation also lists gaps like no SSI and no async notification, and warns that conflict-heavy workloads pay a 200% response penalty.
The RWC election and failover process is fully deterministic, with three hard criteria and no human override, which makes switchover predictable but leaves no room for judgment in unusual network partitions.
KingbaseES's distributed design keeps transactions and global consistency as kernel modules rather than external middleware, so the execution path and tooling stay identical across centralized and distributed deployments; that's a meaningful divergence from the sharding-middleware approach.
The documentation's self-listed limitations—missing SSI, missing async notification, and a 200% response hit on conflicting operations—are concrete constraints that a team must weigh against the convenience of a single codebase.