Database Transactions are logical units of database work that group one or more operations into a defined unit of execution. A transaction may contain reads, inserts, updates, deletes or other database operations and establishes a boundary within which the database system manages visibility, consistency and completion according to its transaction model. The fundamental idea is that a related set of changes should be treated as one logical operation rather than as unrelated individual statements.
For example, transferring funds between two accounts conceptually involves decreasing one balance and increasing another, and treating those changes as a transaction prevents the system from regarding the transfer as successfully completed after only one side has changed. Transactions are fundamental to multi-user database systems because concurrent sessions can otherwise observe intermediate states or interfere with one another. Their exact semantics depend on the database management system and its configured isolation and durability mechanisms.
A transaction normally progresses through states such as active execution, successful completion through commit, or termination through rollback. A commit makes the transaction's changes eligible to become permanent according to the database's durability mechanisms, while a rollback causes its transactional changes to be undone or otherwise rendered ineffective according to the engine's implementation. A transaction can fail because of an application error, constraint violation, deadlock, connection failure or system problem.
Database engines maintain internal mechanisms such as write-ahead logging, undo information, locking or multi-version concurrency control to provide the required behaviour. Transaction boundaries can be explicit, with application code issuing begin, commit and rollback operations, or implicit, depending on the database driver's and engine's configuration. Autocommit modes commonly make individual statements separate transactions unless an explicit transaction is started.
Transactions become particularly important under concurrent access. If two sessions modify overlapping data simultaneously, the database must determine what each operation can see and how conflicting modifications are resolved. Lock-based systems may acquire shared or exclusive locks, while multi-version concurrency control can allow readers to access appropriate row versions while writers create newer versions. Isolation settings determine how much interaction between concurrent transactions is permitted.
Lower isolation can provide greater concurrency but allow phenomena such as non-repeatable reads or phantom reads, while stronger isolation can reduce concurrency or increase resource consumption. Serial execution provides the strongest conceptual isolation by making transactions behave as though executed one after another, but database engines use sophisticated mechanisms to obtain useful concurrency without literally serialising every transaction.
Transaction boundaries should correspond to coherent business operations and should generally be kept as short as practical. A transaction that remains open for a long time can retain locks, prevent version cleanup, increase contention and enlarge recovery requirements. Excessively broad transactions can therefore reduce concurrency even when every individual statement is efficient. Conversely, splitting a logically indivisible operation into multiple independent transactions can create partial states that violate business requirements.
Applications must also understand the interaction between transaction scope and external operations: committing a database transaction does not automatically make an external API call, file operation or message delivery atomic with the database. Coordinating database state with external systems can require patterns such as an outbox, idempotent processing, compensating actions or distributed transaction protocols.
Database Transactions are distinct from ACID Transactions as terminology, although the concepts overlap heavily. A transaction is the unit of work and the database mechanism that provides transactional semantics, whereas ACID is a framework describing four desirable properties of transactional processing: atomicity, consistency, isolation and durability. Not every use of the word transaction necessarily means that all four properties are implemented with identical strength in every environment, particularly in distributed systems and specialised databases where guarantees may be configurable.
Transactions are also distinct from database sessions or connections. A session represents an interaction context with the database, while a transaction represents a particular unit of work within that context. Multiple transactions can occur sequentially within one connection, and depending on the system a transaction can span many statements.
Transaction processing is used across many domains, including financial operations, order processing, inventory management, authentication-related state changes, reservations, billing and configuration management. Consider an order placement operation: it might create an order, create its line items, decrement inventory and record a payment-related state. Whether all these actions belong in one database transaction depends on the business semantics and architecture, but operations that must change together should not be allowed to leave contradictory database state.
Constraints such as foreign keys, unique constraints and check constraints are often evaluated within transactional processing, allowing invalid changes to be rejected without permanently applying a partial operation. Savepoints can also divide a transaction into recoverable subregions, allowing selected work to be rolled back without necessarily discarding everything performed since the transaction began.
Deadlocks illustrate an important limitation of concurrent transaction processing. A deadlock can occur when transaction A holds a resource needed by transaction B while transaction B holds a resource needed by transaction A, creating a cycle in the dependency graph. Database systems commonly detect deadlocks and terminate one transaction so the other can proceed, requiring the application to retry when appropriate. Even without deadlocks, lock contention can cause waiting and reduce throughput.
Optimistic approaches instead allow transactions to proceed with fewer blocking locks and detect conflicts later, depending on the engine's concurrency model. Applications therefore need appropriate error handling and, where documented as safe, retry strategies for transient transaction failures. Transaction correctness is partly a database concern and partly an application concern because retrying an operation can itself produce duplicate effects unless the operation is designed to be idempotent.
Effective transaction design combines logical correctness, concurrency control and operational discipline. Developers should define clear transaction boundaries, avoid unnecessary work while a transaction is open, use suitable isolation settings, handle commit and rollback failures correctly, and account for deadlocks and transient conflicts. Database monitoring can reveal long-running transactions, lock waits, deadlocks, rollback rates and transaction throughput. Performance tuning must consider that transaction latency can affect resource retention and concurrency even when query execution itself appears fast.
In high-scale systems, transaction semantics can become more complicated when data spans partitions, replicas or independent services, because a transaction may no longer fit within a single database's coordination boundary. Database Transactions therefore provide the fundamental execution unit for reliable state changes, but their practical behaviour is determined by the interaction between application logic, database constraints, concurrency control, logging, recovery and system architecture.
