From HyperDB to LightDB: The Four Routes of Proprietary In-Memory Databases in Securities Core Trading Systems

📌 Core Argument The Xinchuang (Domestic IT Substitution) transformation of securities core trading systems has spawned four routes of proprietary in-memory databases: Apex HyperDB (the nuclear weapon for De-Oracle), Kingstar KMDB (the low-latency platform component), Hundsun UFT-MDB/LightDB (the Agile-Stable Bimodal dual engines), and HuaRui AMI (the ultra-fast trading memory computing platform).

These four routes are not simply about which technology is superior; rather, they represent different vendors’ answers to the fundamental question: “What data architecture should the core trading system use?” Understanding these four routes means understanding all the technical options for the Xinchuang substitution in the securities core trading systems over the next five years.

I. Background: Why Do Securities Core Trading Systems Need Proprietary In-Memory Databases?

#

1.1 Bottlenecks of the Traditional Architecture

#

Securities core trading systems have long relied on Oracle databases + centralized architectures. With the explosive growth in trading volumes (trillion-level daily turnover in A-shares), the rise of quantitative trading (microsecond-level latency requirements), and the approaching Xinchuang deadline (100% substitution by 2027), the traditional architecture faces a triple dilemma:

• Performance Bottleneck: Disk I/O has become the throughput ceiling; millisecond-level latency cannot meet the demands of ultra-fast trading.
• Cost Bottleneck: Oracle licensing fees are exorbitant, and IBM mainframe/minicomputer O&M costs remain high.
• Xinchuang Bottleneck: Oracle is not on the Xinchuang catalog; domestic alternatives must be found.

1.2 The Breakthrough of In-Memory Databases

#

In-memory databases load all data into memory, eliminating disk I/O and achieving microsecond-level read/write speeds. However, financial-grade in-memory databases face three major challenges:

• Data Consistency: Memory is volatile; how to guarantee no data loss during a power outage?
• High Availability: How to achieve seamless failover when a single node fails?
• SQL Compatibility: How to be compatible with existing Oracle business logic?

Different vendors have provided different answers, forming four distinct routes.

II. Panorama of the Four Routes

#

III. Deep Dive into the Four Routes

#

3.1 Route 1: Apex HyperDB — The Nuclear Weapon for De-Oracle

#

Positioning: The core database base for A5/LiveDTP, with the goal of completely replacing Oracle.

Architectural Philosophy: Compute-Storage Separation + Active-Active

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

Technical Features:

• Proprietary Kernel: R&D started in 2013, achieving full proprietary status after 5 years of integration.
• Active-Active Architecture: The A5 core trading domain is based on a distributed in-memory database, adopting an active-active setup.
• Transaction Sync: Memory employs transaction synchronization technology to ensure data consistency.
• ARM Optimization: On ARM platforms, query capability surpasses Intel platforms.
• Inherent Xinchuang: HyperDB inherently possesses Xinchuang attributes.

Key Achievements:

• Went fully live at Soochow Securities in 2020, achieving the securities industry’s first “De-Oracle.”
• The A5 Xinchuang edition is the industry’s only fully live, full-business distributed core trading system.
• Deployed in hundreds of critical low-latency trading application nodes across dozens of financial institutions.

Representative Cases: Soochow Securities, Donghai Securities, Huabao Securities, Maiqiao Securities, A5 Max head brokerage hundreds-of-millions client migration.

3.2 Route 2: Kingstar KMDB — The Storage Engine for the Low-Latency Platform

#

Positioning: One of the four foundational components of the KOCA-LDP low-latency platform, working in synergy with KGMS, HARE, and KGBP.

Architectural Philosophy: Platform Synergy + Full-Scenario Coverage

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

Technical Features:

• Microsecond/Nanosecond Response: Achieves microsecond or even nanosecond-level data operation responses.
• Zero-Lookup, Zero-Data-Copy: Upgraded to improve query concurrency and reduce blocking.
• SQL Execution Engine: Features traditional database data consistency guarantees and SQL execution engine capabilities.
• Master-Slave Replication + Async Sync: Supports multiple highly reliable operating modes.
• OLTP + OLAP Dual Scenarios: Simultaneously supports Online Transaction Processing and Online Analytical Processing.

