Full ACID Support Means ‘Game Over’ for Relational, MongoDB Says
MongoDB today revealed that it’s now supporting multi-document ACID transaction guarantees with version 4.0 of its database. When it becomes generally available later this year, MongoDB says it will have eliminated the last hurdle preventing enterprises from moving off relational databases.
“With this final piece of the puzzle with multi-document ACID transaction guarantees, it’s game over,” said Seong Park, MongoDB‘s vice president of strategy and product marketing. “We’re making it as easy as possible for developers and architects to never be forced to have to use a relational database again.”
When NoSQL databases like MongoDB first hit the market about 10 years ago, developers were enamored with their flexibility and scalability. In MongoDB’s case, the document model made it very easy to update the database with new data types compared to traditional relational databases.
However, that flexibility came at a cost, including the lack of consistency guarantees. While relational databases like Oracle and Microsoft SQL Server offered strong consistency guarantees, NoSQL databases generally offered something less. Many NoSQL databases embraced an eventual consistency approach, while MongoDB supported a strong consistency model for single documents, but not across multiple documents.
MongoDB’s prior consistency guarantee was suitable for less-critical use cases, such as eHarmony’s compatibility matching system (an actual MongoDB use case). But it was less suitable for, say, powering the core banking system of a global financial services firm, where the full ACID-ity of a relational system guaranteed that money was counted quickly and accurately.
MongoDB has been working toward improving its consistency guarantees ever since it bought Wired Tiger back in late 2014. The company has always supported single-document ACID transaction guarantees, but it still pushed the technical complexity required to deliver full ACID guarantees for transactions that touched more than one documents out to the user.
At a launch even today in Seattle, Washington, MongoDB co-founder and CTO Eliot Horowitz announced that it will support multi-document ACID transaction guarantees with MongoDB version 4.0, which is currently in beta.
“This morning we are announcing that MongoDB is officially dropping ACID,” Horowitz said. “So multi-document, fully ACID documents are coming to MongoDB 4.0 this summer.”
Transactions in MongoDB will behave just like they do in other databases, Horowitz said. “They’re going to be completely familiar to anybody who’s ever used transactions before,” he said. “You begin a transaction, you commit a transaction, you void a transaction just as you expect.”
Support for multi-document ACID transactions will make it easier for MongoDB customers to develop complex applications, and will eliminate the need for developers to write application-layer code to handle the transactions, according to Park. “You had to write this extra block of code to handle two-phase commit or distributed transactions in MongoDB,” he told Datanami.
The new feature will make it easier for a financial services firm to use MongoDB to power a trading system that automatically performs some operations, like creating roll-ups or aggregate reports, upon completion of a trade, Park said. Support for multi-document ACID transactions will also come in handy in the e-commerce arena, where stock-keeping units in an inventory system need to be decremented when a customer completes a purchase.
It wasn’t that MongoDB customers couldn’t build these types of systems, Park said. In fact, they did. Morgan Stanley, for example, has publicly discussed a swap equities platform it developed with an older version of MongoDB. In some cases, investments that customers make in creating a better document model on the front-end could eliminate some of the complexity associated with accurately supporting multi-document transactions down the road.
In any case, all that technical complexity is all now handled automatically by the database, which will theoretically free the developer up to focus on her application.
MongoDB 4.0 will allow users to selectively use the multi-document transactions feature in their cluster as they see fit. Because it will come with a performance cost, users will be able to turn it off when they don’t need it.
“If you’re not using transactions – if a write doesn’t have a transaction, there’s absolutely no performance penalty whatsoever,” Horowitz said. “If you want to use a transaction for one tiny little operation and nothing else, you’ll see no performance impact.”
Park was not able to share details about how much of a performance hit the new feature will bring, but promised that MongoDB will be publishing benchmarks in the near future to help customers make good decisions.
The same Wired Tiger storage engine that powers multi-document transaction guarantees can be configured as a fast, in-memory data store. It’s all about making the product flexible for a broad set of use cases, Park said
“So if you want to have very low-latency, high-performance, high-throughput, you can put an in-memory storage engine in place,” he said. “It’s a pluggable storage engine architecture, so we want to have fit-for-purpose storage engine for right use case.”
While MongoDB has mostly been used for developing new Web and mobile applications, Park hopes the new support for multi-document ACID transactions will bolster the case for running existing business applications on NoSQL.
The pain of moving off relational is arguably not as high as enterprise customers feel, and the payoff of moving to NoSQL is potentially much bigger than they anticipate, he said. “Sometimes they don’t understand there’s maybe less risk than what they’re thinking of, and there’s actually much more positive business benefit in terms of moving and re-platforming to a modern database,” he says.
“This is ultimately for us almost the last step in terms of getting to the point where developers honestly don’t even have much of a choice to make anymore,” he said. Developers “should never be forced to use a relational database again.”
Editor’s note: This story has been corrected. MongoDB has always offered strong consistency guarantees, and has never taken the eventual consistency approach. But prior to 4.0, the consistency guarantee was only for single document transactions, not transactions that touch multiple documents. Datanami regrets the error.