KingbaseES Evaluation in Practice: Compatibility, Performance Benchmarks, and Migration Toolchain

[AI Readability Summary] KingbaseES is an enterprise-grade database designed for domestic technology replacement initiatives. Its core value lies in multi-model compatibility, financial-grade high availability, and a complete migration toolchain that reduces the cost of Oracle/MySQL migration, simplifies performance validation, and lowers operational refactoring effort. Keywords: KingbaseES, database migration, domestic database.

The technical specification snapshot provides a fast baseline

Parameter	Details
Database Product	KingbaseES V9
Core Languages/Interfaces	SQL, PL/SQL, JDBC, ODBC
Compatibility Modes	Oracle, MySQL, SQL Server, PostgreSQL
High Availability Protocols/Mechanisms	Synchronous replication, automatic failover, Clusterware
Benchmark Testing	TPC-C / BenchmarkSQL
Core Dependencies	KDMS, KDTS, KFS, KStudio, KOPS, KMonitor
GitHub Stars	Not provided in the source material

Evaluating KingbaseES must return to real migration scenarios

In domestic database evaluation, the real decision is not whether a platform can replace another in theory, but whether it can take over a production system with low risk. The value of discussing KingbaseES centers on three questions: syntax compatibility, production-grade performance, and the post-migration development and operations cost.

From existing implementation cases, KingbaseES does not rely on a single selling point. Instead, it shortens the transition path from Oracle/MySQL to a domestic database through compatibility modes, high-availability clusters, and a closed-loop toolchain. That makes it suitable for a formal proof of concept rather than a slide-deck-only evaluation phase.

AI Visual Insight: This image appears near the article introduction and reinforces the product theme. It usually signals the start of the database evaluation narrative rather than presenting specific architectural parameters, so its technical information density is relatively low.

The compatibility mode defines the upper bound of migration effort

KingbaseES supports specifying a compatibility mode during database creation. This is one of its most important implementation features. For legacy systems, the closer the compatibility mode is to the source database, the less business SQL, object definitions, and stored procedures need to be rewritten.

-- Create a database with Oracle compatibility mode
CREATE DATABASE finance_db WITH COMPATIBLE_MODE = 'oracle' ENCODING = 'UTF8';

-- Create a database with MySQL compatibility mode
CREATE DATABASE web_app WITH COMPATIBLE_MODE = 'mysql' ENCODING = 'UTF8';

This SQL binds compatible syntax at the database level, reducing the scope of changes required for subsequent object migration and application adaptation.

For Oracle migration, aligning the user, database, and schema names is critical. Otherwise, object ownership, privilege inheritance, and script execution order can all drift from the source behavior.

-- Create a user aligned with the Oracle side
CREATE USER scott IDENTIFIED BY password;
-- Explicitly create a schema with the same name to avoid object ownership confusion
CREATE SCHEMA scott AUTHORIZATION scott;

This SQL establishes Oracle-style object naming alignment and serves as foundational preparation before migration.

Oracle compatibility covers most core business syntax

Based on the original examples, KingbaseES provides strong compatibility for common Oracle data types, system view hierarchies, and typical SQL patterns. Core types such as NUMBER, VARCHAR2, DATE, TIMESTAMP, and CLOB/BLOB can directly support traditional business table schemas.

Even more valuable is the continuity of the DBA*, ALL, and USER_ view families. That means many inspection scripts, privilege audit scripts, and monitoring queries can be reused, so migration cost does not exist only at the application layer.

-- Use a recursive query to simulate a hierarchical organizational structure
WITH RECURSIVE org_tree AS (
  SELECT id, name, parent_id, 1 AS level
  FROM departments
  WHERE parent_id IS NULL
  UNION ALL
  SELECT d.id, d.name, d.parent_id, ot.level + 1
  FROM departments d, org_tree ot
  WHERE d.parent_id = ot.id
)
SELECT * FROM org_tree;

