In-Memory Databases × Securities & Funds Fintech: A Deep Dive into History and Technology

#

This article weaves together the historical evolution and technical depth of in-memory databases in China’s securities and fund industry. We start with why financial markets demand not just speed but also durability, trace the four generations of architectural transformation, then dive deep into the technology stack, compare open-source alternatives, and examine real-world cases.

1. An Unexpected Premise: Finance Doesn’t Just Need Speed – It Needs Speed Without Loss

#

Before discussing specific technologies, it’s crucial to establish the right problem framework. Three forces drive the adoption of in-memory databases in securities and fund trading systems:

• Market data surges: Exchange matching engines have already reduced latency to microseconds. The “September 24” surge event created instantaneous transaction floods that far exceeded traditional system capacity.
• I/O bottlenecks: Traditional core systems rely on Oracle/DB2, where each order processing step incurs network I/O plus disk I/O – single query latencies of tens to hundreds of milliseconds. In high-frequency trading, this is like “riding blind.”
• Non‑negotiable data integrity: Financial transactions require far stricter consistency than typical internet services. Any single order error can become a regulatory incident.

These three forces pushed “in-memory” from an option to a necessity. As the CIO of Guojin Securities put it, the next-generation core system must be able to “withstand peak loads, deliver speed, and embrace innovation.”

💡 Keep this framework in mind: every technical discussion below answers the question, “How do you achieve financial-grade speed + consistency + zero loss + scalability inside memory?”

2. Historical Evolution: Four Generations Along One Main Line

#

China’s securities and fund industry did not adopt in-memory databases overnight. The path follows a clear four-generation trajectory.

First Generation: Industry Starting Point – The “IOE” Era and Centralized Consolidation

#

• Around 2000, the centralized trading era began. Brokerage core systems were built on foreign technology stacks: IBM minicomputers + Oracle databases + EMC storage (the “IOE” triad).
• The design philosophy was “buy expensive hardware for reliability,” but the architecture was monolithic and centralized, with extremely low scalability ceilings.
• Commercial databases (especially Oracle) dominated because they offered both performance and highly reliable data storage, especially in overall monolithic performance.

Core contradiction of this generation: Oracle was too powerful yet too heavy – it managed everything, so nothing could iterate quickly; moreover, being foreign commercial software made it a strategic liability under the growing “Xinchuang” (domestic IT substitution) policy.

Second Generation: Technological Awakening – The “In-Memory” Thought Experiment (2008–2012)

#

• From 2008 to 2012, Apex Software began developing memory‑based low‑latency ultra‑fast trading systems for institutional and professional investors (the A5 prototype).
• Around 2012, Hundsun launched UFTCORE, its first‑generation in‑memory database. Internal processing performance improved by two orders of magnitude compared to physical databases, supporting transaction rollback and enhanced indexing. It was deployed at nearly 40 clients including GF Securities, Founder Securities, Changjiang Securities, and Industrial Securities.
• In the same year, Apex Software started forward‑looking R&D on its own in‑memory database (even before “Xinchuang” became a buzzword).

Key insight of this generation: “Removing Oracle” meant deconstructing the entire commercial database stack – handing performance to an in‑memory database, handing storage to domestic databases, and using distributed architecture to surpass the capabilities of any single monolithic database.

Third Generation: Xinchuang Ignites – “Changing Engines While Flying” (2020–2024)

#

• June 2020: Apex Software and Soochow Securities jointly launched the A5 Xinchuang edition in full production. This became the only trading system that truly removed Oracle and ran on a domestically developed core database, breaking a 20‑year dependency on foreign databases and hardware.
• Led by Soochow and Guotai Junan, the industry began building next‑generation core systems based on in‑memory trading with distributed architecture, gradually migrating to full Xinchuang deployment. This marked the entry of core trading systems into the deep waters of Xinchuang.
• December 2024: Hundsun’s UF3.0 in‑memory trading went live at Founder Securities in selected branches, achieving the first securities‑industry in‑memory trading production deployment with full‑stack Xinchuang. The project completed three major milestones in three months, with seamless switching between old and new systems and instant emergency rollback.
• 2024: Huafu Securities partnered with Hundsun to build the industry’s first full‑stack Xinchuang investment trading management system (O45).

