Can National Standards Accelerate the Growth of China's Domestic Databases?

Background and Motivation

Chinese "Xinchuang" (domestic) databases have proliferated with diverse architectures, technology stacks, and implementation details. An initial concern is that a national standard might impose uniform constraints on products that are fundamentally different, turning a standard into a restrictive tool rather than a facilitator.

Why Standards Can Still Be Valuable

Historical experience with commercial databases shows that, after an early period of heterogeneity, the market converged on a set of de‑facto technical standards (SQL syntax, B‑tree indexes, MVCC, transaction isolation levels, stored procedures, triggers, etc.). Those common features enabled rapid growth and interoperability. Domestic databases, although newer, are already aligning with the same core features of Oracle, MySQL, and PostgreSQL.

Practical Experience with Domestic Products

In a 2014 performance‑optimization project the team first encountered domestic systems such as DM (达梦) and Kingbase (金仓). Familiar system‑view names— DBA_TABLES, V$SYSSTAT, V$SESSION —provided an immediate sense of compatibility, even though the underlying kernel and metric granularity differed from Oracle. This partial compatibility reduced onboarding effort and contributed to a smoother project outcome.

Standardizable Peripheral Interfaces

While core database engines (execution plans, optimizer algorithms, storage engines) are inherently difficult to standardize, several peripheral interfaces can be defined as national reference specifications:

Observability APIs : a uniform set of endpoints for exposing load, latency, wait‑event, and cluster‑level metrics.

Data‑dictionary tables : a common schema (e.g., a view named DBA_TABLES) that presents table metadata, column definitions, and statistics across products.

Cloud‑platform integration interfaces : a standardized RDS‑type contract that allows third‑party databases to be managed as first‑class services on public clouds.

Observability API Example

GET /api/v1/metrics
{
  "cpu_usage": "float",
  "disk_io": "float",
  "wait_events": [{"event": "string", "count": "int"}]
}

Implementations that expose this JSON structure can be ingested by any monitoring tool without custom adapters.

Data‑Dictionary Standard

CREATE VIEW DBA_TABLES AS
SELECT owner, table_name, tablespace_name, num_rows, last_analyzed
FROM internal_metadata_table;

Adopting a single view name and column set eliminates the need for product‑specific translation layers.

Log File Standardization

Standardizing log locations, file‑naming conventions, and entry formats has negligible impact on the database kernel but greatly assists DBA troubleshooting. For example, adopting an Oracle‑style error stack that prints the full call trace (from the innermost PL/SQL block outward) enables faster root‑cause analysis.

Programming Interface Harmonization

JDBC/ODBC already provide a baseline API, yet details such as sequence generation and stored‑procedure syntax remain fragmented:

Sequences : Oracle uses seq_name.NEXTVAL. Some domestic products emulate this, but others require custom functions.

Stored procedures : Vendors offer PL/SQL‑like, MySQL‑style, or PostgreSQL‑style syntaxes. A national stored‑procedure language could be based on Oracle PL/SQL with Ada‑style extensions, providing broad compatibility while allowing vendor‑specific extensions.

Cloud RDS Integration Case

When a cloud provider offers its own database as a managed RDS service, third‑party domestic databases must be deployed on generic VMs, leading to performance disparities (bare‑metal vs. cloud‑disk I/O). A mutually agreed RDS‑integration specification—defining required APIs for provisioning, scaling, backup, and monitoring—allows all vendors to implement a comparable managed‑service layer, eliminating the business‑driven incompatibility.

Migration Performance Considerations

Even with interface compatibility, execution‑plan differences can cause query runtimes to increase several‑fold after migrating from Oracle to a domestic system. Typical causes include:

Sub‑optimal index design that Oracle’s Cost‑Based Optimizer (CBO) can tolerate but other engines cannot.

Differences in join ordering, statistics freshness, and parallel execution strategies.

Addressing these issues requires query rewriting, index tuning, and, where possible, enhancements to the target database’s optimizer.

Conclusion

National standards focused on peripheral interfaces—observability APIs, data‑dictionary views, log formats, stored‑procedure syntax, and cloud‑RDS contracts—can lower learning curves, simplify tool development, and encourage broader ecosystem participation without constraining core engine innovation. While such standards do not eliminate performance gaps inherent to different execution engines, they provide a practical foundation for migration, monitoring, and cloud integration across Chinese domestic databases.