What's the Difference Between Apex A5's HyperDB and Kingstar's KMDB? Two Philosophies of In-Memory Databases

📌 Core Argument Although both HyperDB and KMDB are referred to as “in-memory databases,” they play entirely different roles within their respective vendors’ architectural ecosystems. HyperDB is the core database foundation for Apex Software’s A5 “compute-storage separation and De-IOE” route, aiming to completely replace Oracle by keeping “the trading core in-memory and persistence in open-source databases.” KMDB, on the other hand, is one of the four foundational components of Kingstar’s KOCA-LDP low-latency platform, working in synergy with KGMS, HARE, and KGBP to provide FS2.5 with “microsecond-level in-memory data operations + master-slave replication + asynchronous disk DB synchronization.”

In short: HyperDB is the “nuclear weapon for De-Oracle,” while KMDB is the “storage engine for the low-latency platform.” The two differ fundamentally in positioning, architectural roles, and technical evolution paths.

I. Positioning Differences: Core Database Base vs. Low-Latency Platform Component

#

1.1 HyperDB: Apex A5’s “Nuclear Weapon for De-Oracle”

#

HyperDB (“Feichi” In-Memory Database) is an in-memory database independently developed by Apex Software since 2013. After more than a decade of refinement, it is the core pillar of the A5 Xinchuang (Domestic IT Substitution) edition’s “De-IOE” route.

Core Mission: To completely replace traditional commercial databases like Oracle.

Apex Software’s architectural philosophy is “Compute-Storage Separation”:

Transactional Data Processing ──→ HyperDB In-Memory DB (Proprietary, daytime real-time trading nodes)
                                        ↓
Persistent Data Storage ────────→ Open-source RDBMS (Domestic Xinchuang databases)

HyperDB’s Role:

• Acts as the trading core; all order-related businesses are completed in the in-memory database.
• Highlights low-latency data access and high-concurrency processing capabilities.
• Used in daytime real-time trading nodes.
• In the A5 core trading domain, it is based on a distributed in-memory database and adopts an active-active architecture.
• Memory utilizes transaction synchronization technology.

💡 Key Positioning: HyperDB’s role in the A5 ecosystem is the “core database replacing Oracle”—it must not only perform high-speed in-memory read/writes but also assume the responsibilities of traditional databases, such as consistency guarantees and SQL execution.

1.2 KMDB: Kingstar’s KOCA-LDP Storage Component

#

KMDB is Kingstar’s independently developed low-latency in-memory database. As one of the four foundational components of the KOCA-LDP platform, it works in synergy with KGMS (Microservices Gateway), HARE (High-Speed Message Bus), and KGBP (Trading Middleware).

Core Mission: To provide in-memory data operation capabilities for the KOCA-LDP low-latency platform.

KMDB’s Role:

• One of the four foundational components of KOCA-LDP (KGMS + HARE + KGBP + KMDB).
• Responsible for “efficient execution,” providing high availability, low latency, and data persistence.
• Achieves “zero-lookup, zero-data-copy,” improving query concurrency.
• Features master-slave replication and asynchronous physical database synchronization.
• Supports both OLTP and OLAP scenarios.

Application in FS2.5:

• Core Trading: As one of the three core components of K-LDP (KGMS + HARE + KMDB), KMDB handles in-memory data operations.
• Trading Settlement: FS2.5 clearing adopts KMDB in-memory database technology, achieving high-performance clearing through a compute-storage separation architecture.

💡 Key Positioning: KMDB’s role in the Kingstar ecosystem is the “in-memory storage engine for the low-latency platform”—it is a component of the KOCA-LDP platform, working with HARE, KGMS, and KGBP to build ultra-fast trading capabilities. It is not a “database replacing Oracle,” but the “in-memory data storage layer within the low-latency platform architecture.”

1.3 Summary of Positioning Differences

#

II. Architectural Philosophy Differences: Compute-Storage Separation vs. Platform Synergy

#

2.1 Apex A5: Compute-Storage Separation + De-Oracle

#

Apex A5’s architectural philosophy is “Compute-Storage Separation”:

