NoSQL Databases Should Support Transactions: 10 Reasons Why

by Chris Preimesberger

Concurrency arises whenever multiple clients, users, or parts of an application read and write the same data at the same time. Transactions make managing concurrency simple for developers. The main property of transactions that achieves this simplicity is isolation, or the “I” in ACID. When a system guarantees that transactions are fully isolated, developers can treat each transaction as if it were executed sequentially, even though it may actually be executed concurrently. The burden of reasoning about potential interactions between operations from separate transactions goes away.

Transactions allow developers to build abstractions simply and efficiently, providing a highly extensible capability to support multiple data models. Data models optimized for graphs, hierarchical documents, column-oriented data or relational data can all be implemented in layers. A common abstraction is to maintain an index along with the primary data to enable quickly finding data items matching some constraint. With transactions, an indexing layer can update both the data and the index in a single transaction, guaranteeing their consistency and allowing for a strong abstraction.

Transactions enable a more efficient data representation within a given model. Data elements can be modeled to optimize access efficiency, using multiple documents when appropriate, and still be updated in a single transaction to guarantee consistency. Moreover, the data can be shared by multiple clients and concurrently updated. Again, transactions provide the concurrency control needed to safely manage a shared state.

When applications evolve, having the flexibility to modify the data model and the power of global transactions can make the difference between an easy change and re-architecting. This sort of evolution is a natural and frequently occurring pattern. Transactions make the difference between being able to easily add these features and throwing out large parts of your code and starting over.

It may seem that the design tradeoffs for your system compel you to give up the advantages of transactions to gain speed, scalability and fault tolerance. Systems built this way are usually fragile, difficult to manage and often nearly impossible to adapt to changing business needs. The costs of forgoing transactions are rarely worth the benefits, especially if an alternative can provide transactional integrity at scale.

When the NoSQL movement began, features familiar from relational databases had been aggressively shed and were deemed unnecessary or even harmful for scalability and performance goals. However, it is becoming clear that supporting transactions is a matter of engineering effort, not a fundamental tradeoff in the design space. Algorithms for maintaining transactional integrity can be distributed and scaled out like many other problems.

Transactions guarantee the durability of writes (the “D” in ACID). This guarantee comes with some increase in write latency. Durability means that committed writes stay committed, even in the face of subsequent hardware failures. As such, durability is an important component of fault tolerance. NoSQL systems that don’t support durability are necessarily weaker in regard to fault tolerance.

For several decades, nearly all software systems that need to store data have been built on top of relational (mostly SQL) databases, and rely on the strong consistency guarantees and concurrency controls provided by ACID transactions. Any projects to transition existing systems to modern distributed databases will be exceptionally complicated, if not impossible, if the new database does not provide ACID transactions.

Google can in large part be credited with the creation of the NoSQL movement; its “Big Table” white paper served as the basis for many first-generation NoSQL databases. It introduced the concept of “eventual consistency” as a sacrifice that could be made for scalability. Google has recently released a paper on Spanner, the company’s new distributed database system, which instead of eventual consistency provides ACID transactions. If Google’s engineers need transactions, chances are good that you do, too.

ACID transactions simplify concurrency for developers by providing “serializable” operations that can be composed to properly engineer application software. The choice to use transactions is ultimately not a matter of fundamental tradeoffs but of sound engineering. As the technology matures, transactions will form a foundational capability for future NoSQL databases. If you’re building an application that needs to be scalable and you don’t have transactions, you will eventually be burned.