Turning point of this generation: Xinchuang transformed from a compliance requirement into a strategic imperative. In‑memory trading evolved from a lab capability to large‑scale production engineering. The industry reached consensus on the construction path: replace legacy centralized trading systems entirely with new‑generation, fully Xinchuang‑enabled distributed counter systems.

Fourth Generation: Scale Maturity – The “Trillion‑Yuan Market” Era (2025–2026)

#

• By 2025, the global in‑memory database market was growing at approximately 19.65% CAGR.
• July 2026: Guojin Securities completed full customer migration to UF3.0 with zero faults, zero anomalies, covering all Shanghai/Shenzhen/Beijing stock, bond, and fund products.
• July 2026: Hundsun UF3.0 surpassed 50 million cumulative customers, officially entering the mature stage of scaled deployment.
• Hundsun released its 6.0 AI ecosystem architecture, accelerating its transformation into an AI‑driven fintech company.

Defining mark of this generation: In‑memory trading systems have shifted from “flagship projects” to infrastructure, capable of calmly handling trillion‑yuan‑level market surges – the hallmark of a mature, normalized financial‑grade low‑latency system.

📌 The main thread connecting all four generations: IOE centralized (foreign‑dependent) → In‑memory thought experiment (domestic DB seeds) → Xinchuang ignition (mass production) → Scale maturity (normalized trillion‑yuan markets). Each generation broke the “impossible triangle” (performance × Xinchuang × scale) of its predecessor.

3. Technical Depth: What Proprietary In‑Memory Databases Actually Do

#

Now let’s go deep into the technology. First, a critical positioning statement:

Hundsun’s proprietary in‑memory database is not a typical relational in‑memory database, but one with certain data relationships and pre‑processing capabilities. It is therefore defined as an “object‑oriented weakly relational in‑memory database,” focused on ultra‑fast trading and other low‑latency scenarios. It can be designed and optimized for specific business needs to achieve extreme performance, supporting high concurrency, strong consistency transactions, and complex data models.

This positioning is the key to understanding the entire technology: it deliberately deviates from the “general‑purpose relational” route and chooses a specialized engine purpose‑built for trading scenarios.

3.1 Hundsun’s Three Generations: From UFTCORE to UFTMDB

#

Hundsun’s proprietary in‑memory database has evolved through three clear phases:

From UFTCORE → UFTDB → UFTMDB, the main line is a triple jump of “performance improvement → concurrency isolation → system stability.” The first generation solved “Is it fast?”, the second solved “Is concurrency stable?”, and the third solves “Is the system stable and maintainable?”

3.2 Golden’s KMDB and Apex’s HyperDB: Different Proprietary Routes

#

• Golden FS2.5: Clearing adopts KMDB in‑memory database technology with a storage‑compute separation architecture, enabling high‑performance clearing and flexible allocation of compute and storage resources. The message bus is the self‑developed HARE high‑speed business bus.
• Apex A5: Based on the self‑developed HyperDB in‑memory database + LiveDTP distributed low‑latency middleware, honed over five years of co‑development. Fully adapted to Xinchuang environments; all order‑related business runs on the in‑memory database.

3.3 The Low‑Latency Platform “Three Musketeers” – In‑Memory Database Alone Is Not Enough

#

Focusing solely on the in‑memory database tells only half the story. True trading speed comes from the synergy of “low‑latency message bus + in‑memory database + concurrency framework”:

An engineering iron law: The in‑memory database and the low‑latency platform complement each other and are inseparable. Neither alone can deliver the full low‑latency benefit; the ultimate goal is to make low‑latency trading features available to retail customers.

3.4 UF3.0 Performance Breakthrough – Hard Numbers

#

Based on Hundsun’s proprietary MDB in‑memory database, UF3.0 delivers impressive metrics:

• 1.5 million transactions per second throughput
• Core penetration latency < 100 microseconds
• Concurrency capability improved by two orders of magnitude
• Peak 5x redundancy with built‑in fault self‑healing

Architectural details behind these numbers include:

