MongoDB rebuts claims it's not ready for business critical workloads 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 …
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.
I was partime DBA of a shop with RDBMS and MongoDB mix.... the developers choose Mongo for the Catalog of a web agro retail because of the very broad set of the products and their atributes that they sold, it was a very complex task for a relational model to get that data into de DB. But all the transactional part of the the site was left to the RDBMS because it just works.
As a DBA, is complex get the control of a NoSQL db, mainly because the data structure is very lax and under full control of the developers.
No, you don't have it right, MongoDB's schema is very loose and defined by the client application. Which can be really great for application developers. But it's not really designed for or compatible with DBAs so I completely understand why any DBA would hate it. The actual database itself is basically a back end for a MongoDB client library and all the validation occurs on the client. This can be convenient for software developers because your web servers (that are cheap and plentiful) can do more of the work.
I work with a mix of different database types and there are a few things that MongoDb is massively better at than a relational database like complex data structures that have a lot of nesting. And for general CRUD it's not really any better or worse than a relational database. And it's very good for distributed databases and very large databases because of the ways the data can be sharded. What MongoDb sucks at is managing a bunch of related data in different collections (which are like tables). It's mostly about structuring your data in a way that makes sense for the database because if you build your MongoDb database like a relational database it'll suck, because there is no "relational integrity", each collection should be a contained concept (possibly a very complex one).
It's a tool in the belt, just like relational. But it's good to have some experience with different types of database so you don't end up in the "if all you have is a hammer everything looks like a nail" situation. Next time you build a trivial project I suggest you give it a try.
Yeah, a bit like time series systems, document databases can be useful for processing lots and lots of ephemeral and roughly similar records defined in JSON. Because it doesn't care about integrity, it scales quite well both for reading and writing. I think they're quite popular in message brokers where the publishers and subscribers expect a little flexibility.
But RDBMS are also pretty fast if you disable integrity! ;-)
https://www.youtube.com/watch?v=b2F-DItXtZs
Gorgeous! The comment on performance did it for me. ;)
Mr Squiggle: "I suggest you pipe your data to /dev/null, it will be just as fast."
"it lowers the barrier to entry"
This is the wrong answer.
MongoDB should be *raising* their very low requirement - in terms of volume of data - for customers to have to shard, not lowering the barrier to sharding.
Try getting a definitive answer to the question "At what volume of data do I need to shard?" The answer is very revealing.
MongoDB is easy for developers to get up and running, and way too many developers don't think beyond that point. They don't consider data integrity, or relationships between data... and they certainly don't consider the other end of the line where you need to generate reports based on that data.
Next thing you know, the project is well into development and you discover that it's virtually impossible to pull critical metrics from your data without developing a custom reporting engine.
Rule of thumb... If you are unable to concretely explain _why_ you need to use a specific database type (and this goes equally for graphql and others, as it does nosql), you should stick to a standard RDBMS like Postgres.
And no, being "easy" is not a valid reason.
article: Enhancements in the 8.0 release include claimed 32 percent better throughput and 56 percent faster bulk writes.
cow: i would have thought Mongo was magnitudes faster than just 32% or 56%, given you have zero guarantee that data doesnt disappear because of no transactions and acid.
Its a mystery why anyone is using it given those figures from MONGO itself. Hardly a shock given most of the world are idiots who just copy everyone else without any criitical thinking.
While never a DB chap, I always took an interest in data (and knowledge) representation and storage.
A book that I read in the 1990s viz
Logical Introduction to Databases, John Grant OUP 1995
made me appreciate that the relational model was logical abstraction that could mostly be divorced from its physical implementation. This was a major point in Codd's original paper. Whether you used SQL or QUEL or similar you could locate data without any understanding of how it might be stored ie declarative in nature.
I guess many of the arguments are about ACID and other properties which span both the logical and physical aspects of databases.
As always "you pays your money and makes your choice."
I am gratified to note that Postgres is alive and kicking (arse? ;) which must give Michael Stonebraker some pleasure.
I can say frrom experience that object stores, data stores, and document stores each have their own model and purpose in the development arena, but the most common use case is to have an RDBMS "own" the data with reference links and keys to the object stores and document stores so that the latter have their access secured by the application server code, not the application client.
Trying to claim one can do the job of the other is really misunderstanding the fundamental mechanics of how they work and why they're efficient at what they do. No competent computer science graduate would make that mistake, only a bean-counting MBA.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
