News Stay informed about the latest enterprise technology news and product updates.

MongoDB 4.0 takes ACID transactions to multi-document level

MongoDB is taking a deeper step into SQL-style processing waters with a 4.0 update that brings increased support for ACID-compliant transactions to its NoSQL database.

With MongoDB 4.0, the NoSQL database is going deeper into what is widely seen as the sweet spot of SQL-based systems:...

ACID transactions. The processing guarantees provided by ACID compliance are a requirement in many applications -- and something of a holy grail for NoSQL users.

Vendor MongoDB Inc. said this week that the upcoming new version of its software would support the ACID properties -- atomicity, consistency, isolation, and durability -- in transactions across multiple MongoDB documents. Such support gives the database a foothold in mission-critical applications where NoSQL's usual style of eventual consistency for data isn't a good fit.

"MongoDB is officially dropping ACID," CTO and co-founder Eliot Horowitz dryly deadpanned at a company event in Seattle. MongoDB 4.0, the company's first major update since going public late last year, is available now as part of a beta program, with a full release expected to ship this summer, Horowitz said.

Prior to this release, MongoDB had supported a form of transactional consistency at the individual document level. To expand that consistency across multiple documents required work at the application level, and significant developer effort, Seong Park, MongoDB's vice president of strategy, said in an interview.

Building out applications

MongoDB is a document-oriented database that allows developers to create application portions built as software objects, described as "documents." The approach has freed developers from the task of creating relational schemas before building out applications.

But a need for the type of data consistency enjoyed by SQL relational databases has become common.

MongoDB CTO Eliot HorowitzEliot Horowitz

For example, in e-commerce applications, system architects who originally turned to NoSQL databases for fast data handling have had to find other ways to provide the most accurate and most recent data to users. This is a key use case that MongoDB 4.0 is meant to address.

Seong and Horowitz said the work to build multi-document ACID transaction support has been a major undertaking, underway at least since the company's 2014 purchase of WiredTiger Inc., the developer of a storage engine that has subsequently become MongoDB's default data store.

What's up, multi-doc?

Working consistently with transactional data from many data sets or documents is a common scenario for applications today, according to Doug Henschen, an analyst at Constellation Research.

"If your customer data is in one document set and order details are in another, for example, you'd need this multi-document capability to ensure ACID characteristics," Henschen said. To date, that has been accomplished in MongoDB by "complicated developer workarounds," he added.

MongoDB's move was prompted by users who wanted full ACID transactions, and also wanted to store complex sets of data rather than single documents, according to IDC analyst Carl Olofson. Among such users, he'd seen some moving from MongoDB to relational databases for lack of such capabilities.

And this lack was a lure not only to relational alternatives. It put MongoDB at a competitive disadvantage against NoSQL rival MarkLogic Corp., Olofson said. That company, one of the first to successfully commercialize NoSQL, has supported complex ACID transactions for a number of years, using what's known as multi-version concurrency control.

Riding the DevOps train

Much of MongoDB's success in recent years occurred as it has ridden along with the Agile and DevOps developer movements. Because of its schemaless nature, the NoSQL software supports Agile development better than relational database management systems, Olofson said.

"It means that developers can build and change applications without needing a DBA to define or revise a schema first," he said. But, he added, that comes with a cost.

The RDBMS remains the more powerful platform for supporting queries not anticipated by the developers, according to Olofson. Support for operational functions like guaranteed transactions are a step forward for MongoDB, but complex query capabilities may continue to give relational databases an important edge, he said.

For his part, Henschen said the implications that the capabilities included in MongoDB 4.0 will have on various transactional workloads remains to be seen.

"The feature won't be extended to sharded clusters until the MongoDB 4.2 release, and the date for that release has yet to be set," Henschen noted. Still, he said, it will be useful to give existing and would-be MongoDB developers more options for supporting a range of applications, including demanding ACID transactions.

Next Steps

Databases, including NoSQL databases, on cloud continue to expand

Dig Deeper on Database management system (DBMS) software and technology



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How important is transactional consistency in operational applications within your organization?
Well, I'm from "the rival" MarkLogic. MongoDB has said for years transactions don't matter, now suddenly the are the "only document DB with transactions" (false!) and it's a big deal.


To your question - transactions are very important for almost all my customers. We at MarkLogic focus on the biggest "enterprise" solutions, where losing data or corrupting data is unacceptable (full stop)... 6 of the top 10 global banks,, insurance, etc.

I focus on data integration and building Data Hubs across silos, where the tracking of what has been integrated, what has quality issues, data lineage and tracking, audits of who changed what - all that is critical. It's data management and governance for grownups.

If you want to store lineage with the data, track workflow or state of a document as it is processed, or simply know what happened - you MUST have multi-record transactions. 

For instance: did a trade clear, was a claim was rejected, did the MDM split notification get processed, was supporting documentation submitted to allow an approval? If you don't have multi-document integrity (ACID) guarantees, you simply can't know what happened.