Transactional databases are architected to be ACID compliant, which ensures that writes to the database either succeed or fail together, maintaining a high level of data integrity when writing data to the database. Transactional databases are therefore critical for business transactions where a high-level of data integrity is necessary (the canonical example is banking where you want a whole transaction—debit from one account and credit to another—to either succeed or fail).

Because transactional databases are designed to run production systems, they’re very good at operations that must complete in milliseconds. If you’re doing analytics on a transactional replica of your production database, the replica will likely be nearly in sync with the main database, i.e. sub-second latency.

Working with data from transactional databases to provide a real-time operational snapshot is a perfect analytical use case for transactional databases because there’s so little latency introduced by the replica. If you’re trying to monitor support workloads or inventory or another operational system and need to make decisions based on data that’s as fresh as possible, replicating the production database may be the best option.

If even one part of the transaction fails, the entire transaction fails. In this way, every transaction must succeed 100% in order to successfully be committed to the database.

A transaction is either written to the database (bringing the database from one valid state to another) or the transaction is reverted.

Transactions that haven’t completed yet cannot be acted on or modified by other transactions.

Once a transaction is written to the database, it will stay there, even in the event of a database failure.