What Is a Transactional Database?

Summary

Transactional databases handle large volumes of short, real-time read and write operations for systems such as orders, payments, account balances, and customer records. They support online transaction processing (OLTP) by treating related steps as one logical unit: successful work commits, while failures roll back the full transaction. ACID—atomicity, consistency, isolation, and durability—protects integrity under concurrency and failures, with row-oriented storage optimized for individual-record access, locking and isolation levels coordinating concurrent work, and write-ahead logging (WAL) supporting crash recovery. The source positions these databases as foundations for banking, e-commerce, healthcare, reservations, and telecommunications, while noting that row-oriented execution is less suitable for large analytical workloads and that horizontal scaling is more complex than in distributed NoSQL systems.

Context

Operational applications require fast, accurate, consistent updates to individual records, including financial transactions, orders, inventory, patient records, reservations, and subscriber data. These systems must remain reliable during concurrent access and recover consistently after failures, while analytical workloads and growing scale create different requirements.

Approach / What changed

The explanation covers the transaction lifecycle, row-oriented storage, ACID properties, concurrency control through locks and isolation levels, and crash recovery through write-ahead logging. It also contrasts transactional engines with columnar and distributed systems and lists relational, NoSQL, and cloud-managed database examples.

Takeaways

• A transaction commits all its operations together or rolls them back together, preventing partial updates such as recording a bank transfer on only one account.
• Row-oriented storage is optimized for frequent reads and writes of complete individual records, whereas columnar storage is better suited to large analytical scans.
• Write-ahead logging records changes before applying them, allowing committed work to be recovered and incomplete transactions to be rolled back after a crash.

Related reading