There are many, many companies that rely on MongoDB. Companies like Google, Facebook, Cisco, Expedia, eBay, just to name a few.

In my experience data loss and operational issues are a thing of the past. With the current version of MongoDB, 3.6, there are lots of data safeguards in place. One of the biggest frustrations that any company faces in the age of the internet is old topics of discussion. MongoDB has come a long way since many "problem area" blog posts and articles.

If you haven't tried out the latest version and put it through its paces, I would highly encourage you to do so. Judging by reports of others here as well as performance and security analysis done by outside vendors, MongoDB is truly web scale.

I've written my own blog posts on MongoDB Performance (https://www.kenwalger.com/blog/nosql/mongodb/mongodb-perform...) and Data Durability (https://www.kenwalger.com/blog/nosql/mongodb/data-durability...) which, while based on MongoDB 3.4, still offer some useful insights into the current state of MongoDB.

Try it out and report back your own findings.

I've tried out many major versions which add new features (MVCC in 3.x was a game changer IMO). But it's just difficult to convince a lot of engineering teams these days to use MongoDB because of all the negative reviews floating around.

I have worked on several projects that successfully used MongoDB over the past six or seven years now with three different companies. One project had over 5TB of data spread out over a couple of databases with numerous collections each, and no we didn't shard that database. We also didn't have any issues with accessing the data at that size. When I see negative stories around a technology, especially databases/data storage, I personally like to dig in to see if things are as bad as people say. All platforms can have issues (don't get me started on SQL Server and torn pages ;) ). Most of the negative press I've seen around MongoDB was from people not understanding the technology. Sure there were valid issues/bugs and some people might have lost data, but I don't think it was as widespread as some posts would have you believe (except for those running old versions accessible from the internet without proper authentication that is). Also a lot of posts that keep coming up are from several years back. MongoDB has changed a lot over the past couple years, and they continue improving the platform with each release. Bottom line, understand the platform before using it, learn it's strengths and weaknesses and you should have a successful implementation as well.

Me too. One of my consulting gigs back in 2012 was based on MongoDB and the system is still working well in production afaik. The use case was to store complex documents but size wasn't an issue, nor was the global table lock (it was a law firm's document management system). But over the years people's opinions seem to have changed from neutral to outright hostile when I bring up MongoDB.

Also I used mongo's map reduce framework back in the day for reporting, something that stored procedures are still lagging behind (based on my experiences in MySQL and Postgres)

Hi there, guess there are plenty of companies out there with success stories. Personally I have been quite septic when I was asked to use MongoDB for a government project in the area of tax income prediction. We stared small more in terms of an POC, but the success came faster than we thought and we had to scale out. Luckily this was a really easy task with MongoDB. That it is purely made for it but it is one of its pros. An other project, last year was in the area of health / hospital software with faily high security and HA targets. Also this was easier that thought in the beginning. The more I use MonogDb the more I like it. Personally I think the success story of MongoDB is just in its Beginning but this is my own opinion. The best thing you can do it to give it a try. But please do not make the same error like me. First get a very good understaning of the document model than design your DB. Many calls for help I get can be boiled down to a design which was obviously make be some one who was still thinking in relations instead of documents. Have fun and enjoy, as soon as you climbed the hill and start thinking in documents you have passed the line. :-)

Yes I do, I've deployed MongoDB cluster with 3 node replica set for production. I've started with single instance MongoDB for development with version 2.2.2. Right now I'm using 3.6. It is a nice journey with MongoDB. I learned about data and science from MongoDB only. Eagerly waiting for 4.0.0 when I can use transaction also.

In my company, we are currently working on several projects backed by MongoDB. All of them do it successfully. Everybody I work with is really happy with MongoDB. I only know one user that thinks MongoDB has not a really good performance, why? He compares it with ElasticSearch in a strict search use case. As you can see, he is not making a good comparison. So, it's better to learn and test before saying uncertain phrases.

Do you guys have any whitepapers/engineering blog posts about using MongoDB? I'd really like some engineering insights into what access patterns are used in modern MongoDB based systems.