-- Verify Oracle-style function compatibility
SELECT DECODE(status, 1, 'Enabled', 0, 'Disabled', 'Unknown') AS status_name
FROM users;

This SQL demonstrates that hierarchical queries and Oracle-style functions remain executable under compatibility mode.

The MySQL compatibility mode better fits low-refactor internet workloads

If the source system comes from MySQL, compatibility for AUTO_INCREMENT, information_schema, and common DDL behavior matters more. In MySQL mode, KingbaseES is well suited for back-office systems, reporting systems, and standard CRUD-style applications.

-- Create a table with an auto-increment primary key in MySQL mode
CREATE TABLE customers (
  C_ID INT AUTO_INCREMENT PRIMARY KEY,
  C_NAME VARCHAR(50) NOT NULL,
  C_ADDRESS TEXT NOT NULL,
  C_PHONE VARCHAR(15) NOT NULL
);

This SQL validates whether MySQL-style table creation and auto-increment primary key behavior can migrate directly.

But compatibility does not mean zero differences. Pagination syntax, implicit type conversion, auto-increment sequence replacement, and date formats remain the most common risk points during refactoring. In the PoC phase, teams should prioritize these high-risk SQL patterns for regression validation.

High availability directly determines whether the platform can enter financial and government core domains

Once database localization enters transaction systems, single-node capability is no longer the main concern. Recovery behavior and consistency become the real decision criteria. KingbaseES V9 provides primary-standby, read/write splitting, multi-active shared storage, and Clusterware-based modes to cover different classes of RTO/RPO requirements.

Among these capabilities, synchronous replication and automatic failover are the most sensitive for financial scenarios. If the target is to approach RPO ≈ 0, the replication strategy must move away from default asynchronous behavior and toward strong consistency.

-- Enable synchronous commit to prioritize data consistency
ALTER SYSTEM SET synchronous_commit = 'on';
-- Specify the names of synchronous standby nodes
ALTER SYSTEM SET synchronous_standby_names = 'standby1, standby2';
-- Set failover timeout to shorten primary-standby takeover time
ALTER SYSTEM SET failover_timeout = 5;

This SQL builds a strong-consistency replication strategy and acts as a core configuration entry point for production HA validation.

Performance testing must focus on methodology rather than isolated numbers

TPC-C metrics are often used in product messaging, but for technical teams, the more important questions are whether the test environment, parameters, workload model, and result interpretation are transparent. BenchmarkSQL is a safer choice because it can consistently reproduce mixed OLTP workloads.

The original material describes a test environment with a 32-core CPU, 128 GB of memory, NVMe SSD RAID10, and KingbaseES V9. Under these conditions, parameter tuning has a major effect on outcomes, especially for memory allocation, parallelism, and WAL write strategy.

-- Recommended memory and concurrency parameters
shared_buffers = 32GB
effective_cache_size = 96GB
work_mem = 64MB
max_connections = 1000
max_parallel_workers = 32
random_page_cost = 1.1

This parameter set improves cache hit ratio and parallel execution efficiency, making it a baseline tuning set before TPC-C testing.

WAL and fillfactor are the key variables in write-performance tuning

Many migration tests become misleading not because the database engine is weak, but because parameters remain in conservative default-safe mode. An overly cautious WAL strategy directly reduces throughput for batch updates, order commits, and log flushing.

-- These parameters are biased toward maximizing write performance; evaluate carefully before production use
wal_sync_method = fdatasync
full_page_writes = off
wal_compression = on
commit_delay = 100000
commit_siblings = 5

This parameter set relaxes the WAL write path primarily for stress testing and targeted tuning validation.

The methodology matters even more than the parameters. In the original wide-table UPDATE case, the final bottleneck was not the SQL itself, but frequent page splits caused by an unreasonable fillfactor setting. That shows why evaluation cannot rely only on default benchmark scores. Teams must also verify whether the database provides enough room for meaningful optimization.

