📌 Core Argument The Xinchuang (Domestic IT Substitution) of securities core trading systems is essentially a foundational battle to “De-Oracle.” The decisive factor in this battle is the choice of the in-memory database technical route. Currently, the market has formed four distinct technical routes: Apex’s “Full In-Memory Trading + External Persistence”, Kingstar’s “Industry-Tailored In-Memory Database within the Low-Latency Platform”, Hundsun’s “HTAP Converged Database with Embedded In-Memory Engine”, and HuaRui’s “Message-Driven + In-Memory Computing” ultra-fast route.
Each of the four routes has its own philosophy, but they all converge on the same goal: “microsecond-level latency + autonomous and controllable.”
I. Why “In-Memory Databases” are the Decisive Factor in Securities Xinchuang#
1.1 The Three Shackles of Traditional Architecture#
China’s securities centralized trading systems have historically relied heavily on the technical architectures of major US IT companies, specifically high dependence on foreign commercial databases and specific commercial hardware platforms. This dependency brings three shackles:
- Performance Shackles: Oracle’s latency is difficult to compress further under extreme high-concurrency scenarios, failing to meet microsecond-level trading demands.
- Cost Shackles: Oracle’s commercial licensing fees are exorbitant and increase annually.
- Security Shackles: The underlying core systems are uncontrollable, failing to meet the autonomous and controllable requirements of Xinchuang.
1.2 The Breakthrough Logic of the In-Memory Database Route#
The distributed in-memory database route effectively solves this dilemma—enhancing reliability while avoiding latency issues caused by software performance.
Its core philosophy is: Replace the performance-sensitive parts during trading hours with an in-memory database, and replace the post-trading query and storage functions with domestic Xinchuang databases or other open-source databases. This uses architectural means to lower the performance requirements for a single monolithic database and reduces the risk of system crashes based on distributed databases.
1.3 The Divergence of the Four Vendors’ Routes#
2020 was a key turning point—Hundsun launched UF3.0 (equipped with LightDB + Light-LDP), Kingstar launched FS2.0/FS2.5 (proprietary apps + K-LDP platform), and Apex launched the A5 Xinchuang edition (proprietary HyperDB in-memory database). The three vendors made three different engineering choices for the in-memory database route. Combined with HuaRui ATP T7’s message-driven route, this constitutes the “Four Routes of In-Memory Databases” for securities core trading systems.
II. Route 1: Apex HyperDB — The “Full In-Memory Trading + External Persistence” De-Oracle Route#
2.1 Engineering Philosophy: Compute-Storage Separation, Thorough De-Oracle#
Apex Software’s route is the most radical—completely breaking free from traditional commercial database dependencies.
Its core architectural philosophy is:
Daytime Real-Time Trading ──→ HyperDB In-Memory Database (Completely replaces Oracle)
↓
Post-Trading Query/Storage ──→ Domestic Xinchuang DB or Open-Source RDBMSApex A5 adopts a compute-storage separation trading architecture: computation is completed in the middleware and in-memory database, weakening the role of the database to merely persistent storage. Data storage design is divided into transactional data processing and persistent data storage, using Apex’s proprietary HyperDB in-memory database and an open-source RDBMS, respectively.
2.2 The Technical Base of HyperDB#
- R&D Starting Point: In 2013, the company decided to independently develop the “Feichi” in-memory database, HyperDB.
- Architectural Features: Distributed architecture, multi-core performance optimization, proprietary algorithms, high reliability, and inherent Xinchuang attributes.
- Platform Adaptation: Fully adapted to the Xinchuang environment. It performs exceptionally well in mixed ARM/x86 Xinchuang environments like Kunpeng and Hygon. On ARM platforms, HyperDB’s query capability surpasses Intel platforms.
- High Availability: A5 trading nodes use active-active technology; memory employs transaction synchronization technology, along with multiple HA methods like service clusters and master-slave modes.
2.3 Ultimate Evolution: HTS 2X Pure-Blood Xinchuang Edition#
In December 2024, Apex released the HTS 2X Pure-Blood Xinchuang Edition, pushing “compute-storage separation” to the extreme:
💡 HyperDB + Tencent Cloud TDSQL Combination: By combining the proprietary in-memory database HyperDB with Tencent Cloud’s TDSQL, it achieves the separation of real-time in-memory computing for trading data and the storage of trading flow data. Single order processing time is reduced to under 10 microseconds, and full-link latency is less than 30 microseconds; meanwhile, comprehensive performance such as data query and storage efficiency is improved by 30%.
2.4 Benchmark Implementations#
- Soochow Securities: The A5 Xinchuang edition went fully live, achieving the industry’s first comprehensive “De-Oracle” (i.e., no reliance on Oracle), reducing trading latency from 10ms to <1ms.
- CITIC Securities: The A5 Max Super Edition completed the benchmark project of migrating hundreds of millions of clients for a head brokerage.
- Soochow, Donghai, Huabao, etc. (4 brokerages): Achieved full-client, full-business, full-stack Xinchuang.
2.5 The Essence of the Route#
📌 The Essence of the Apex Route: It is not “replacing Oracle with a domestic database,” but “using architectural restructuring to eliminate the very need for Oracle”—through compute-storage separation, letting the in-memory database handle all performance-sensitive real-time computing, and letting the domestic RDBMS do only what it’s best at: persistent storage. This is a “drastic but effective” (釜底抽薪) De-Oracle route.
III. Route 2: Kingstar KMDB — The “Industry-Tailored In-Memory Database” within the Low-Latency Platform#
3.1 Engineering Philosophy: Synergy of the K-LDP Trio#
Kingstar’s approach is completely different from Apex’s. KMDB is not an isolated in-memory database, but one of the three core components of the K-LDP Low-Latency Platform:
K-LDP Low-Latency Platform
├── KGMS: Unified access, isolating external clients from internal servers
├── HARE: High-speed message bus, end-to-end latency <1.1 microseconds
└── KMDB: Industry-tailored in-memory databaseThe combination of the three achieves high performance, high concurrency, and high reliability in trading.
3.2 Technical Features of KMDB#
Kingstar officially positions KMDB as an “industry-tailored in-memory database”:
- Traditional Database Capabilities: Features traditional database data consistency guarantees and SQL execution engine functions.
- Highly Reliable Operating Modes: Supports multiple highly reliable operating modes.
- Synergy with External Databases: Can synchronize with various disk databases.
- Compute-Storage Separation Architecture: FS2.5 clearing adopts KMDB in-memory database technology, achieving high clearing performance through a compute-storage separation architecture design.
3.3 Dual-Scenario Application of KMDB#
KMDB plays a dual role in FS2.5:
| Scenario | Application Method | Architectural Features |
|---|---|---|
| Trading Orders | Synergy of KGMS + HARE + KMDB trio | High performance, high concurrency, high reliability |
| Trading Clearing | KMDB compute-storage separation architecture | Flexible allocation of computing and storage, distributed elastic scaling |
3.4 Continuous Evolution#
- 2023 Annual Report: Outputted the proprietary in-memory database KMDB based on the KOCA platform to head brokerage clients.
- First Half of 2024: FS2.5 adopted KMDB for new order and new clearing systems, further improving performance.
- August 2024: FS2.5 fully inherited and developed; KMDB continues to iterate as a core component of the K-LDP platform.
- August 2026: Kingstar and Huawei joined forces; KMDB + HARE + KGMS ensure system high reliability through HARE’s multi-active election mechanism and KGBP’s master-slave follow multi-active architecture.
3.5 Benchmark Implementations#
- CICC Wealth: Xinchuang first-generation core trading counter.
- CSC (China Securities), Zhongtai Securities: Overall counter projects.
- Galaxy, GF Securities: Batch landing of FS2.5 full-stack domestication solutions.
- Ping An Securities: Next-generation trading order system.
3.6 The Essence of the Route#
📌 The Essence of the Kingstar Route: KMDB is not meant to “replace” Oracle, but to “synergize with HARE within the K-LDP low-latency platform to form a complete low-latency trading solution.” KMDB is an industry-tailored in-memory database that is deeply coupled with KGMS and HARE, forming Kingstar’s native Xinchuang “Iron Triangle.” This is a “platformized” in-memory database route.
IV. Route 3: Hundsun LightDB — The “HTAP Converged Database with Embedded In-Memory Engine”#
4.1 Engineering Philosophy: Multi-Storage Engine Convergence#
Hundsun’s approach is different from the previous two. LightDB is not a pure in-memory database, but a converged distributed database that supports both Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP).
Its core innovation is the multi-storage engine architecture:
LightDB Converged Database
├── LightSQL: SQL coordination layer (receives requests, compiles SQL, global transaction coordination)
├── GCS: Global resource and transaction management service
├── LightTP: Online storage engine (traditional database functions)
├── LightMEM: In-memory storage engine (microsecond-level transaction processing)
└── LightAP: Analytical storage engine (big data statistical analysis)The LightMEM in-memory storage engine is the “in-memory database” component of LightDB—mainly designed for highly latency-sensitive trading and risk control scenarios, providing both API direct connection and SQL access interfaces, aiming to provide microsecond-level transaction processing responses.
4.2 Financial-Grade Features of LightDB#
- Financial Scenario Optimization: Speed and security are the most important features. LightDB ensures that when throughput reaches 50,000 TPS, latency remains stable at 5-8 milliseconds.
- Architectural Design: Separation of compute and storage, supports multiple storage engines, multi-replica high availability.
- Differentiated Consistency Control: Supports differentiated consistency control from the table, transaction, to instance level, ensuring that performance and consistency demands are balanced on the basis of decoupling.
- Xinchuang Adaptation: Supports domestic OS like Kylin Linux and openEuler; supports domestic processors like Huawei Kunpeng ARM and Hygon x86; transparent data encryption supports national cryptographic standards.
- Strong Compatibility: Compatible with Oracle and MySQL, retaining core PostgreSQL performance.
4.3 Role in UF3.0#
Hundsun UF3.0 relies on the JRES3.0 cloud-native base, proprietary LDP low-latency platform, and MDB in-memory database to build a comprehensive trading system. As a converged database, LightDB plays a dual role in UF3.0: core data storage and real-time computing.
4.4 Benchmark Implementations#
- China Merchants Securities (CMS): Fully launched UF3.0 in July 2025, completing a full switchover for millions of clients. It is the industry’s first system overall landing based on a cloud-native architecture supporting millions of clients.
- Soochow Securities: The first to cooperate and land the “TA + LightDB” Xinchuang project with Hundsun.
- Overall Scale: 11 brokerages have gone live, over 20 signed partner institutions, and the cumulative scale of existing clients served has broken through 50 million.
4.5 The Essence of the Route#
📌 The Essence of the Hundsun Route: It does not purely pursue “in-memoryization,” but rather “convergence”—LightDB provides microsecond-level responses through the LightMEM in-memory engine, but provides HTAP convergence capabilities through the synergy of different storage engines like LightTP and LightAP. This is a “converged” route that solves all problems within the database, rather than a “compute-storage separation, each doing its own job” route.
V. Route 4: HuaRui ATP T7 — The Ultra-Fast Route of “Message-Driven + In-Memory Computing”#
5.1 Engineering Philosophy: Message-Driven, Not Database-Driven#
HuaRui’s route is fundamentally different from the previous three—it is not centered on an in-memory database, but on the proprietary low-latency message bus AMI:
AMI Message Bus (Microsecond-level communication)
↓
Message-Driven + Reliable In-Memory Computing + Multi-Shard Concurrent Processing
↓
In-Memory Computing + Distributed Storage5.2 Ultra-Fast Performance#
- Internal System Processing Latency: Less than 80μs.
- Single-Node Mixed Load Throughput: Greater than 1.6 million TPS.
- Trading Latency: Microsecond-level.
- Concurrency Capability: Supports 100 million+ securities accounts.
- Availability: Multi-active cluster, second-level failover, 99.999% availability.
- Guotai Junan: Trading speed improved by over 20 times.
- Guosen Securities: Trading latency reduced to 50μs, throughput improved by hundreds of times.
5.3 Essential Differences from the Previous Three#
| Dimension | Apex / Kingstar / Hundsun | HuaRui ATP T7 |
|---|---|---|
| Core Driving Force | In-Memory Database | Message Bus AMI |
| Architectural Philosophy | Compute-Storage Separation or Converged DB | Message-Driven + In-Memory Computing |
| Main Battlefield | Retail Core Trading Full Business | Ultra-Fast Trading, Quantitative Orders |
| De-Oracle Method | In-Memory DB replaces Oracle | Bypasses the database, message bus direct drive |
5.4 The Essence of the Route#
📌 The Essence of the HuaRui Route: In the “in-memory database” competition, it has forged a “non-database” route—building a message-driven architecture through the proprietary world-class distributed low-latency message middleware AMI. Reliable in-memory computing is completed directly at the message layer, fundamentally bypassing the reliance on traditional databases. This is the optimal solution for ultra-fast trading scenarios.
VI. Ten-Dimensional Deep Comparison of the Four Routes#
| Comparison Dimension | Apex HyperDB | Kingstar KMDB | Hundsun LightDB | HuaRui ATP T7 |
|---|---|---|---|---|
| Route Label | Full In-Memory + External Persistence | Industry-Tailored within Low-Latency Platform | HTAP Converged DB with Embedded In-Memory Engine | Message-Driven + In-Memory Computing |
| Core Components | HyperDB + LiveDTP | KMDB + HARE + KGMS | LightMEM + LightTP + LightAP | AMI Message Bus |
| De-Oracle Method | Thorough Replacement (Eliminating root cause) | Platformized Synergistic Replacement | Converged Compatibility (Oracle compat. mode) | Bypassing the database |
| Arch. Philosophy | Compute-Storage Separation | Multi-Component Synergy within Platform | Compute-Storage Separation + Multi-Engine Convergence | Message-Driven + In-Memory Computing |
| Latency Performance | Single order <10μs, full link <30μs | HARE end-to-end <1.1μs | 5-8ms at 50k TPS | Internal <80μs, Guosen down to 50μs |
| Throughput | Linear scaling with nodes | Distributed elastic scaling | Stable at 50k TPS | Single node >1.6 million TPS |
| SQL Capability | In-Memory DB + External Open-Source DB synergy | Features SQL execution engine | Full SQL compatibility (Oracle/MySQL) | Primarily in-memory computing |
| High Availability | Active-Active + Transaction Sync | HARE multi-active election + KGBP master-slave | Multi-replica RTO≤30s, RPO=0 | Multi-active cluster, 99.999% |
| Xinchuang Adaptation | Kunpeng/Hygon, ARM surpasses x86 | Deep adaptation with Kunpeng/Ascend | Kunpeng/Hygon + Kylin/openEuler | Deep cooperation with Huawei Kunpeng |
| Representative Cases | Soochow De-Oracle, CITIC A5 Max | CICC Wealth, CSC | CMS UF3.0, Soochow TA | Guotai Junan, Guosen Securities |
| Applicable Scenarios | Retail Core Full Business De-Oracle | Overall Counter New Build + Low-Latency | Full Business Comprehensive Platform + Smooth Migration | Ultra-Fast Trading, Quantitative Orders |
VII. The Underlying Logical Opposition of the Four Routes#
7.1 “Compute-Storage Separation” vs. “Converged Database”#
Both Apex and Kingstar chose the compute-storage separation architecture, but their implementation paths differ:
- Apex: HyperDB only handles daytime real-time computing; persistence is completely handed over to external domestic/open-source databases—this is “extreme specialized division of labor.”
- Kingstar: KMDB synergizes with HARE and KGMS within the K-LDP platform, but the clearing scenario still adopts compute-storage separation—this is “division of labor within the platform.”
Hundsun took the opposite path—LightDB completes all OLTP, in-memory computing, and OLAP work within a single database through multiple storage engines (LightMEM/LightTP/LightAP), which is “converged integration.”
7.2 “Thorough De-Oracle” vs. “Oracle Compatibility”#
- Apex: Thorough De-Oracle. HyperDB completely replaces Oracle. A5 is the industry’s first core trading system to achieve comprehensive De-IOE.
- Hundsun: LightDB is compatible with Oracle and MySQL, retaining core PostgreSQL performance—this is “compatible De-Oracle” designed for smooth migration of the existing ecosystem.
- Kingstar: KMDB synchronizes with various disk databases; brokerages can independently choose domestic infrastructure—this is “open De-Oracle.”
7.3 “Database-Driven” vs. “Message-Driven”#
The first three routes are essentially “database-driven”—building trading systems centered on in-memory databases. HuaRui completely jumps out of this paradigm: centered on the message bus AMI, in-memory computing is completed directly at the message layer.
This reflects two different engineering philosophies:
💡 Database-Driven Camp (Apex/Kingstar/Hundsun): Believes “data” is the core, solving performance problems through in-memory databases.
💡 Message-Driven Camp (HuaRui): Believes “flow” is the core, solving performance problems through message buses.
VIII. Selection Decision: Recommended Paths for Four Types of Brokerages#
8.1 Head Brokerages (Millions of clients, comprehensive De-Oracle demand)#
Recommended: Apex A5 Max Route
- CITIC Securities chose A5 Max to complete the migration of hundreds of millions of clients, proving the feasibility of this route at an ultra-large scale.
- HyperDB’s thorough De-Oracle meets the highest demand for autonomous controllability of head brokerages.
- The compute-storage separation architecture scales linearly in mixed Kunpeng/Hygon environments.
8.2 Overall Counter New Build (Mid-to-Large brokerages, low-latency demand)#
Recommended: Kingstar FS2.5 + KMDB Route
- K-LDP platform trio synergy, HARE end-to-end latency <1.1 microseconds.
- FS2.5 has been batch-landed in overall counter projects for head brokerages like CICC, Galaxy, and GF.
- Native Xinchuang, no extra retrofit needed; brokerages can independently choose domestic infrastructure.
8.3 Smooth Migration of Existing Ecosystem (Hundsun legacy clients)#
Recommended: Hundsun UF3.0 + LightDB Route
- LightDB is compatible with Oracle and MySQL; the lowest cost for existing migration.
- UF3.0’s “Bimodal IT (Agile & Stable)” architecture supports smooth Xinchuang transition.
- CMS’s millions-level client full switchover has verified its feasibility.
8.4 Ultra-Fast Trading / Quantitative Orders (Specific Scenarios)#
Recommended: HuaRui ATP T7 Route
- Internal system processing latency <80μs, single-node mixed load throughput >1.6 million TPS.
- Guotai Junan’s trading speed improved by over 20 times.
- Over 100 production systems online and running.
8.5 “Core + Ultra-Fast” Dual-Engine Architecture (Head Brokerage Trend)#
More and more head brokerages are choosing a “Core Trading System + Ultra-Fast Trading System” dual-engine architecture:
Core Trading System (Carries full business)
├── Apex A5 Max / Kingstar FS2.5 / Hundsun UF3.0
└── In-Memory DB: HyperDB / KMDB / LightDB
Ultra-Fast Trading System (Carries quantitative orders)
└── HuaRui ATP T7 + AMI Message BusThis “Core + Ultra-Fast” dual-engine architecture is becoming the standard configuration for head brokerages’ core systems.
IX. 2027 Final Verdict: The Attack and Defense of the Four Routes#
9.1 Apex HyperDB: Attacking the “Thorough De-Oracle” Highlands#
Apex’s route is the most radical, but also the most convincing in terms of autonomous controllability. A5 Max’s completion of hundreds of millions of client migrations at CITIC Securities proves the engineering feasibility of the “compute-storage separation + HyperDB” route at an ultra-large scale. As the 2027 Xinchuang deadline approaches, the demand for thorough De-Oracle will drive more head brokerages to choose the Apex route.
9.2 Kingstar KMDB: Defending the “Low-Latency Platform” Position#
Kingstar KMDB’s moat lies not in the in-memory database itself, but in the complete ecosystem of the K-LDP low-latency platform—the synergy effect of the KGMS + HARE + KMDB trio. HARE’s end-to-end latency of <1.1 microseconds is the overall value that a standalone KMDB cannot provide. The Kingstar route has a leading advantage in overall counter new-build projects.
9.3 Hundsun LightDB: Defending the “Existing Ecosystem” Base#
Hundsun UF3.0 has cumulatively served over 50 million clients, with 11 brokerages live and over 20 signed partner institutions. LightDB’s Oracle compatibility makes it the optimal choice for smooth migration of Hundsun’s existing clients. Compatible De-Oracle might not be the most thorough, but it is the steadiest route.
9.4 HuaRui ATP T7: Attacking the “Ultra-Fast Niche” Track#
HuaRui does not take the path of “replacing Oracle,” but the path of “bypassing the database.” In niche tracks like quantitative trading and ultra-fast orders, HuaRui is irreplaceable. Over 100 production systems online prove the commercial viability of the message-driven route.
9.5 The Fundamental Reason for the Coexistence of the Four#
The four routes are not a zero-sum game, but coexist in layered scenarios:
Ultra-Fast Trading Layer (Microsecond-level) ──→ HuaRui ATP T7 (Message-Driven)
↓
Core Trading Layer (Millisecond-level) ────────→ Apex A5 / Kingstar FS2.5 / Hundsun UF3.0
↓
Persistent Storage Layer ──────────────────────→ Domestic RDBMS (OceanBase / TDSQL / Kingbase, etc.)Each layer has the most suitable technical route, and each vendor has built barriers at the layer they are best at.
X. Conclusion: The “Xinchuang Philosophy” of In-Memory Database Routes#
Back to the core question at the beginning—Apex HyperDB, Kingstar KMDB, Hundsun LightDB, HuaRui ATP T7, what exactly are the essential differences among the four in-memory database routes?
💡 Four Routes, Four Philosophies:
- Apex HyperDB: Answers “how to completely break free from Oracle” with “Compute-Storage Separation + Thorough De-Oracle.”
- Kingstar KMDB: Answers “how to build a native Xinchuang overall counter” with “Synergy of the Low-Latency Platform Trio.”
- Hundsun LightDB: Answers “how to smoothly migrate the existing ecosystem” with “HTAP Convergence + Oracle Compatibility.”
- HuaRui ATP T7: Answers “how to achieve microsecond-level ultra-fast trading” with “Message-Driven + In-Memory Computing.”
These four philosophies have no absolute superiority or inferiority, only scenario adaptation. Apex suits head brokerages pursuing thorough De-Oracle; Kingstar suits mid-to-large brokerages building new overall counters; Hundsun suits smooth migration of existing ecosystems; HuaRui suits ultra-fast trading niche scenarios.
Before the 2027 Xinchuang deadline, the four routes will jointly drive one thing—making the “heart” of China’s securities core trading systems beat entirely to the code of China’s own. When Soochow Securities’ trading latency drops from 10ms to <1ms, when HuaRui ATP T7 achieves a 20x speed increase at Guotai Junan, when CMS UF3.0 completes a full switchover for millions of clients—behind these numbers is the history of China’s securities Xinchuang written jointly by the four in-memory database routes.
📌 Author’s Note: The choice of the in-memory database route is essentially a brokerage CIO’s trade-off between the “degree of autonomous controllability” and “migration risk.” Apex bets on the long-term benefits of “thorough De-Oracle,” Kingstar bets on the overall value of “platformized synergy,” Hundsun bets on the existing dividend of “compatible smoothness,” and HuaRui bets on the niche barrier of “ultra-fast specialization.” Four bets, four futures—and history will prove that on the exam paper of the 2027 Xinchuang deadline, there are no wrong routes, only unsuitable scenarios.