MongoDB rebuts claims it's not ready for business critical workloads
Shifting battle-hardened systems to document model – are your skills and tools ready?
MongoDB has used the release of version 8.0 to defend its viability as the underpinning of business-critical transactional systems.
The document store database is rated the fifth most popular database by both DB-Engines and Stack Overflow's developers survey. Major developers like Adobe, Bosch, and Ticketmaster use it for modern web and mobile applications. However, debate still rages over whether its document model – which sees data stored in BSON files – is a suitable alternative to the more traditional relational databases that underpin most business-critical applications that process high transaction volumes, all day, every day.
Enhancements in the 8.0 release include claimed 32 percent better throughput and 56 percent faster bulk writes. MongoDB also says it has achieved faster horizontal scaling for high availability, and reduced application costs.
Speaking to The Register ahead of MongoDB's conference in London this week, chief product officer Sahir Azam explained the improvements in price-performance are partly due to a new approach to sharding – an approach to improving resilience and performance by dividing large distributed database into smaller units stored across multiple database servers.
"We've made it easier and cheaper for customers to get started with sharding, because now we offer the ability to co-locate config servers with the core data bearing nodes, which makes it easier and more cost effective when you're starting off – you do not have to have an extra infrastructure. As your application scales, you can choose to decouple those things for better isolation and better tunability later on, but it lowers the barrier to entry," he said.
Last week, Spencer Kimball, CEO of Cockroach Labs, which makes the distributed relational system CockroachDB, opined that while MongoDB is great for mobile applications and web applications, it is not suitable for business-critical transactional systems.
Kimball explained there was a "cumulative tax" on document store systems, which accrued over time and made them unsuitable for long-lived business-critical applications. He argued that one of the unheralded benefits of relational databases is that, through defining their schema, they allow complex use cases to develop over five to ten years.
We've allowed customers the flexibility to introduce things like typing schema validation and governance of different versions of the collections for years now.
Azam said it was a "common misnomer" that just because MongoDB has a flexible schema, it is not governed and completely schema-less. "We've allowed customers the flexibility to introduce things like typing schema validation and governance of different versions of the collections for years now."
Some MongoDB implementations were tightly governed in terms of their schema, he said. "The typical arc, early on in development, customers want a lot of flexibility as they're sort of defining the way their data model looks. But then as the application and the development team starts to scale, they start to layer in governance and schema," Azam added.
The chief product officer denied MongoDB has a scalability ceiling beyond which it is not suitable for business-critical systems. He pointed to the fact that financial services orgs – which famously have negligible tolerance for unreliable systems – have built core transactional systems on the database. to cement his view that MongoDB can work in very demanding roles.
- MongoDB takes a swing at PostgreSQL after claiming wins against rival
- MongoDB CEO says if AI hype were the dotcom boom, it is 1996
- MongoDB loses nearly a quarter of its value after adjusting revenue forecasts
- Couchbase takes fight to MongoDB with columnar side store upgrade
Azam hasn’t convinced everyone.
Adam Ronthal, research VP in Gartner's ITL data and analytics group, said the document model of databases like MongoDB appealed to developers for its flexibility and agility, particularly with its distributed scalability. However, he noted achieving transactional performance required some redundancy.
I've always struggled a little bit with MongoDB's assertion that they're going to go in there and replace all these core relational systems built on mature RDBMS platforms like Oracle and Db2 …
"MongoDB specifically recommends a denormalized data model to minimize the need for distributed transactions spanning multiple documents because of the performance impact there, but they do represent fundamentally different data persistence paradigms [to relational systems]. I've always struggled a little bit with MongoDB's assertion that they're going to go in there and replace all these core relational systems built on mature RDBMS platforms like Oracle and Db2, and they've been talking like that since 2016," Ronthal said.
While it might be possible to build that scalable and robust transactional system on MongoDB, users need to question the benefits of the move, along with how much they can apply their existing mix of skills and tooling to the problem.
"Swapping out your database is like open heart surgery. It's never as easy as you think it's going to be, and it always takes a little bit longer than you think it's going to," the analyst opined. ®