Why it matters
A bank’s database is where money actually lives. If it loses a confirmed transaction, or lets two withdrawals both succeed against a balance that covers only one, the error is real money. Most other design choices in a bank can be revisited. The database behind the ledger rarely can.
What money needs from a database
The four properties known as ACID matter most:
- Atomicity: a transfer’s debit and credit both happen or neither does.
- Consistency: rules such as “balance may not go below the overdraft limit” always hold.
- Isolation: concurrent transactions do not see each other’s half-finished work.
- Durability: once confirmed, a transaction survives a crash.
Relational databases were built for exactly this, which is why ledgers run on them.
The landscape
| Technology | Role | Typical use in Indian banking | Notes |
|---|---|---|---|
| Commercial relational (for example Oracle Database, IBM Db2, Microsoft SQL Server) | System of record | Core ledgers, payment systems, loan systems | Mature clustering and tooling; significant licence cost |
| Open-source relational (PostgreSQL and its enterprise distributions) | System of record or supporting system | Newer applications, channel back ends, some core modules | Lower licence cost; enterprise support available |
| Distributed SQL (for example CockroachDB, YugabyteDB) | Relational data spread across nodes | New systems that need scale across sites | Strong consistency across nodes, at the cost of write latency |
| In-memory cache (Redis and similar) | Fast reads of data held elsewhere | Session data, reference data, rate limiting, balance snapshots for display | Not a system of record; data can be lost |
| Document stores (for example MongoDB) | Flexible, nested records | Customer profiles, onboarding journeys, content | Check the transaction guarantees before using for money |
| Key-value and wide-column stores | Very high write and read volumes | Event histories, logs, device and fraud features | Usually eventual consistency |
Typical uses are general industry patterns, not claims about named banks. Product names are examples only.
Vendors have also moved established banking software onto open-source relational databases. EDB stated in 2019 that multiple Finacle modules had been migrated to EDB Postgres and implemented at financial institutions in Asia.1EDB. Infosys Finacle Names EnterpriseDB Open Source DB Partner of the Year. As of 11 April 2019.
Clustering and replication
A single database server is a single point of failure. Clustering runs several servers so that one can take over from another. Replication copies data to other servers or sites, synchronously (no loss, slower writes) or asynchronously (faster, small possible loss). RBIReserve Bank of India. India's central bank. It regulates banks and payment systems, runs RTGS and NEFT, and holds the accounts in which banks settle with one another. expects critical systems to aim for no loss at all: For critical information systems, regulated entities should prioritise a minimal RTO, approved by their IT Strategy Committee, and a near-zero RPO; with a non-zero RPO they need a documented method for reconciling data when resuming from the alternate site.2Reserve Bank of India. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (full text). As of 7 November 2023. Replication is not a backup, though: a deleted table is deleted everywhere. Regulated entities must back up data and periodically restore it to check that it is usable.2Reserve Bank of India. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (full text). As of 7 November 2023.
How to choose
Start from the consistency the data needs, not from the technology. Balances, postings and anything else that must never be wrong belong in a relational database with full transactions. Data that is read far more than written, such as reference data or a customer’s recent transactions for an app screen, can be cached. Data whose shape changes often and which does not move money, such as onboarding forms, can suit a document store. High-volume append-only data, such as events and logs, suits stores built for writes.
Trade-offs
| Choice | You gain | You give up |
|---|---|---|
| One large relational database | Simple strong consistency | Scale limited to the biggest machine; costly failover |
| Distributed SQL | Scale and resilience across nodes | Higher write latency; newer operational skills |
| Cache in front of the database | Fast reads and less load on the core | Stale data risk; another system to keep consistent |
| Open-source engine | Lower licence cost, no single vendor | Support contracts and in-house skills still needed |
Pitfalls
- Treating a cache as the truth, for example approving a payment against a cached balance.
- Assuming replication is a backup. Mistakes replicate too.
- Choosing a store for its speed and discovering later that it cannot run a multi-record transaction.
- Migrating engines without checking behaviour, such as differences in how dates, rounding or locking work.
- Long-running reports on the ledger database, slowing customer transactions.
Questions for a design review
- Which data here must never be wrong, and which store holds it?
- What isolation level do money-moving transactions run at?
- If the primary database fails now, how much data is lost and who reconciles it?
- When was a backup last restored and checked?
- Which reads could move to a cache or replica, and how stale may they be?