
Ask HN: Does anyone have success stories with MongoDB? - jitix
When we talk about MongoDB most of the discussions focus on how people have lost data and have had operational issues with it.<p>Are there any companies&#x2F;teams that have successfully deployed and scaled MongoDB in the recent years? If so why did you choose it despite the negative publicity and what kind of data and access patterns are you using it for?
======
kenwalger
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...](https://www.kenwalger.com/blog/nosql/mongodb/mongodb-performance-
issues/)) and Data Durability
([https://www.kenwalger.com/blog/nosql/mongodb/data-
durability...](https://www.kenwalger.com/blog/nosql/mongodb/data-durability-
mongodb/)) 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.

~~~
jitix
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.

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

~~~
jitix
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)

------
mhoeller
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. :-)

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

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

~~~
jitix
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.

------
arivelli
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

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

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

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

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

------
evalero
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...](https://dzone.com/articles/why-we-moved-from-nosql-mongodb-to-
postgresql)

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

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

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

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

------
ibiwan
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!

------
opotoc
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 ;)

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

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

------
kcanache
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

