MongoDB Inc. announced today that version 4.0 of its MongoDB database platform will support multi-document ACID transactions to provide a consistent view of data across replica sets.
ACID Transactions are now in beta and the company says the syntax of multi-document transactions should feel familiar to those used to working with transactions in relational databases.
“Transactional guarantees have been a critical feature for relational databases for decades, but have typically been absent from non-relational alternatives, which has meant that users have been forced to choose between transactions and the flexibility and versatility that non-relational databases offer,” said Stephen O’Grady, principal analyst with RedMonk, in a statement accompanying the release. “With its support for multi-document ACID transactions, MongoDB is built for customers that want to have their cake and eat it too.”
One of the key enablers of transactions in MongoDB is the company’s document model, which enables organizations to store unstructured but related data in documents rather than tables. “The document model is something we made a bet on,” Seong Park, vice president for strategy and product marketing at MongoDB, told SD Times. “Multi-document ACID transaction support allows us to have broad applicability.”
Park said the update is the result of over three years of engineering effort during which they laid the groundwork for the introduction of transactions. In version 3.6, MongoDB introduced a global logical clock, which becomes the underpinning for functionality such as change streams resumability, released as a user facing feature in 3.6, but also necessary to support multi-document ACID transactions. An example, Park explained, is a e-commerce system on which a customers goes online to buy five cards. The back end has to decrement the inventory, and multiple tables have to be updated. With multi-document transactions, the update is done once.
With the release, MongoDB is moving away from calling itself a NoSQL database toward being billed as a modern, or next-generation-database. “Relational databases are constraining, limiting and rigid,” said Park, “while NoSQL has become more of a niche. It does things really well with key values and graphs.” Multi-document transactions “were the number one most requested feature by our community. Developers shouldn’t be forced to use legacy technology like a relational database ever again.”
In a blog post, Grigori Melnik, head of product, server and tools at MongoDB, discussed MongoDB’s motivations for the introduction of multi-document transactions.
“Because of this fundamental difference in data modeling, MongoDB’s existing atomicity guarantees are able to meet the data integrity needs of most applications,” Melnik wrote. “In fact, we estimate 80%-90% of applications don’t need multi-document transactions at all.”
However, there are some legitimate use cases and workloads where transactions across multiple documents are needed. In those cases, without transactions, a developer would have to implement complex logic on his own in the application layer. Also, some developers and DBAs have been conditioned by 40 years of relational data modeling to assume multi-table/document transactions are a requirement for any database, irrespective of the data model they are built upon. Others are concerned that while multi-document transactions aren’t needed by their apps today, they might be in the future and they don’t want to outgrow their database.”
MongoDB aims to ship version 4.0 this summer.