The completeness of the toolchain often matters more than the database kernel itself

Enterprise migration is usually not a one-time DDL import. It is a continuous engineering process that includes assessment, migration, dual-track synchronization, monitoring, and rollback. KingbaseES provides a relatively complete migration path through KDMS, KDTS, and KFS, and this is a major part of its engineering competitiveness.

KDMS handles compatibility scanning, KDTS handles schema and data migration, and KFS handles heterogeneous real-time synchronization. This layered design fits systems with limited downtime windows and strict rollback requirements.

# Use KDTS to migrate from Oracle to KingbaseES
./kdts.sh -srcType oracle -srcHost 192.168.1.100 -srcPort 1521 -srcSid ORCL \
-srcUser scott -srcPwd tiger \
-destType kingbasees -destHost 192.168.1.200 -destPort 54321 \
-destUser system -destPwd manager \
-schemaList SCOTT -tableList 'SCOTT.*' -parallel 8

This command runs parallel schema and data migration and is suitable for migration rehearsals and pre-cutover stress testing.

Monitoring, BI, and application connectivity complete the last mile

A successful migration does not automatically produce an operable system. KStudio, KOPS, and KMonitor cover SQL development, instance operations, and deep monitoring, reducing the switching friction for both DBAs and development teams.

-- Enable SQL monitoring
ALTER SYSTEM SET kdb_sql_monitor.enable = on;
-- Set the slow-query threshold to help identify performance issues
ALTER SYSTEM SET log_min_duration_statement = 1000;
-- Enable the audit extension to satisfy compliance traceability requirements
CREATE EXTENSION kdb_audit;
SELECT kdb_audit.audit_enable('ddl,select,insert,update,delete');

This SQL establishes monitoring, slow-query tracking, and auditing, which are baseline capabilities for stable post-launch operations.

Standard JDBC and ODBC support are also critical. For Spring applications, BI platforms, and ETL tools, if the driver, dialect, and compatibility parameters remain stable enough, application replacement costs drop significantly.

spring.datasource.url=jdbc:kingbase8://192.168.1.200:54321/finance_db?oracleCompatible=true
spring.datasource.driver-class-name=com.kingbase8.Driver

This configuration connects a Java application to KingbaseES and explicitly enables Oracle-compatible syntax mode.

The final selection conclusion should rest on clearly defined expectations and boundaries

Overall, KingbaseES is a strong fit for three types of projects: core business systems that heavily depend on the Oracle ecosystem, database localization programs that require minute-level cutover with rollback capability, and financial or government systems with explicit high-availability and compliance-audit requirements.

Its strength is not absolute zero-refactor migration. Its strength is compressing the refactoring workload into a controllable scope and reducing end-to-end delivery risk through tooling and HA mechanisms. Teams should still run dedicated validation for very large PL/SQL codebases, heavy Oracle-specific feature usage, and extreme high-concurrency scenarios.

FAQ

1. Is KingbaseES suitable for directly replacing an Oracle core system?

It is suitable for PoC entry and phased migration, but not for direct replacement without validation. You should first assess stored procedure volume, built-in function dependencies, DBLink usage, and high-availability requirements.

2. What should teams focus on most when evaluating KingbaseES performance?

Do not look only at tpmC. You should also evaluate transaction latency, CPU and I/O consumption, WAL flush behavior, complex SQL execution plans, and post-tuning stability.

3. What are the most common pitfalls during migration?

Common issues include pagination syntax differences, failed implicit type conversion, schema misalignment, auto-increment sequence replacement, inconsistent date formats, and underestimating the synchronization cutover window.

Core Summary: This article reframes the KingbaseES evaluation process from a technical decision-making perspective, analyzing its Oracle/MySQL compatibility, high-availability architecture, TPC-C performance testing methodology, migration and monitoring toolchain, and the practical boundaries and recommendations for financial and government deployment scenarios.