News: 1727940369

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

MongoDB rebuts claims it's not ready for business critical workloads

(2024/10/03)


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.

[1]

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.

[2]

[3]

"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.

[4]

Kimball [5]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.

[6]MongoDB takes a swing at PostgreSQL after claiming wins against rival

[7]MongoDB CEO says if AI hype were the dotcom boom, it is 1996

[8]MongoDB loses nearly a quarter of its value after adjusting revenue forecasts

[9]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. ®

Get our [10]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zv5rQYp0bT2mC0zlRIcV-gAAAFQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zv5rQYp0bT2mC0zlRIcV-gAAAFQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zv5rQYp0bT2mC0zlRIcV-gAAAFQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zv5rQYp0bT2mC0zlRIcV-gAAAFQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://www.theregister.com/2024/09/27/cockroach_labs_ceo/

[6] https://www.theregister.com/2024/08/30/mongodb_postgresql/

[7] https://www.theregister.com/2024/09/13/mongodb_ceo_says_if_ai/

[8] https://www.theregister.com/2024/05/31/mongodb_valuation_dip/

[9] https://www.theregister.com/2023/11/28/couchbase_columnar_side_store/

[10] https://whitepapers.theregister.com/



Just a humble BI developer

AMBxx

I don't work with MongoDB but can someone confirm my understanding. If I have it right, MongoDB performs best when it has a proper schema confugured just like a relational database?

Think I'll stick with Postgres and MS SQL.

Re: Just a humble BI developer

werdsmith

I do use Mongo, but only as a way of keeping up my knowledge. I certainly haven't found the compelling use case to choose it over relational, though I am sure there is one. Especially as they seem to be totally focused on Atlas which requires you to implement your whatever solution in the cloud.

I can see why cloud because the configuration of mulitple redundant shards is an admin headache. Absolutely scalable but niche cases require it. Not compelling.

Captain Hogwash

MongoDB is web scale.

ForthIsNotDead

What does that mean? Most web projects, with tens of thousands of users will happily run on a single RDBMS system. Are we talking online retailer selling plumbing spares, or facebook? :-)

Captain Hogwash

https://www.youtube.com/watch?v=b2F-DItXtZs

Doctor Syntax

"sort of defining the way their data model looks"

If somebody is "sort of" defining "the way" their data model "looks" I can see why they might need flexibility. I think that just defining the data model is the way to go, however.

[...] or some clown changed the chips on a board and not its name.
(Don't laugh! Look at the SMC etherpower for that.)
-- from /usr/src/linux/MAINTAINERS