Key Achievements:

• KOCA-LDP overall end-to-end latency is 1.1 μs; KMDB business penetration is <1 μs.
• FS2.5 >50% overall project coverage in TOP 10 head brokerages.
• KMDB not only serves as a core foundational component for FS2.5 and A8 but has also been successfully output externally.

Representative Cases: CICC Wealth, Huaxing Securities (Industry’s first full-stack Xinchuang single-track complete counter), SWS, Ping An Securities, Galaxy MTA.

3.3 Route 3: Hundsun UFT-MDB + LightDB — Agile-Stable Dual Engines

#

Positioning: Under Hundsun’s UF3.0 “Bimodal IT (Agile and Stable)” architecture, the in-memory trading engine (UFT-MDB) handles ultra-fast trading, while the distributed database (LightDB) handles persistence and general business.

Architectural Philosophy: Dual-Track Parallel + Agile-Stable Separation

Stable Mode (Secure & Stable): LightDB Distributed DB (Accounts, Clearing, Risk Control)
Agile Mode (Rapid Iteration): UFT-MDB In-Memory DB (Trading Core)

Technical Features:

• UFT-MDB: Core processing latency <50 μs; single-node pure order throughput 150,000 TPS.
• LightDB: Financial-grade distributed database, supporting OLTP and OLAP fusion, featuring high SQL compatibility, elastic capacity scaling, and financial-grade high availability.
• Agile-Stable Bimodal: Trading and clearing are the stable mode; accounts and operations are the agile mode. The two types of databases perform their respective duties.
• Full-Stack Xinchuang: Completed full-stack Xinchuang adaptation from chips and servers to databases.

Key Achievements:

• UF3.0 has gone live in 11 brokerages; China Merchants Securities completed a full switchover for millions of clients.
• Founder Securities achieved the industry’s first full-stack Xinchuang for in-memory trading.
• Overall processing capacity increased by 70 times compared to the previous generation.

Representative Cases: China Merchants Securities (Millions-level client switchover), Orient Securities (Full-client, full-business launch), Founder Securities (First in-memory trading full-stack Xinchuang), Caixin Securities (First identical-structure options in-memory trading).

3.4 Route 4: HuaRui AMI — The Memory Computing Platform for Ultra-Fast Trading

#

Positioning: The core infrastructure of HuaRui’s ATP distributed ultra-fast trading platform, focusing on memory messaging and computing for ultra-fast trading scenarios.

Architectural Philosophy: Native Distributed + Low-Latency Message Bus

Client Request → AMI Memory Message Bus (Distributed, Agentless, Microsecond-level)
                        ↓
                 AMI Memory Computing Engine (Order Processing, Risk Control, Quotes)

Technical Features:

• AMI Memory Message Bus: End-to-end latency <1 μs; supports reliable multicast and unicast.
• Full-Stack Proprietary: Completely self-developed from the message bus to the memory computing engine.
• Hardware Acceleration: Supports RDMA, FPGA, and other acceleration technologies.
• Distributed Architecture: Supports horizontal scaling with no single point of failure.

Key Achievements:

• Over 100 ATP online production systems.
• Outstanding performance advantages in the quantitative and high-frequency trading segments.
• Used by multiple head brokerages for ultra-fast counters and algorithmic trading systems.

Representative Cases: Ultra-fast trading counters of multiple head brokerages, quantitative private fund trading systems.

IV. Four-Dimensional Deep Comparison

#

4.1 Positioning & Architectural Role

#

4.2 Architectural Philosophy

#

4.3 Performance Metrics

#

4.4 Xinchuang Path

#

4.5 Applicable Scenarios

#

V. Selection Perspective: Which Route to Choose for Which Scenario

#

5.1 Selection Decision Tree

#

What is your primary goal?
├── Thorough De-Oracle (Oracle Replacement)
│   └── Apex HyperDB (A5 Route)
├── Ultra-Fast Trading (Quantitative, High-Frequency)
│   └── HuaRui AMI (ATP Route)
├── Full-Stack Xinchuang + Low-Latency Platform Synergy
│   └── Kingstar KMDB (FS2.5 Route)
└── Smooth Legacy Evolution + Bimodal IT (Agile-Stable)
    └── Hundsun UFT-MDB + LightDB (UF3.0 Route)

