Transactions are a necessity for most applications

NoSQL databases have dominated the database scene over the past decade. They have largely delivered on their promise of unlimited scaling and performance boosts, and there is now a growing breed of hybrid databases that combine the power of Partitioning and Replication of Schemaless Databases with the transactional guarantees of relational databases.

But initially, NoSQL databases abandoned transactions in favor of Scalability and Performance. They led to a belief that transactions were generally the anti-thesis of scalability. There is a notion that large systems need to sacrifice transactions to maintain good performance and scalability.

But the truth is not that simple, and like everything else in the technology world, transactions have advantages and limitations. Most applications have requirements that need transactions but adopt NoSQL databases without understanding how to plug the gap. It is crucial to know what is being sacrificed by going to NoSQL databases.

For example, Applications with linkages between data records need to maintain Referential Integrity. When multiple transactions are being committed concurrently, the database needs to ensure that data in different objects (like tables in RDBMS and documents in NoSQL databases) are updated safely and together, preserving the foreign key relationships. Otherwise, the database may end up with partial data structures from different transactions, violating the application's Invariants.

Additionally, all associated object indexes have to be updated simultaneously along with object data. Transactional databases handle this requirement very well out-of-the-box.

Document databases that do not support joins also encourage denormalization. But Denormalization does not eliminate the need for transactions. Several documents have to be updated in one go when denormalized information needs to be updated. Transactions are very useful in this situation to prevent denormalized data from going out of sync.

On the read side, applications should minimize dirty reads when several objects are updated together. NoSQL databases hide behind Eventual Consistency and the CAP Theorem when applications experience this problem. However, it is still essential to recognize and handle the scenarios, to make the user experience seamless.

So while it is possible to gain scalability and performance with NoSQL databases, it is important to think about data architecture and user workflows and minimize the error scenarios resulting from a lack of transaction support.