• Compute Core: Autonomous and controllable in-memory database (HyperDB) + proprietary middleware (LiveDTP).
• Storage: Auxiliary storage databases and OS use open-source products (domestic Xinchuang databases).
• Core Idea: Weaken the role of the database, using it merely for persistent storage.

HyperDB’s Position in the Architecture:

Client Request → LiveDTP Distributed Low-Latency Middleware → HyperDB In-Memory DB (Trading Core)
                                                                        ↓
                                                                Open-source RDBMS (Persistence)

A5’s Three Domains:

1. Core Trading Domain: Based on a distributed in-memory database (HyperDB), adopting an active-active architecture.
2. Basic Business Domain: Provides fundamental business services like fund clearing, authentication, data services, and management.
3. Tech Support Domain: Configuration center, queue services, management platforms, etc.

💡 Architectural Philosophy: HyperDB is the concrete carrier of A5’s “compute-storage separation and De-IOE” route—by using an in-memory database to replace the performance part of traditional Oracle, it ensures “the trading core is in-memory, persistence is in open-source DBs,” completely breaking free from foreign commercial database dependencies.

2.2 Kingstar FS2.5: KOCA-LDP Platform Synergy

#

Kingstar FS2.5’s architectural philosophy is “Order Channel + Comprehensive Base Layering” + “Three Separations and Four Integrations”:

• Separation of trading and clearing, accounts and funds, orders and reporting.
• Integration of access, operations, data, and backend services.
• Core trading adopts the K-LDP low-latency tech platform.

KMDB’s Position in the Architecture:

Client Request → KGMS Unified Access Gateway → HARE High-Speed Message Bus → KGBP Trading Middleware
                                                                                      ↓
                                                                                 KMDB In-Memory DB
                                                                                      ↓
                                                                              Async Physical DB Sync

KOCA-LDP Four-Component Synergy:

💡 Architectural Philosophy: KMDB is not a “database replacing Oracle,” but the “in-memory data storage layer within the KOCA-LDP low-latency platform architecture”—it works with HARE, KGMS, and KGBP to build ultra-fast trading capabilities. KOCA-LDP is fully implemented in C/C++, combined with various low-latency NICs and FPGA/GPU hardware acceleration.

2.3 Core Divergence in Architectural Philosophy

#

III. Technical Feature Differences: Proprietary Kernel vs. Platform Component

#

3.1 HyperDB’s Technical Features

#

R&D History:

• Began R&D on basic in-memory databases in 2013.
• After 5 years of integration, achieved a fully proprietary in-memory database.
• Performs exceptionally well in multi-core performance, proprietary algorithms, high database reliability, and data O&M capabilities.
• Inherently possesses Xinchuang (localization) attributes.

Core Features:

• Distributed Architecture: Uses a distributed architecture to enhance overall system capabilities.
• Cross-Platform Performance: On ARM platforms, HyperDB’s query capability surpasses Intel platforms.
• Low-Latency Access: Highlights low-latency data access and high-concurrency processing.
• Active-Active Architecture: The A5 core trading domain is based on a distributed in-memory DB with an active-active setup.
• Transaction Sync: Memory employs transaction synchronization technology.
• High Availability: Multiple HA methods including service clusters and master-slave modes.

Deployment Scale:

• Deployed in hundreds of critical low-latency trading application nodes across dozens of financial institutions.
• Tested through multiple major market rallies.
• The HTS ultra-fast trading system uses HyperDB to achieve microsecond-level order processing speeds.

3.2 KMDB’s Technical Features

#

R&D History:

• Developed as a component of the KOCA-LDP platform.
• KOCA-LDP V2.0 upgraded key technologies of all foundational components.
• Overall performance metrics have entered the industry’s first tier.

Core Features:

• Microsecond/Nanosecond Response: Achieves microsecond or even nanosecond-level data operation responses.
• High Throughput: Provides millions of transactions per second (TPS).
• Traditional DB Compatibility: Features traditional database data consistency guarantees and SQL execution engine capabilities.
• Highly Reliable Modes: Supports multiple highly reliable operating modes.
• Master-Slave Replication: Features master-slave replication.
• Async Sync: Features asynchronous physical database synchronization.
• Zero-Lookup, Zero-Data-Copy: The upgraded KMDB achieves “zero-lookup, zero-data-copy,” increasing query concurrency and reducing blocking.
• Dual-Scenario Support: Main application scenarios include OLTP and OLAP.

