How GaiaDB‑X Powers Next‑Gen Banking Core Systems: Architecture & Real‑World Cases

1. Bank New Generation Core System Background and Architecture

Historically, large and medium banks built their core systems on mainframes and minicomputers, but rapid growth in e‑commerce, online and mobile payments has made these architectures increasingly inadequate in four key areas: inability to support fast‑growing transaction volumes, slow iteration cycles, system risk and lack of talent for mainframe technologies.

Support for rapidly increasing business demand.

Need for fast, weekly‑level iteration similar to internet companies.

Requirement for software and hardware autonomy.

Closed ecosystem and difficulty recruiting mainframe experts.

Guided by national policies, banks are migrating core architectures from mainframes to commodity servers, establishing a new, self‑controlled technology stack often referred to as “core system migration.”

To understand the scale, a typical state‑owned bank serves 500‑700 million customers, holds 1‑2 billion accounts, and processes 50‑80 k transactions per second at peak. The database layer must handle tables with billions of rows, TPS in the millions, and support ten‑year historical queries on trillions of records, requiring thousands of servers even on generic hardware.

Technology Stack Overview

At the IaaS layer, banks use x86 and ARM commodity servers with virtualization and container services. The PaaS layer employs distributed systems such as Spring Cloud, a mix of distributed, single‑node, relational and cache databases, as well as log databases (ES) and time‑series databases. Middleware includes message queues, object storage, and distributed locks. The SaaS layer adopts a unit‑based micro‑service architecture, dividing applications into three unit types:

Global units for routing and traffic distribution.

Business units that host core logic; banks often split workloads into multiple units (e.g., 16 units each serving 50 M customers) for active‑active deployment.

Common units for services that are not unit‑ized.

Consequently, modern banking core systems resemble internet‑scale architectures, using the same technology stack.

Database Requirements in the Migration Scenario

Distributed scalability to handle billions of customers on commodity servers.

Strong consistency (ACID) to meet strict financial correctness.

Robust disaster‑recovery meeting regulatory Level‑5 standards, including active‑active and zero‑RPO capabilities.

Operational efficiency despite a 50‑fold increase in node count, requiring automation and intelligent management.

Two Database Architecture Options

Single‑node architecture is simple with a small failure domain but forces complex business‑layer data sharding and cannot fully support unit‑level workloads.

Distributed database architecture offers better performance; each business unit can use a dedicated distributed database, simplifying business logic.

GaiaDB‑X Distributed Database for Financial Scenarios

GaiaDB‑X, developed by Baidu Intelligent Cloud, is a Shared‑Nothing distributed database built on commodity servers, providing horizontal scalability for high performance and large data volumes.

Its three‑tier architecture consists of:

Compute layer : Stateless, horizontally scalable, MySQL‑compatible, parses SQL, performs permission checks, logical and physical optimization, and pushes computation to the storage layer.

Storage layer : Multi‑shard design with hash, range, or list partitioning; each shard maintains multiple replicas for reliability.

GMS (Global Metadata Service) : Manages global metadata such as schema, permissions, routing, and provides a globally unique, monotonically increasing logical timestamp (TSO) for distributed transactions, using Raft for replication.

At the bottom, a unified database control platform manages clusters across tens of thousands of nodes.

Consistency Solutions

Three typical approaches are discussed:

TrueTime (hardware‑dependent GPS/atomic clocks).

HLC (used by CockroachDB, decentralized but weaker consistency).

TSO (used by TiDB and GaiaDB‑X), which provides a global logical sequence number without special hardware.

Disaster Recovery and Multi‑Site Deployment

Banks adopt a two‑stage migration: first to x86 CPUs, then to domestically produced CPUs (Kunpeng, Feiteng, etc.). A typical deployment includes two same‑city data centers (active‑active) and one remote disaster‑recovery site, with 3 + 2 node replication and strong synchronous replication to achieve zero data loss (RPO = 0).

Financial Application Cases

Baixin Bank has fully eliminated Oracle, running over 200 systems on GaiaDB‑X with a 99.93% domesticization rate, achieving >70% hardware cost reduction and active‑active disaster recovery.

National Exchange co‑developed a database solution with Baidu, implementing a collocate mechanism that reduced transaction latency from 80 ms to 15 ms while meeting active‑active requirements.

Large State‑Owned Bank migrated from minicomputer‑based core to commodity servers, expanding node count to ~1,000, and leveraged Baidu’s unified database control platform to achieve full production rollout and regulatory acceptance.

Overall, GaiaDB‑X demonstrates how distributed, cloud‑native database architectures can meet the scalability, consistency, disaster‑recovery, and operational demands of modern banking core systems.