• Stable‑Agile Dual Mode: The stable mode (trading and clearing core) prioritizes reliability; the agile mode (account operations) enables rapid iteration. The traditional “three separations” are further decoupled into account center, authentication center, capital center and other capability bases.
• Distributed cluster: A single shard supports 10 million customers and 1 billion orders; multiple shards in parallel support trillion‑yuan‑level market trading volumes.
• High elasticity: Service nodes can be expanded in T+0 real time; shards can be flexibly expanded in T+1.
• High agility: Competitive and comprehensive businesses are decoupled, supporting gray releases by business/shard with over 90% gray rate and weekly rolling releases.
• High resilience: Hardware side includes cluster HA, same‑city active‑active, and two‑site‑three‑center deployments; software side uses multi‑process, read‑write separation, and distributed clusters – process failures are automatically taken over without affecting others.

3.5 Asset Management’s “Compute Push‑Down” – The Highest Form of Usage

#

The O45 asset management scenario reveals the deepest use of in‑memory databases – “pushing computation down to the memory layer”:

• Traditional architecture: Data lives in the database, computation lives in the application layer, with significant data movement overhead between them.
• In‑memory computing architecture: Computation logic is pushed into the memory space where data resides, dramatically reducing data movement.
• Effect: In core business scenarios, transaction processing efficiency improves about 10x, while maintaining millisecond‑level real‑time risk interception.
• After Huafu Securities’ full‑stack Xinchuang O45 went live, overall performance efficiency improved 10–20x, and clearing time was reduced by 50%.

💡 “Compute push‑down” is the highest form of in‑memory databases in trading systems – it’s not just about fast storage, but about completing computation and data access within the same memory space, eliminating the I/O boundary. This is partially realized by VoltDB (stored procedures on database nodes) and Tarantool (Lua stored procedures), but financial proprietary implementations have brought it to engineering maturity.

3.6 Comparison with Open‑Source Solutions – Where They Fall Short

#

To highlight the unique value of the proprietary route, here is a comparison of four categories of open‑source/commercial solutions:

The common weaknesses of open‑source solutions align precisely with the strengths of proprietary ones:

1. Redis is not designed as a single source of truth – persistence is configurable, transactions are non‑strict ACID, making it unsuitable as the core trading fact store.
2. TimesTen’s licensing risk – after Redis switched to SSPL in 2024, AWS/GCP/Azure collectively forked Valkey. TimesTen, as a commercial database, faces the same “upstream uncontrollable” risk.
3. No “migration engineering” – open source provides software; financial proprietary provides “software + dual‑track parallelism + production traffic replay + full‑chain compatibility + lossless instant rollback.”

4. Modular Breakdown of a Financial‑Grade In‑Memory Database

#

Based on publicly available information, a proprietary in‑memory database typically contains the following modules:

4.1 Data Model: Object‑Oriented Rather Than Pure Relational

#

• The basic data model resembles a relational database (tables, indexes), but supports complex associations – e.g., “one account with many orders, one order with many fills, each fill corresponding to one order.” These relationships can be established directly in memory, reducing search scope and avoiding the need for relational joins.
• Locks and data can be placed together (a key advantage of in‑memory over disk databases: better cache locality and faster access).

4.2 Transaction Engine: Financial‑Grade ACID

#

• Supports transaction commit and rollback, with Read Committed isolation level.
• Supports MVCC (multi‑version concurrency control) to resolve read‑write blocking and improve concurrency.
• Upon transaction completion, automatically generates Redo logs; can choose asynchronous, semi‑synchronous, or strongly synchronous replication based on disaster recovery requirements.
• Distributed transactions coordinate across nodes via 2PC or Paxos protocol to prevent partial commits.

4.3 Persistence: Preventing “Memory” from Becoming “Volatile Storage”

#

This is the biggest misconception – modern in‑memory databases achieve durability through write‑ahead logging (WAL), snapshot backups, and cluster redundancy:

• Hundsun: Transactions automatically generate Redo logs; replication modes selectable by business DR needs.
• Apex: Performance handled by in‑memory database, storage handled by domestic Xinchuang databases, combined with WAL for zero loss.
• TimesTen: Entire database and transaction logs are persisted as log files and checkpoint files on disk, supporting synchronous/asynchronous logging.