5.2 Core Trade-offs of the Four Routes

#

VI. Future Evolution: The Convergence Trend of the Four Routes

#

6.1 Common Directions

#

• AI Native: All routes are exploring integrating AI capabilities (intelligent risk control, intelligent routing) into in-memory databases.
• Cloud Native: Containerization and Kubernetes deployment are becoming standard.
• Hardware Acceleration: FPGA, RDMA, and DPU are becoming key means for performance improvement.
• Deepening Xinchuang: From “adaptation” to “native” — new versions will be developed directly based on domestic chips and operating systems.

6.2 Differentiated Evolution

#

• HyperDB: Continue to deepen ARM optimization, exploring an integrated solution of “in-memory database + smart NIC.”
• KMDB: Evolve from a component to a platform, potentially becoming an independent “KOCA-MDB” product line to enhance external output capabilities.
• UFT-MDB + LightDB: Dual-engine fusion; LightDB absorbs in-memory computing capabilities, while UFT-MDB enhances persistence.
• AMI: Expand from ultra-fast trading to real-time risk control and real-time clearing, broadening scenarios.

VII. Conclusion: Four Routes, One Goal

#

Back to the core question at the beginning: From HyperDB to LightDB, what are the four routes of proprietary in-memory databases in securities core trading systems really competing for?

💡 It’s not about “who is faster,” but “who is more suitable for your brokerage.” The four routes represent four different architectural philosophies:

• HyperDB represents “autonomous and controllable at the database layer” — proving that domestic in-memory databases can completely replace Oracle.
• KMDB represents “autonomous and controllable at the platform layer” — proving that domestic low-latency platforms can achieve microsecond-level performance and fully support Xinchuang.
• UFT-MDB + LightDB represents “the engineering wisdom of Bimodal IT” — proving that a dual-engine architecture can balance legacy compatibility with ultra-fast innovation.
• AMI represents “focus on the ultra-fast track” — proving that achieving perfection in a niche scenario is also a valid route.

A Consensus:

📌 Author’s Note: There is no absolute superiority among these four routes, only differences in applicable scenarios. Apex HyperDB is the “nuclear weapon for De-Oracle,” suitable for brokerages pursuing complete liberation from Oracle; Kingstar KMDB is the “storage engine for the low-latency platform,” suitable for brokerages choosing the KOCA-LDP route; Hundsun UFT-MDB + LightDB is the “Agile-Stable Bimodal dual engines,” suitable for Hundsun legacy clients for smooth evolution; HuaRui AMI is the “king of ultra-fast trading,” suitable for quantitative and high-frequency trading scenarios.

By the 2027 Xinchuang deadline, all four routes will become viable choices for the Xinchuang substitution of brokerages’ core trading systems. What they are driving together is the historic leap of China’s securities core trading systems from “IOE dependency” to “full-stack Xinchuang.” And the ultimate winner of this leap is not a single route, but the overall capability of China’s FinTech autonomous and controllable strategy — when HyperDB replaces Oracle at Soochow Securities, when KMDB achieves full-stack Xinchuang single-track operation at Huaxing Securities, when UFT-MDB supports millions of clients at China Merchants Securities, and when AMI achieves microsecond-level trading at quantitative private funds, the “heart” of China’s securities core trading systems will finally be beating to the rhythm of China’s own code.

Appendix: Quick Reference Table for the Four Routes

#

💡 Further Reading & Interaction

Would you like me to write 《Three Paths for Xinchuang Substitution of Securities Core Trading Systems: Heterogeneous Replacement, Legacy Upgrade, Dual-Track Parallel》 next? Or perhaps switch angles to 《From Oracle to Proprietary In-Memory Databases: A Practical Guide for Database Migration in Securities Core Trading Systems》?

Both can dig deeper from the in-memory database route comparison in this article, linking “Technical Routes” to “Migration Paths” and then to “Practical Implementation,” completing the full Xinchuang implementation spectrum. Let me know your choice in the comments!