Also, regarding ES, its easy to see how each system prioritizes things. For me if I had to design a system today I'd use MongoDB as the main OLTP database, use ES for search (with regular jobs syncing data between Mongo and ES), and use Hadoop/Spark for analytics. Mongo is decent for OLAP loads but there's no point running OLAP queries on production OLTP stores.

Yes, I'm working to a global company in a global project, its hard to describe how we use the database but in simple terms, we store the information of customers and their preferences about alerts & notifications, params & configuration about the alerts and of course the alerts sent by our application. about the negaive publicity I think in most of cases it related with mistakes about how to work with mongodb.

Regards

We use MongoDB in several capacities on several projects: A cache/ speed layer for content distribution worldwide (relying on replica set across data centers), an event source for customer loyalty and profile management, and as a backend for an e-commerce style customer facing web store. In each of those projects we leveraged several mongo features that were well suited to the problems we had. Our mongo clusters have been remarkably stable and work very well. Our scale has not required sharding at this point. Our QPS and write rates have been well within the design SLA. We did have to periodically analyze query performance and apply index and or query syntax changes, but other than that didn't encounter any issues. The biggest wins for us was time to market and flexibility: Compared to the RDBMS counterparts, we move faster, resolve issues faster, and deliver web pages faster. The negative publicity has been "in the noise" and typically reflected more negatively on the generators of such rather than the product itself.

Caching is an interesting use case. I never thought about that. Would love to see a blog post/writeup on that.

I've used MongoDB extensively for the aggregation framework. The tools within that subset of mongo provide a rather granular and speedy approach to manipulating compound datasets into usable, normalized results. I recently built a translation service using MongoDB as the backend, and utilized the aggregation framework to weight and score translations based on different criterion.

We use MongoDB as our primary database (hosted with Mongo Atlas) here at Mixmax and it's been a pleasure to use. It's allowed us to move very quickly by not having to deal with schema migrations when adding new features. We have a few terrabytes of data and a query volume of about 1k writes a second.

I have helped to several companies working with MongoDB and now they have deployed more instances in other "old" services to speed up the performance.

I Think that MongoDB needs some maintenance and attention like other databases. If you use MongoDB because your stack is based in javascript and you think that it could be easy because support javascript based commands but you don't have any background as dba, you will fail like this guys: https://dzone.com/articles/why-we-moved-from-nosql-mongodb-t...

I have experienced issues too, but nothing catastrophyc because I have studied so much this technology and I feel confortable

We did in 2014 a rewrite of an API that was in SQL Server for MongoDB along with asp.net. It was very good, very fast and very satisfying. This was my first professional contact with mongodb.

We using MongoDB for many internal projects (ASP.NET Core) in our big company. Biggest replica-set - 3x(8 Xeon cores and 32GB RAM) has 600 inserts/600 update/500 deletes in second without any sharding. Average CPU load on primary node ~ 30%.

Average document size ~ 50 - 300KB. It work perfect with authomathic failover, when Oracle with their CLOB types collapsed with Disk IO. MongoDB save a lot of time for us.

But first you need to understand how it works and then you'll love it too.

At my current company we're using it for several purposes, caching layer, documented oriented data, disparate data sets that have frequent change. In our experience as well as many others the MongoDB issues of the past have largely been fixed. I'm hopeful that people's perceptions of MongoDB will change as the product continues to address the needs of the development community while continuing to build a strong database product.

We use MongoDB for performance, as a kind of caching layer in front of our relational DB. Since it's pretty well normalized, joining all the tables together for a web page render takes forever, so we do that once and store it in Mongo, then just return that whenever a site needs data!

I wonder where all these horror stories come from - I only have seem 'loss' of data if people were not trained using MongoDB. An I mean not trained at all, MongoDB is easy to learn. There are plenty of success stories by major companies out there, google them ;)

We use mongodb shard cluster to support up to 10k simultaneous users for our web application. Without this sharding architecture, no matter how big our sql server is we can't handle that work load.

i`m new in mongo but i`m happy to learn everything about it, for the moment i`m to fresh to throught to opinion, but it is an excellent way to storage data.

i`m new in mongo but i`m happy to learn everything about it, for the moment i`m to fresh to throught a opinion, but is an excellente way to storage data