What is a Database Transaction?
What is a Database Transaction?
Definition
A database transaction refers to a logical unit of work that consists of one or more database operations. It is a fundamental concept in database management systems, ensuring the integrity and consistency of data. A transaction allows multiple database operations to be treated as a single, indivisible unit, either all succeeding or all failing. This guarantees that the database remains in a consistent state, even in the event of failures or concurrent access by multiple users.
What is ACID?
Transactions have the following four qualities, which is usually communicated as the acronym, ACID. Note that different implementations of transactions will provide guarantees of differing “strength.”
Atomicity
Atomicity is one of the key properties of a database transaction. It ensures that all the operations within a transaction are treated as a single, indivisible unit. In other words, either all the operations within the transaction are successfully completed, or none of them are. This guarantees that the database remains in a consistent state, even in the face of failures or concurrent access by multiple users. By maintaining atomicity, database transactions provide reliability and predictability in data manipulation.
Consistency
Consistency is a crucial property of a database transaction. It ensures that the database moves from one consistent state to another consistent state after the completion of a transaction. In simpler terms, it means that the data in the database adheres to a set of predefined rules or constraints. If any operation within a transaction violates these rules, the entire transaction is rolled back, and the database remains unchanged. By enforcing consistency, database transactions maintain the integrity and reliability of the data, ensuring that it remains accurate and valid throughout the transaction process. Traditionally (and in Convex), this is “immediate” consistency - in that once you write data to the database, you can immediately read the value you wrote. Some systems offer a weaker “eventual” consistency, which means you may not be able to observe the changes you made until a later point.
Isolation
Isolation is an essential property of a database transaction that ensures concurrent access to the database does not interfere with the integrity of the data. It allows multiple transactions to execute concurrently without impacting each other's results. Each transaction is isolated from others, creating a virtual environment where it appears to be the only transaction running. There are varying levels of isolation. Convex offers “serializable” isolation by default, which is the strongest isolation. This prevents issues such as dirty reads, non-repeatable reads, and phantom reads. Most systems will default to a weaker level, for instance Postgres defaults to “read committed” which can allow non-repeatable reads and phantom reads. By providing isolation, database transactions maintain data integrity and ensure that the results of concurrent transactions are consistent and reliable.
Durability
Durability is a critical property of a database transaction that guarantees the permanence of its changes. Once a transaction is committed, its effects are durable and will persist even in the event of system failures or crashes. This is achieved through the use of transaction logs and other mechanisms that ensure the changes are written to non-volatile storage. By providing durability, database transactions ensure that the data remains intact and recoverable, maintaining the reliability and consistency of the database over time.
By providing ACID properties, database transactions ensure reliable and predictable data manipulation.
Convex and Transactions
When using Convex, all of your reads and writes with your database within a server function are automatically transactional and ACID compliant, even though Convex isn't a SQL database.
This may come to a surprise for developers, as most document stores are not transactional, as they optimize for performance, sacrificing key reliability features. Unlike traditional relational databases, NoSQL databases prioritize horizontal scalability and high-speed data processing, often sacrificing transactional capabilities. The absence of transactions in NoSQL databases allows for greater flexibility and agility in handling large volumes of data**.** However, this lack of transactional support can lead to potential data inconsistencies or integrity issues in certain scenarios.
NoSQL databases typically adopt a "eventual consistency" model, where data consistency is achieved over time rather than instantaneously. This means that changes made to the database may take some time to propagate across all nodes in a distributed system, resulting in temporary inconsistencies.
While some NoSQL databases offer limited transactional support for specific use cases, such as single-document operations, they generally lack the comprehensive ACID properties provided by traditional relational databases.