Chinese Domestic Databases: Three Generations Compared for Selection

Kernel Origins Define Three Technical Generations

The article establishes that Chinese domestic databases are not a monolith but fall into three distinct technical lineages:

Traditional centralized – Dameng DM8 (self-developed, initially referencing Oracle) and Kingbase KES (PostgreSQL kernel). Both target Oracle/MySQL/PostgreSQL compatibility.

Open-source modified – openGauss/GaussDB (Huawei's deep PostgreSQL fork). Primary compatibility is PostgreSQL with partial MySQL support.

Self-developed distributed – OceanBase (Ant Group, pure self-developed) and TiDB (PingCAP, self-developed). Both are distributed NewSQL databases compatible with MySQL protocol; OceanBase also offers an Oracle mode.

The kernel origin determines three critical factors: migration cost of existing SQL/stored procedures, reuse of DBA skills and ecosystem tools, and the viable migration path.

Product-by-Product Analysis

Dameng DM8: Traditional Sector Xinchuang Mainstay

Positioning : Oracle "drop-in replacement", first choice for government/enterprise Oracle replacement.

Strengths : High Oracle syntax/stored procedure compatibility; centralized architecture with Oracle-like operational mindset; full government/enterprise certification.

Weaknesses : Weaker distributed capabilities than internet-grade systems; small community ecosystem (commercial support driven); compatibility mode edge cases (empty string handling, case-sensitivity parameters).

Best fit : Deep Oracle legacy (heavy PL/SQL), government/enterprise centralized deployment, no internet-scale concurrency needs.

Kingbase KES: PostgreSQL-line Xinchuang Representative

Positioning : PostgreSQL kernel + xinchuang certification, default answer for "PostgreSQL users moving to xinchuang".

Strengths : Native PostgreSQL ecosystem compatibility (extensions, drivers, tools largely work); multi-mode compatibility (Oracle/MySQL/PostgreSQL); high market share in party/government/state-owned enterprises.

Weaknesses : Multi-mode compatibility is a double-edged sword (dialect behavior deviates from native PostgreSQL); distributed capability is average.

Best fit : PostgreSQL/MySQL legacy migration, government/state-owned enterprises, teams with existing PostgreSQL stack.

openGauss / GaussDB: Huawei Ecosystem

Positioning : Open-source (openGauss) + commercial (GaussDB), tightly bound to Huawei ecosystem.

Strengths : Performance optimizations via self-developed storage engine and MOT in-memory tables; enterprise-grade features (full encryption, security); synergy with Huawei hardware (Kunpeng) and cloud.

Weaknesses : Growing divergence from upstream PostgreSQL (upgrades no longer track community); ecosystem primarily via Huawei channels.

Best fit : Huawei ecosystem customers (Kunpeng/Huawei Cloud), government/enterprise with hard security requirements.

OceanBase: Financial-grade Distributed

Positioning : Ant Group self-developed distributed database, validated in financial core systems (Alipay, MYbank).

Strengths : Paxos-based majority strong consistency; distributed high availability (RPO=0); mature multi-region multi-active deployments (two-region-three-center, five-data-center); HTAP capability; MySQL/Oracle compatibility modes.

Weaknesses : Distributed complexity raises operational bar; overkill for small centralized scenarios.

Best fit : Financial core systems, ultra-high concurrency with strong consistency, large-scale multi-active geo-distribution.

TiDB: Distributed HTAP Open-source Benchmark

Positioning : MySQL-protocol-compatible distributed NewSQL, most active open-source community among domestic databases.

Strengths : Transparent horizontal scaling (application sees near single-node MySQL); TiFlash columnar engine for real-time analytics (HTAP); cloud-native with mature Kubernetes deployment.

Weaknesses : Poor cost-benefit at small scale (minimum 6+ nodes); MySQL compatibility not 100%; extreme single-point latency worse than native MySQL.

Best fit : Internet businesses where MySQL sharding has become untenable, HTAP mixed workloads, open-source self-controllability.

Cross-dimensional Comparison

The article provides a tabular comparison across five dimensions:

Architecture : Dameng/Kingbase/openGauss are centralized (openGauss mainly); OceanBase/TiDB are distributed.

Syntax compatibility : Dameng→Oracle; Kingbase→Oracle/MySQL/PostgreSQL modes; openGauss→PostgreSQL/partial MySQL; OceanBase→MySQL/Oracle modes; TiDB→MySQL.

Horizontal scaling : Weak for first three; strong for OceanBase and TiDB.

Operational threshold : Low (Oracle-like) for Dameng; low (PostgreSQL-like) for Kingbase; medium for openGauss; high for OceanBase; medium-high for TiDB.

Typical customers : Dameng→government/military/power; Kingbase→government/state-owned; openGauss→Huawei ecosystem government/enterprise; OceanBase→banks/Alipay ecosystem; TiDB→internet/fintech.

Selection Decision Tree

Question 1: Is xinchuang compliance a hard requirement?
├─ Yes → What is the existing stack?
│   ├─ Deep Oracle legacy → Dameng
│   ├─ PostgreSQL/MySQL legacy, government → Kingbase / openGauss
│   └─ Large financial core + multi-active → OceanBase
└─ No (pure technical selection) → Has scale outgrown single instance?
    ├─ Single MySQL still handles load → Don't switch, MySQL is optimal
    ├─ Sharding untenable / need HTAP → TiDB or OceanBase
    └─ On Huawei Cloud/Kunpeng → GaussDB

Three Universal Reminders

POC with real workload replaces official benchmarks : Run your actual top-20 SQL statements on candidate databases; vendor benchmarks have no reference value.

Operational ledger first : Backup/recovery, monitoring/alerting, DBA staffing, commercial support SLA—distributed operational costs are often underestimated.

Exit cost : Prefer products with mainstream syntax compatibility (MySQL/PostgreSQL/Oracle modes) to keep a future migration path open.

Quick Reference Summary

Three generations: shell-based centralized (Dameng/Kingbase), open-source modified (openGauss), self-developed distributed (OceanBase/TiDB) — kernel origin dictates migration cost and ecosystem reuse .

Dameng = Oracle replacement; Kingbase = PostgreSQL xinchuang; openGauss = Huawei ecosystem; OceanBase = financial distributed; TiDB = open-source HTAP.

Centralized migration cost lowest: follow original kernel (Oracle→Dameng, PostgreSQL→Kingbase/openGauss).

Distributed prerequisites: real scale (sharding pain) + operational capability.

Decision chain: compliance mandatory? → legacy compatibility → scale match → POC + operational ledger + exit cost.

Insight : The first step in choosing a domestic database is not comparing feature lists, but understanding "which soil it grew from" — kernel origin is the root of all differences.