Databases

Data storage solutions for payment workloads, spanning strongly consistent relational stores for ledgers, in-memory stores for sessions and rate limiting, and specialized stores for search and high-volume event logs. Choosing the right database per workload, rather than one database for everything, is one of the most consequential architecture decisions a payment platform makes.

Use in configurator

PostgreSQL

PostgreSQL is widely regarded as the safest default relational database for payment platforms, combining strong ACID guarantees, mature JSON support, and a rich extension ecosystem such as PostGIS, pg_partman and logical replication that covers most needs without introducing a second database technology. Its transactional integrity makes it a strong fit for the core ledger and transactional tables at the heart of most payment systems.

Advantages

Strong ACID compliance and mature transaction isolation guarantees suited to financial data; native JSONB support bridges relational and document-style needs without a separate database; rich extension ecosystem covers partitioning, replication and geospatial needs; excellent tooling and long track record in production fintech systems.

Limitations

Horizontal sharding for extreme write scale requires deliberate architecture, such as Citus or application-level sharding, rather than being built in by default; vertical scaling has practical ceilings that very high-volume platforms eventually need to plan around; some advanced features require careful extension management during upgrades.

Use cases

Core transactional and ledger data; merchant and account records; any workload requiring strong consistency guarantees.

Performance: High

MySQL

MySQL remains one of the most widely deployed relational databases in the world, with deep operational familiarity across hosting providers, ORMs and monitoring tools. For payment platforms already standardized on MySQL, often inherited from an earlier stage of the business, its maturity and broad tooling support make it a safe, well-understood choice to continue building on rather than migrating away from without strong justification.

Advantages

Extremely broad familiarity among engineers, DBAs and hosting providers; mature replication, including group replication, and backup tooling; wide ORM and framework support across virtually every language; proven track record handling large transactional workloads at scale.

Limitations

Some advanced relational features and strictness options vary by storage engine and edition, requiring careful configuration for financial-grade guarantees; historically weaker JSON and full-text capabilities than PostgreSQL, though recent versions have closed much of this gap; licensing and edition differences between Community and Enterprise need to be understood upfront.

Use cases

Merchant and transaction data stores; platforms migrating from or already standardized on a MySQL-based stack; e-commerce-adjacent payment integrations.

Performance: High

MariaDB

MariaDB is a fully open-source, community-governed fork of MySQL that maintains strong compatibility while adding its own storage engines and features. It is a common choice for teams that want to stay on a MySQL-compatible wire protocol and tooling ecosystem while avoiding licensing ambiguity or wanting a more community-driven roadmap.

Advantages

Drop-in compatibility with most MySQL tooling, drivers and ORMs, easing migration; fully open-source governance model avoids licensing ambiguity; additional storage engines such as ColumnStore and Aria offer flexibility MySQL does not provide by default; active community-driven development cadence.

Limitations

Feature parity with the latest MySQL releases can lag or diverge in edge cases, requiring verification for specific advanced features; smaller managed-hosting footprint than MySQL or PostgreSQL on some cloud providers; documentation for divergent features is less abundant than for mainstream MySQL.

Use cases

Legacy MySQL migrations seeking an open-source path forward; platforms wanting MySQL compatibility without vendor licensing concerns.

Performance: High

MongoDB

MongoDB's flexible document model is well suited to configuration data, product catalogs and audit or event logs where the schema evolves frequently or varies across records, without requiring the migration overhead a strict relational schema would impose. It is deliberately not the recommended store for the core transactional ledger, where strong multi-document consistency guarantees matter more than schema flexibility.

Advantages

Schema flexibility makes iterating on evolving data shapes such as configuration, catalogs and logs fast without migrations; horizontal scaling via native sharding is more straightforward than sharding a relational database; strong tooling for aggregation pipelines and analytics on semi-structured data; good performance for document-shaped read and write patterns.

Limitations

Multi-document transactional guarantees, while supported in modern versions, require more careful design than a relational database's native transactions; schema flexibility can become a liability without discipline, leading to inconsistent document shapes over time; not recommended as the primary store for core ledger or transactional data.

Use cases

Product and pricing catalogs; configuration and feature-flag storage; audit and event logs with varying shapes across event types.

Performance: Medium

Redis

Redis is an in-memory data store used almost universally in payment platforms for session storage, rate limiting, distributed locks, caching and lightweight queueing. Its sub-millisecond latency makes it the natural place to put anything that needs to be read or written extremely fast and doesn't require the durability guarantees of the primary transactional database.

Advantages

Sub-millisecond latency for reads and writes, ideal for sessions, rate limiting and caching; native support for pub/sub, sorted sets and other structures useful for queues and leaderboards; simple operational model for small-to-medium deployments; widely supported across every major language and framework.

Limitations

Primarily an in-memory store, so durability requires deliberate configuration such as AOF or RDB persistence and should never be treated as the source of truth for transactional data; memory costs scale directly with dataset size, which matters for very large caching layers; clustering adds operational complexity at high scale.

Use cases

Session storage and rate limiting; distributed locks for idempotency enforcement; caching of frequently read, rarely changed data; lightweight job queues.

Performance: Very high

Cassandra

Cassandra is a distributed, wide-column database built for extremely high write throughput and linear horizontal scalability across multiple data centers, at the cost of the strong consistency guarantees relational databases provide by default. It fits payment platforms generating massive volumes of event or log data that need to be written reliably and queried by known access patterns, rather than ad-hoc relational joins.

Advantages

Handles extremely high write throughput with linear scalability by adding nodes; strong multi-datacenter replication support for geographic distribution and resilience; tunable consistency lets teams trade off latency and durability per use case; proven at massive scale in industry.

Limitations

Significant operational complexity to run and tune correctly, including compaction, repair and consistency levels; data modeling must be designed around known query patterns upfront, since ad-hoc joins are not supported the way they are in relational databases; eventual consistency model requires careful application-level design.

Use cases

High-volume transaction event logs; time-series data at massive scale; multi-region resilient storage for append-heavy workloads.

Performance: Very high

Elasticsearch

Elasticsearch provides fast full-text search and flexible aggregations over large volumes of semi-structured data, making it the standard choice for letting support teams and merchants search transaction history, and for powering operational monitoring dashboards. It is explicitly not designed to be a financial system of record; it should always sit alongside, and be fed from, an authoritative transactional database.

Advantages

Extremely fast full-text search and flexible ad-hoc aggregations across large datasets; strong fit for building operational monitoring and observability dashboards; scales horizontally for search-heavy workloads; rich query DSL supports complex filtering that would be painful to express in SQL.

Limitations

Not ACID-compliant and should never be treated as a financial system of record, so an authoritative database must always remain the source of truth; keeping indexes in sync with the source database requires a reliable pipeline such as change-data-capture or dual writes with reconciliation; operational overhead for cluster management, shard sizing and reindexing.

Use cases

Transaction search for support and merchant-facing tools; operational monitoring and log aggregation dashboards; fraud-signal exploration across large historical datasets.

Performance: High