4.4 High Availability: Result Replication + Multi‑Center Active‑Active

#

Hundsun MDB’s HA approach:

Based on the RCM reliable multicast message bus, using a publish‑subscribe model, result replication technology synchronously or asynchronously replicates in‑memory database results, ultimately achieving same‑room active‑active, same‑city active‑active, and cross‑site disaster recovery deployment.

Specific metrics: UF3.0 in‑memory trading achieves RPO=0, RTO=0 seconds under replica failure, with peak 5x redundancy and built‑in fault self‑healing.

4.5 Compute‑Storage Separation: Different Postures for Trading vs. Clearing

#

This is an architectural innovation driven by specific financial scenarios:

• Trading core: All data fully in‑memory, pursuing extreme low latency (UF3.0 < 100 μs).
• Clearing core: Adopts compute‑storage separation architecture. KMDB is designed with “clearing for assets” in mind, allowing flexible allocation of compute and storage resources according to clearing business needs, with distributed architecture enabling elastic scaling – clearing performance reaches minute‑level.

4.6 Memory Management: Proprietary Fine‑Grained Control

#

Hundsun’s LDP platform uses a proprietary memory management scheme:

• Fine‑grained control over memory allocation, reading/writing, and reclamation, delivering high‑performance memory access.
• Asynchronous automatic expansion.
• Customizable memory initialization operations and memory usage dashboards.

This is what fundamentally distinguishes an “in‑memory database” from “shoving data into Redis” – general‑purpose caches do not provide this kind of financial‑grade memory lifecycle management.

4.7 Xinchuang Adaptation: Full‑Stack Independent Control

#

All three proprietary in‑memory databases are fully self‑developed to meet Xinchuang requirements:

• Hundsun: MDB is part of a software‑hardware integrated solution. UF3.0 achieved “go‑live equals Xinchuang” at Founder Securities, having undergone seven generations of evolution and full‑stack Xinchuang adaptation, capable of supporting trillion‑yuan market conditions.
• Golden: KGMS, HARE, KMDB, KWAS and other core technologies are all independently developed, natively supporting Xinchuang.
• Apex: HyperDB is fully adapted to Xinchuang environments, with the entire stack from servers and networks to operating systems and databases under independent control.

5. The Hardest Engineering Problem: Why Migration Matters More Than the System Itself

#

The most overlooked yet skill‑intensive aspect in all materials is this: core system replacement is like changing engines while flying.

• Founder Securities: Started in September 2024, completed three major milestones in three months. Go‑live achieved seamless, zero‑impact switching between old and new systems. Interfaces remained fully compatible with existing channels and downstream systems, supporting lossless instant emergency rollback.
• Guojin Securities: Full customer migration with zero faults, zero anomalies, creating a trading foundation that “withstands peaks, delivers speed, and embraces innovation.”
• Hundsun shares a library of 10,000+ test cases and a production traffic replay tool that can simulate real data. Customer migration cycles for tens of millions of users have been shortened to 6 months, with construction timelines compressed by over 50%.

⚠️ Engineer’s mindset reminder: Going live with an in‑memory trading system is the biggest engineering challenge. Hundsun’s approach is full‑chain compatibility (identical upstream interfaces) + dual‑track synchronization (real‑time consistency between old and new) + four‑dimensional testing (shared cases + traffic replay + production validation + emergency quality assurance). This “migration engineering” knowledge is often more valuable than the system itself for quantitative engineers.

6. Trends: Three Main Lines

#

Based on the latest developments, proprietary in‑memory databases in the securities and fund industry are evolving along three lines:

1. AI‑Native Integration: Hundsun’s 6.0 AI ecosystem, Golden’s K‑GPT + KOCA‑AI – in‑memory databases will become the real‑time data foundation for AI inference.
2. Deepening Compute‑Storage Separation: FS2.5’s KMDB has already practiced compute‑storage separation in clearing; “compute push‑down + compute‑storage separation” becomes standard.
3. Cross‑Center Active‑Active Becomes Normal: Evolving from same‑city active‑active to cross‑site active‑active, with RPO=0, RTO=0 seconds becoming the entry threshold for core systems.

