Database Architecture for Financial Applications

The database layer is one of the least visible components in a financial system — and one of the most consequential. When it is configured correctly, transactions settle reliably, audit trails are complete, and the system scales without incident. When it is not, the failure modes are severe: duplicate transactions, inconsistent balances, compliance gaps, and outages that regulators treat as operational risk events under DORA. 

For senior decision-makers evaluating technology strategy or vendor capability, understanding the basic taxonomy of database choices — and where each is appropriate — is not a technical luxury. It is a governance requirement. 

The Non-Negotiable Baseline: ACID Compliance 

Before any architectural decision, one requirement must be fixed: financial data must be managed by a storage layer that guarantees ACID properties — Atomicity, Consistency, Isolation, and Durability. In plain terms, this means that a payment either completes fully or does not complete at all; that two transactions cannot corrupt each other's data by running simultaneously; and that once a transaction is confirmed, it cannot be silently lost. 

ACID compliance is not a differentiating feature. It is the floor. Any database used for ledger data, payment records, or customer account balances must meet this standard without exception. The architectures that follow differ in how they meet it — and at what scale. 

Traditional RDBMS: PostgreSQL 

PostgreSQL remains the most widely deployed database in European fintech and banking environments, and for sound reasons. It provides full ACID compliance, mature tooling, deep support for regulatory audit patterns, and a strong operational track record in regulated industries. For institutions with transaction volumes that do not require geographic distribution — which covers the majority of mid-sized banks and payment processors — PostgreSQL is the correct default. 

Its constraints are structural rather than technical. A single PostgreSQL instance, even when optimised, has ceiling limits on write throughput. Replication strategies can extend read capacity, but they introduce complexity and do not eliminate the fundamental single-node write bottleneck. For institutions whose transaction volumes are growing toward that ceiling, or who need active-active deployments across multiple regions to meet availability requirements, PostgreSQL alone is no longer sufficient. 

The question is not whether PostgreSQL is reliable — it is — but whether the operational model it requires fits the scale and availability profile of the institution. 

Distributed SQL: CockroachDB and YugabyteDB 

Distributed SQL databases were designed to solve the specific problem PostgreSQL cannot: horizontal scale without sacrificing ACID guarantees. Both CockroachDB and YugabyteDB provide strongly consistent, distributed storage — meaning that transactions behave correctly across multiple nodes and, in multi-region deployments, across geographically distributed data centres. 

This matters in two scenarios that are increasingly common in European financial services. The first is volume: payment platforms handling tens of millions of transactions per day will eventually exhaust what a single-node architecture can support. The second is geography: PSD3 and national data residency regulations are pushing institutions toward multi-region deployments, and distributed SQL is engineered for precisely this operating model. 

CockroachDB and YugabyteDB are architecturally comparable at the level of guarantees they provide. The practical differentiators — licensing models, support structures, operational maturity, and compatibility with existing PostgreSQL tooling — are the factors that determine which is appropriate for a given institution. Both are PostgreSQL-wire-compatible, meaning that the migration path from a PostgreSQL environment is less disruptive than switching to a fundamentally different paradigm. 

The cost of distributed SQL is operational complexity. These systems require engineering teams with the knowledge to configure, monitor, and operate them correctly. When evaluating a software development partner's capability in this area, the right question is not whether they have used these databases, but whether they can demonstrate production deployments in regulated environments — including how they handle schema migrations, node failures, and multi-region failover under compliance constraints. 

NoSQL: Where It Belongs in a Financial Architecture 

NoSQL databases — document stores, key-value stores, time-series engines — are appropriate in financial architectures, but only in specific, bounded contexts. The critical discipline is ensuring they are never placed in the path of data that requires transactional integrity. 

Appropriate use cases include session management, rate-limiting state, fraud signal caching, audit log ingestion at high throughput, and read-optimised reporting pipelines where eventual consistency is acceptable. In a well-designed fintech architecture, a system might use Redis for real-time fraud signal lookups, Kafka-backed storage for event stream processing, and a NoSQL document store for flexible product configuration data — all feeding a PostgreSQL or distributed SQL core that holds the actual ledger. 

The architectural risk is boundary creep. NoSQL databases are performant and developer-friendly, which creates pressure to extend their use beyond the bounded contexts for which they are suitable. Institutions should expect their development partner to define and enforce these boundaries explicitly, and to document the data flow between components with sufficient clarity that an internal audit function or external regulator can trace the path of any transaction from initiation to settlement. 

The Decision Framework 

Three questions determine the appropriate architecture for any financial system: 

What is the write volume, and is it expected to grow beyond what a single node can sustain? 

If yes, distributed SQL belongs in the evaluation. If current and projected volumes are comfortably within single-node limits, PostgreSQL offers lower operational complexity at equivalent consistency guarantees. 

What are the geographic distribution and residency requirements? 

Multi-region active-active availability — increasingly expected under DORA's operational resilience requirements — is a strong signal for distributed SQL. 

What data is genuinely non-transactional? 

The answer to this question defines the boundary of appropriate NoSQL use. Everything outside that boundary should be treated as transactional by default. 

The institutions that make this decision well are those whose development partners raise it before implementation begins — not after the ledger is already sitting on a document store.