We saw a diagram on the platform of life advice, LinkedIn, that said ACID NoSQL Databases (Graph Databases and Document Stores) were not a thing. TerminusDB is both a graph database and document store and is ACID compliant.
TerminusDB uses immutable data structures making it lock-free in most cases. The query engine uses optimistic concurrency allowing transactions to retry if their state changed while executing. The lack of locking simplifies the engine and makes deadlocks very unlikely while providing ACID guarantees.
What are ACID transactions and how does TerminusDB achieve them?
ACID (Atomicity, Consistency, Isolation, Durability) are properties of database transactions that are generally considered desirable for many applications.
Atomicity
Atomicity is an all-or-nothing approach to database transactions. If a transaction starts but does not complete, then all data manipulation or modification operations carried out by that transaction are undone, and any affected data or objects remain unchanged. The database is returned to the state it was in before the transaction started. Atomicity, or atomic transactions, guarantee the consistency and integrity of data and objects, ensuring the database is not left in an inconsistent or partially changed state.
Atomicity and immutability
TerminusDB combines atomicity with immutability to provide atomic transactions.
Consistency
Consistency, on the other hand, refers to the idea that a transaction must not violate any of the rules or constraints that are imposed on the database. This means that a transaction must not create any data that is inconsistent with the rules of the database. Consistency has multiple forms and can be interpreted in different ways. TerminusDB implements two forms of consistency – full and partial consistency.
Full consistency
Where a schema exists for a TerminusDB database, a transaction will not be completed unless all schema conditions are satisfied. The consistency of the schema is maintained under all conditions.
Partial consistency
When rebasing, transactions that complete under certain read conditions can be replayed by reordering their commits. Schema consistency is maintained but not under all conditions.
Isolation
Isolation is another key property of ACID transactions. It ensures that the operations in one transaction are isolated from the operations in other concurrent transactions. The isolation property gives a user the impression of being the sole user of a database. The user experiences no currency or conflicts with other users of the database.
Read isolation
TerminusDB uses inherent database immutability to ensure each read query exists at a given layer providing each user with an isolated snapshot of the database.
Write isolation
Similar to read isolation, completing write transactions ensures isolation with optimistic concurrency, simply restarting any transactions failing mid-run.
Durability
Finally, durability refers to the ability of a database to persist with the changes made by a transaction even if there is a power failure or other unexpected event that causes the system to crash. This ensures that the changes made by a transaction are not lost and that the database remains in a consistent state even in the event of an unexpected failure.
TerminusDB is durable. In the unlikely event of a partial commit, previous layers remain unchanged and recoverable. Backups are significantly simplified, requiring only copy storage to ensure a safely recoverable state.
ACID NoSQL – A Graph Database and Document Store that is ACID compliant
So there you have it LinkedIn! ACID NoSQL databases are a thing! Don’t believe everything you read on social media.
We just wanted to set the record straight.