Updated on 2026-10-30 10:53:45Core banking systems manage accounts, deposits, loans, interest calculations, and the core ledger. Their databases must keep the books accurate, protect committed transactions, keep services available, maintain predictable performance, and support investigation and audit.
OceanBase, Oracle Database, CockroachDB, and Google Spanner are candidates for different banking architectures. The best choice depends on whether a proposed deployment can meet the bank's transaction, recovery, performance, security, and operational requirements—not on a single benchmark or architecture label.
This is a technical selection framework, not a set of regulatory rules universally applicable in every jurisdiction. Banks must assess applicable laws, supervisory requirements, and internal policies for their own operations.
What Core Banking Requires From a Database
1. Correct Transactions and Accurate Ledgers
A transfer should debit one account, credit another, and record the relevant ledger entries atomically within the defined transaction boundary. Concurrent withdrawals and balance or credit-limit checks must preserve business rules. Use exact numeric representations for amounts and define currency precision and rounding consistently.
Specify the isolation semantics needed for each critical transaction. Serializable isolation can be valuable, but a bank must also test conflict handling and retries. Strong replica consistency alone does not define transaction isolation.
2. Durability and Disaster Recovery
Define the recovery point objective (RPO) and recovery time objective (RTO) for node, data-center, and regional failures. Core ledgers often target RPO zero within an agreed failure scope. Verify replication acknowledgement, durable log persistence, failover, and split-brain prevention for the actual topology.
Multiple replicas alone do not guarantee zero data loss. With asynchronous replication, a confirmed transaction may not yet have reached the recovery site when a failure occurs.
3. High Availability and Business Continuity
Test continuity during faults as well as upgrades, patching, and capacity changes. After a failover, connections, in-flight transactions, and retries must recover correctly. Measure when the complete banking service resumes successful transactions, not just when a database process or leader is available.
4. Stable Performance Under Peak Load
Measure throughput, P95/P99 latency, timeouts, and transaction retry rates. Include payroll, month-end interest calculation, bulk debits, hot accounts, and online transactions running alongside end-of-day processing. A peak TPS result matters less than whether performance remains predictable during peaks, failures, and expansion.
5. Growth and Workload Isolation
Plan for growth in accounts, transaction volume, and ledger history. Measure the impact of data movement and rebalancing as capacity is added. Protect online posting from reporting, regulatory queries, and batch jobs through appropriate resource and deployment boundaries.
For distributed deployments, validate cross-partition transactions, hot keys, and cross-region latency rather than judging scalability by node count alone.
6. Security, Audit, and Data Governance
Evaluate least-privilege access, separation of duties, encryption in transit and at rest, key management, and sensitive-data masking. Record who accessed or changed what and when, and protect audit records against unauthorized alteration. Data residency, retention, and cross-border processing requirements depend on the applicable jurisdiction.
7. Restore, Reconcile, and Trace
Test backups, point-in-time recovery where supported, and regular restoration exercises against accidental changes, logical corruption, and attacks. Reconcile restored balances and ledger entries with business records. High-availability replicas do not replace backups: an erroneous deletion can be replicated too.
8. Compatibility and Operational Readiness
Verify the core application's SQL, drivers, procedures, transaction behavior, and batch jobs—not syntax alone. Assess diagnostics for lock waits, slow SQL, replication lag, capacity, and transaction conflicts. Migration requires data validation, cutover and fallback plans; ongoing support and total operating cost also belong in the decision.
How the Database Candidates Compare
OceanBase
OceanBase is a distributed relational database with MySQL compatibility and Oracle compatibility in Enterprise. For core banking, its value extends beyond migration: it supports distributed ACID transactions, data distribution across a cluster, multi-replica availability, and tenant resource allocation. Assess the required isolation semantics and application behavior in the selected version and deployment.
Its Multi-Paxos log replication commits a log entry after a voting majority persists it; strong-consistency reads are available from the leader. A five-data-center deployment across three regions provides a disaster-recovery option when replicas are placed appropriately and a majority remains available. Test the agreed failure scenarios, including end-to-end reconnection and reconciliation, instead of assuming every outage has the same RPO or RTO.
For performance context, an audited 2020 TPC-C test recorded 707,351,007 tpmC on OceanBase Enterprise with 1,554 data nodes. The result demonstrates OceanBase's ability to process transactions at scale.
OceanBase's published ICBC Asia case describes a cross-site, multi-replica deployment and a data-center shutdown exercise. It is useful evidence of one bank's continuity design, not a guarantee for another deployment.
Oracle Database
Oracle Database is relevant to banks with established Oracle applications, operational expertise, and support arrangements. Oracle RAC uses shared storage across instances; Oracle Sharding distributes data across independent databases. Assess the actual topology, transaction behavior, disaster recovery, licensing, and change costs.
CockroachDB
CockroachDB provides PostgreSQL-compatible SQL over distributed, Raft-replicated ranges. Its default serializable isolation is relevant to concurrent ledger operations; applications must handle retry errors when the database cannot retry safely on their behalf. Verify the required SQL, deployment, and core application support.
Google Spanner
Google Spanner is a managed distributed database with GoogleSQL and PostgreSQL dialects. TrueTime supports external consistency for transactions at the default or serializable isolation level, including across regions. A bank should assess cloud-region suitability, network latency, data residency, application behavior, and service terms.
What to Validate Before Selection
Run the same bank-defined scenarios against each proposed deployment:
- Ledger correctness: Concurrent transfers, balance checks, exact amounts, and reconciliation.
- Recovery: Node, data-center, and agreed regional failures; record RPO, RTO, connection recovery, and transaction outcomes.
- Performance and growth: Peak throughput, P95/P99, timeouts, retries, hot accounts, online traffic with batch processing, and expansion under load.
- Security and operations: Access, audit, backup restoration, upgrade, observability, and application support.
- Migration: Validate data and critical procedures; rehearse cutover and fallback, including writes accepted after cutover.
Two distinctions are essential. A correct database transaction does not by itself guarantee end-to-end exactly-once payments across systems; the application still needs idempotency, deduplication, reliable messaging, and reconciliation. Distributed, active-active, and multi-cloud designs are architecture choices: the acceptance criteria are correctness, recovery, predictable performance, and operability.
The best database for core banking combines transaction consistency, data durability, business continuity, stable high performance, security and auditability, and the ability to scale and evolve.