📌 A judgment criterion throughout this article: To evaluate a financial‑grade in‑memory database, don’t look at “how fast” (vendor‑claimed throughput numbers are just entry tickets). Look at four things instead – Is ACID complete? Is HA switchover sub‑second? Is Xinchuang full‑stack? Is migration seamless? Only when all four are satisfied does it qualify as a true financial‑grade in‑memory database.

7. Case Studies

#

7.1 Case 1: Golden FS2.5 In‑Memory Database System

#

Background:

• Traditional Oracle database hit performance bottlenecks, unable to meet ultra‑fast trading demands.
• Xinchuang substitution required a proprietary alternative.

Technical Solution:

• Custom‑developed in‑memory database specifically for the financial industry.
• Full in‑memory trading + full in‑memory risk control architecture.
• Distributed + microservices + containerized design.

Results:

• Order processing performance improved by more than 10x.
• Real‑time T+0 clearing.
• Successfully deployed at Ping An Securities with full customer migration.

7.2 Case 2: GF Securities (Hong Kong) Full In‑Memory Trading System

#

Challenge:

• Cross‑border trading had high latency.
• Pre‑trade risk control took too long, affecting trading experience.

Solution:

• “Full in‑memory risk control + full in‑memory trading” model.
• All trading and risk control data loaded into the in‑memory database in advance.
• Solved the industry‑wide problem of lengthy pre‑trade risk checks.

Outcome:

• Overall market trading speed improved by tens of times.
• Risk control response time dropped from seconds to milliseconds.

7.3 Case 3: A Bank’s Real‑Time Risk Control System (KingbaseES)

#

Pain Points:

• Traditional risk control suffered from “data silos” and “computational lag.”
• T+1 risk control could not intercept risks in real time.

Technical Architecture:

• Adopted KingbaseES (formerly Renmin University’s Kingbase) in‑memory database.
• Hybrid research method: public regulatory policy analysis + benchmarking against industry best practices.
• Real‑time computing engine reduced data access latency from 20 ms to 1 ms.

Effect:

• Risk control response time dropped from hours to seconds.
• Risk identification accuracy improved by 30%.

8. Technical Selection Recommendations

#

8.1 Scenario‑Driven Selection

#

8.2 Domestic Substitution Roadmap

#

Short term (1–2 years):

• Cache layer: Redis → Tair (Alibaba Cloud) or domestic Redis distributions.
• Application layer: Oracle → KingbaseES / Renmin University Kingbase in‑memory database.

Medium term (3–5 years):

• Core trading system: proprietary in‑memory database (following Golden’s model).
• Distributed computing: domestic distribution of Apache Ignite.

Long term (5–10 years):

• Full‑stack domestic: from hardware (domestic CPUs) to software (domestic OS + database).
• Build an independent and controllable fintech ecosystem.

9. Conclusion

#

The application of in‑memory databases in securities and funds fintech is essentially a paradigm shift from “disk thinking” to “memory thinking.”

Core Value:

1. Performance revolution: Latency drops from milliseconds to microseconds; throughput increases 10–100x.
2. Business innovation: Enables high‑frequency trading, real‑time risk control, robo‑advisory, and other new services.
3. Simplified architecture: Eliminates complex buffer managers; code becomes cleaner.
4. Cost optimization: Although hardware costs are higher, total cost of ownership (TCO) may actually be lower.

Keys to Success:

• Select the right technology stack for your business scenario.
• Balance performance, consistency, and availability in architecture design.
• Build a professional team for in‑memory database operations.
• Continuously track emerging technologies (RDMA, compute‑storage separation, AI integration).

Looking Ahead: With the deepening of China’s Financial Technology Development Plan (2022–2025) and the acceleration of Xinchuang substitution, the securities and fund industry’s adoption of in‑memory databases is entering a golden period. Over the next 5–10 years, full in‑memory, distributed, intelligent will become the main theme of technological development.

References: This article is based on publicly available materials including industry reports, technical documentation, case analyses, vendor official documents, and third‑party benchmark tests.