Business Penetration Performance:

• By utilizing in-memory databases or in-memory data structures, the KOCA-LDP runtime platform achieves internal business processing latency of less than 1 microsecond.
• End-to-end latency is only 1.1 microseconds.

3.3 Technical Feature Comparison

#

IV. Application Scenario Differences: Core Trading Domain vs. Full-Scenario Coverage

#

4.1 HyperDB’s Application Scenarios

#

Main Scenario: The core trading domain of the A5 core trading system.

• Daytime Real-Time Nodes: HyperDB is used for daytime real-time trading nodes.
• Order Businesses: All order-related businesses are completed in the in-memory database.
• HTS Ultra-Fast Trading: HTS uses HyperDB for microsecond-level order processing.
• Active-Active: The A5 core trading domain uses a distributed in-memory DB with an active-active architecture.

Deployed Brokerages:

• Soochow Securities (A5 Xinchuang node first went live in 2021).
• Donghai Securities, Huabao Securities, Maiqiao Securities.
• A5 Max completed a benchmark project migrating hundreds of millions of clients for a head brokerage.

Industry Status:

• In 2020, the A5 Xinchuang edition went fully live at Soochow Securities, achieving the securities industry’s first “De-Oracle.”
• A5 Xinchuang is the industry’s only fully live, full-business distributed core trading system.

4.2 KMDB’s Application Scenarios

#

Main Scenario: Full-scenario coverage of the KOCA-LDP platform.

• Core Trading: FS2.5 orders use the K-LDP platform, with KMDB as one of the three core components.
• Trading Settlement: FS2.5 clearing uses KMDB, achieving high performance via compute-storage separation.
• Ultra-Fast Orders/Quotes: KOCA-LDP builds high-performance core systems like ultra-fast orders.
• OLTP + OLAP: KMDB supports both Online Transaction Processing and Online Analytical Processing.

Deployed Brokerages:

• CICC Wealth Securities (Centralized trading system integration).
• Huaxing Securities (FS2.5 next-gen core trading system, industry’s first tens-of-millions client migration).
• SWS (Shenwan Hongyuan) Securities (Trading settlement system integration).
• Ping An Securities (Next-gen trading order system).
• China Galaxy Securities (MTA share registration system, Kingstar’s first full-stack Xinchuang registration).

External Output:

• KMDB is not only a core foundational component for Securities FS2.5 and Asset Management A8.
• It has also been successfully output externally to meet clients’ proprietary R&D needs.

4.3 Application Scenario Comparison

#

V. Xinchuang Path Differences: De-Oracle Pioneer vs. Platform-Native Xinchuang

#

5.1 Apex’s Xinchuang Path: HyperDB De-Oracle

#

Timeline:

• 2013: Began R&D on basic in-memory databases.
• 2019: Platform adaptation, completing adaptation for HTS and A5 core trading systems.
• 2020: Won Huawei Kunpeng Xinchuang VIP Award; A5 Xinchuang went fully live at Soochow Securities, achieving the industry’s first De-Oracle.
• 2021: A5 Xinchuang node went live at Soochow Securities.
• 2023-Present: A5 live at Soochow, Donghai, Huabao, and Maiqiao Securities.

Xinchuang Strategy:

• Completely replace Oracle with HyperDB, achieving de-commercialization of the underlying database.
• HyperDB inherently possesses Xinchuang attributes.
• On ARM platforms, HyperDB’s query capability surpasses Intel platforms—indirectly proving its ARM prowess.

Core Achievements:

• A5 Xinchuang is the industry’s only fully live, full-business distributed core trading system.
• Broke the 20-year dependence of securities core trading systems on foreign commercial databases and hardware platforms.

5.2 Kingstar’s Xinchuang Path: KOCA-LDP Platform-Native Xinchuang

#

Timeline:

• KOCA-LDP V2.0: Completed key tech upgrades for all foundational components, entering the industry’s first tier.
• FS2.5 Landing: Landed in head brokerages like CICC Wealth, Huaxing, SWS, and Ping An.
• 2024: KMDB serves as a core component for FS2.5 and A8, successfully achieving external output.

Xinchuang Strategy:

• KOCA-LDP is fully implemented in C/C++.
• Combined with low-latency NICs and FPGA/GPU hardware acceleration.
• Runs on x86, ARM, and other CPU architectures.
• Fully supports Xinchuang.
• Fully adapted to mainstream domestic databases like GaussDB, OceanBase, and DM (Dameng).

Core Achievements:

• FS2.5 >50% overall project coverage in TOP 10 head brokerages.
• Huaxing Securities FS2.5 achieved the industry’s first tens-of-millions client migration case.
• Kingstar’s first full-stack Xinchuang registration (TA) case (Galaxy Securities MTA).

5.3 Xinchuang Path Comparison

#

VI. Essence of Underlying Differences: Database Product vs. Platform Component

#

6.1 Essential Difference in Product Form

#

HyperDB is a “Database Product”:

• It is a complete in-memory database product.
• Features traditional database consistency guarantees and SQL execution engines.
• Can be deployed and used independently.
• The goal is to replace traditional commercial databases like Oracle.
• Apex’s official statement: “Proprietary HyperDB in-memory database achieves underlying database de-commercialization.”

KMDB is a “Platform Component”:

• It is one of the four foundational components of the KOCA-LDP platform.
• Must work in synergy with KGMS, HARE, and KGBP to deliver full value.
• It is the “in-memory data storage layer within the low-latency platform architecture.”
• The goal is to provide in-memory data operation capabilities for the KOCA-LDP platform.
• Kingstar’s official statement: “KOCA-LDP foundational components include the microservices gateway KGMS, high-speed message bus HARE, trading middleware KGBP, and in-memory database KMDB.”

6.2 Essential Difference in Evolution Path

#

HyperDB’s Evolution: From “Basic In-Memory DB” to “Feichi HyperDB” to “A5 Core Trading Domain Base”

• R&D started in 2013.
• 5 years of integration to achieve full proprietary status.
• Launched the “Feichi” HyperDB product.
• Serves as the core database base for the A5 Xinchuang edition.
• Deployed in hundreds of critical low-latency trading nodes across dozens of financial institutions.

KMDB’s Evolution: From “In-Memory DB” to “KOCA-LDP Component” to “Externally Output Core Component”

• Developed as a component of the KOCA-LDP platform.
• KOCA-LDP V2.0 upgraded key technologies of all foundational components.
• Achieved “zero-lookup, zero-data-copy.”
• Serves not only as a core component for FS2.5 and A8 but also successfully achieved external output.

6.3 One-Sentence Summary of Differences

#

💡 HyperDB is a “proprietary in-memory database product born for De-Oracle”—the problem it solves is “how to replace Oracle with a proprietary in-memory database.”

💡 KMDB is an “in-memory storage component born for the low-latency platform”—the problem it solves is “how to achieve microsecond-level in-memory data operations within the KOCA-LDP platform architecture.”

VII. Selection Perspective: When to Choose HyperDB vs. KMDB

#

7.1 Scenarios for Choosing HyperDB

#

✅ Prioritize HyperDB in the following scenarios:

1. Core Goal is De-Oracle: Need to completely break free from Oracle dependency; HyperDB is the industry’s first verified feasible De-Oracle solution.
2. Compute-Storage Separation Architecture: Accept the paradigm of “trading core in-memory (HyperDB) + persistence in open-source DBs.”
3. Active-Active Requirement: The A5 core trading domain natively supports active-active architecture.
4. ARM Platform Priority: HyperDB’s query capability on ARM surpasses x86, ideal for the domestic ARM route.
5. Apex A5 Ecosystem: Already chosen or leaning towards the Apex A5 Xinchuang edition.

Representative Cases: Soochow Securities (First De-Oracle in 2020), Donghai, Huabao, Maiqiao Securities; A5 Max head brokerage hundreds-of-millions migration.

7.2 Scenarios for Choosing KMDB

#

✅ Prioritize KMDB in the following scenarios:

