Use Case
Transactions the Business Can Trust
Short, atomic transactions are the hardest workload to get right and the one the business notices first. MariaDB Enterprise Platform commits them correctly, at volume, without going down.
What is online transaction processing (OLTP)?
Online transaction processing, or OLTP, handles high volumes of short, atomic transactions, such as processing payments, updating customer records and adjusting inventory. The MariaDB Enterprise Platform commits them with ACID guarantees and adds in-memory compute through MariaDB GridGain.
How Virgin Media O2 serves more than 30 million users, with every network transaction now running on MariaDB Cloud in production
Transaction latency fell from 7 milliseconds to 1, failed connections disappeared, and the team saw every transaction from the day it migrated.
Capabilities
What transaction processing needs
Correctness comes first, followed by speed and throughput, availability and security. These five capabilities are what enables MariaDB to be a transactional database for enterprise workloads.
Transactional integrity
ACID compliance keeps data accurate under concurrency. InnoDB uses row-level locking and multi-version concurrency control, so readers and writers do not block each other.
Storage engines per workload
Default InnoDB for mixed traffic with full ACID and four isolation levels; MyRocks for write-heavy tables for high compression. Choose per table on the same server.
In-memory compute and streaming
MariaDB GridGain processes events as they arrive and runs logic co-located with the data, so decisions land inside the transaction rather than after it.
Availability under failure
Asynchronous replication with transaction replay; synchronous replication (Galera) for zero data loss; and Raft clustering, which commits on a majority.
Security at every layer
Certificate-based encryption protects data in transit, managed keys protect it at rest, and role-based access controls, password policies and audit logging help secure access.
What transaction processing patterns does MariaDB support?
Transaction processing looks different depending on what is being committed. These three patterns cover most of what customers actually run in production.
Payment processing
Digital wallets, real-time payments, account-to-account transfers and cross-border settlement, with balance, risk and sanctions checks completed before authorization closes.
High-concurrency operational applications
Order capture, inventory updates and customer records, where thousands of short transactions per second must remain correct and fast.
Decisioning inside the transaction
Fraud scoring, dynamic pricing and routing rules execute in memory while the transaction is open, so the answer arrives before the commit.
Recommended resources
Get started
Start building with MariaDB
One real-time database platform you can trust, for everything you run today and everything you build next.
Frequently asked questions
Online transaction processing handles high volumes of short, atomic transactions, such as processing payments, managing customer data and managing inventory updates. Both accuracy and speed matter.
ACID guarantees mean a transaction either completes fully or not at all, and that concurrent transactions do not corrupt each other. For payments and ledgers, this is what makes the record trustworthy.
Yes. Replication and clustering scale transactional load, InnoDB handles concurrency with row-level locking and MVCC, and MariaDB GridGain absorbs peaks in memory when throughput outgrows the database alone.
Keep balance, risk and routing data in memory alongside the compute, so checks finish before the authorization window closes. The ledger commits in MariaDB Enterprise Server with full transactional consistency.
InnoDB is the default, offering full ACID compliance for mixed read and write workloads. MyRocks reduces I/O for write-heavy tables. Storage engines are pluggable, so different tables can use different engines on the same server.
With asynchronous replication, MaxScale detects the failure, promotes a new primary and replays transactions so clients are not interrupted. Galera provides synchronous clusters, while Raft clusters keep writes consistent across regions.