1. KOCA-LDP Platform Ecosystem: Need the complete low-latency platform capabilities of HARE message bus, KGMS gateway, KGBP middleware, and KMDB.
2. Full-Scenario Coverage: Core trading, clearing, ultra-fast orders/quotes, OLTP, OLAP across all scenarios.
3. External Output Requirement: Need to output in-memory database components externally; KMDB already supports this.
4. Kingstar FS2.5/A8 Ecosystem: Already chosen or leaning towards Kingstar’s next-gen core trading/investment trading systems.
5. Microsecond Certainty: HARE end-to-end 1.1 μs, KMDB business penetration <1 μs deterministic performance.

Representative Cases: CICC Wealth, Huaxing Securities, SWS, Ping An Securities, Galaxy Securities MTA.

7.3 Coexistence and Complementarity

#

It is worth noting that HyperDB and KMDB are not mutually exclusive—they belong to different vendors’ ecosystems:

• Choose Apex A5 → Inevitably use HyperDB.
• Choose Kingstar FS2.5/A8 → Inevitably use KMDB.
• Choose Hundsun UF3.0 → Use LightDB/UFT-MDB.
• Choose HuaRui ATP T7 → Use AMI in-memory computing.

When brokerages select core trading systems, they first choose the overall technical route (vendor), and only then the in-memory database component. The difference between HyperDB and KMDB is essentially the concretization of the differences between the Apex A5 route and the Kingstar FS2.5 route at the in-memory database layer.

VIII. Conclusion: The Essence of the In-Memory Database Route Debate

#

Back to the core question at the beginning: What is the difference between Apex A5’s HyperDB and Kingstar’s KMDB?

💡 They are not competitors on the same classification dimension. HyperDB is the core database base for Apex A5’s “compute-storage separation and De-IOE” route, aiming to completely replace Oracle; KMDB is one of the four foundational components of Kingstar’s KOCA-LDP low-latency platform, working with KGMS, HARE, and KGBP to provide FS2.5 with in-memory data operation capabilities.

Three Core Differences:

1. Positioning: HyperDB is a “database product” (replacing Oracle); KMDB is a “platform component” (KOCA-LDP’s storage engine).
2. Architectural Role: HyperDB acts as the active-active in-memory database for the A5 core trading domain; KMDB synergizes with three other components in KOCA-LDP, covering core trading, clearing, and ultra-fast orders/quotes.
3. Xinchuang Path: HyperDB uses “De-Oracle” as the entry point, achieving the industry’s first De-Oracle at Soochow Securities in 2020; KMDB uses the “KOCA-LDP platform native Xinchuang” path, fully supporting Xinchuang and available for external output.

A Consensus:

📌 Author’s Note: The difference between HyperDB and KMDB is essentially the difference in architectural philosophy between Apex Software and Kingstar Information Technology for core trading systems. Apex chose “compute-storage separation and De-Oracle,” using HyperDB to completely replace Oracle, keeping the trading core in-memory and persistence in open-source DBs. Kingstar chose the “KOCA Cloud-Native Platform + K-LDP Low-Latency Platform,” using KMDB as one of the four KOCA-LDP components, synergizing with HARE, KGMS, and KGBP to build ultra-fast trading capabilities.

There is no absolute superiority between these two routes:

• If you pursue thorough De-Oracle, compute-storage separation architecture, and an active-active trading domain → HyperDB + A5 is the purer “De-IOE answer.”
• If you pursue complete synergy of a low-latency platform, full-scenario coverage, and externally outputtable components → KMDB + KOCA-LDP + FS2.5 is the more engineered “platform answer.”

By the 2027 Xinchuang deadline, both routes will become viable choices for the Xinchuang substitution of brokerages’ core trading systems. HyperDB represents “autonomous and controllable at the database layer”—proving domestic in-memory databases can completely replace Oracle; KMDB represents “autonomous and controllable at the platform layer”—proving domestic low-latency platforms can achieve microsecond-level performance and fully support Xinchuang. Together, they are driving the historic leap of China’s securities core trading systems from “IOE dependency” to “full-stack Xinchuang.”

Appendix: HyperDB vs KMDB Technical Comparison Cheat Sheet

#