
Ask HN: Should I not use MongoDB? - nikkwong
Hi guys, I&#x27;m a mostly front end dev who&#x27;s built some mildly popular applications where Mongo has worked fine as a data store. By mildly popular we&#x27;re talking maybe 1 query&#x2F;s. Today, I just launched a product (www.bliss.flights), and it&#x27;s unexpectedly gone viral, we have more signups than I could have ever imagined.<p>I peruse HN a lot so I&#x27;ve read a lot of the recent articles about how Mongo has failed a lot of startups as a production DB. Now that we&#x27;re figuring out the technology stack for this, I don&#x27;t want to do work that is going to have to be redone later.<p>Unfortunately, I&#x27;ve only ever used Mongo, so I&#x27;m used to mongoose and it&#x27;s syntax. Would you guys use a different datastore for something like this, and if so, what? I&#x27;ve written maybe a few lines of SQL in my entire life so not so bullish on learning something new as it will really slow us down!<p>Really appreciate it.
======
scalesolved
"Now that we're figuring out the technology stack for this, I don't want to do
work that is going to have to be redone later."

You're worrying about problems that you don't yet have and at scales you may
never reach. I'd say stick with what you know and see if you can get initial
traction with your users.

If your data is highly relational then yes it's not a great fit but it's still
passable if you're happy to give up transactions and the ability to force data
consistency etc.

Where I work we have a production API serving thousands of websites that uses
Mongo, don't sweat the details too much early on.

~~~
nikkwong
Yeah, I feel like through using Mongo I've learned how to model my data in
ways that are not relational, which has worked well because using aggregation
at all always tends to be really awkward.

Agreed that it could go no where, but, I'm hoping that one project, at some
point in my life does well—so learning a technology that doesn't suffer from
scaling issues would hopefully be a road I eventually have to take.

Appreciate the feedback!

------
kenwalger
MongoDB is definitely ready and capable of handling your traffic. There are
best practices to follow, however, as is the case with any deployment. I would
concur with mattbillenstein that HN definitely skews anti-mongo.

There are many, many companies using MongoDB very successfully. I have found
that "issues" being reported with MongoDB are based on old versions and
information, or an improperly configured and tuned environment. I recently
wrote a blog post covering some topics around this. I'd encourage you to read
it: [https://www.kenwalger.com/blog/nosql/mongodb/mongodb-
perform...](https://www.kenwalger.com/blog/nosql/mongodb/mongodb-performance-
issues/)

I think you'll find that MongoDB will meet, and exceed, your expectations for
performance.

~~~
nikkwong
This is very reassuring, thank you so much!

------
mattbillenstein
HN skews very anti-mongo, but it can be a good fit for certain apps -- I would
stick with what you know until you think you've outgrown what you can do
without sharding. I'd probably never shard mongo, but if you can vertically
scale it for awhile, I'd do that.

If you're on ec2, the i3 instances have very fast nvme instance storage at a
reasonable (cloud) price.

~~~
gerenuk
What would you suggest instead of mongodb for large scale production db? Our
DB size is growing on daily basis and currently near to 200GB on a dedicated
machine.

~~~
mattbillenstein
It depends -- if it's analytics, I'd look to ship it to a hosted system (I
like BigQuery). If it's not, you might be able to scale up to terabyte or two
before sharding; then maybe cassandra or one of the sharded postgres things
(Citus, postgres-xl?)? I haven't had that problem in awhile.

------
mikegray831
Another user of MongoDB here. Thus far it has scaled well for us where we had
a similar situation where uptake was faster then expected. The WiredTiger
storage engine made most of the concerns of 2012-2013 for MongoDB, non-issues.
However, if you try to put a relational model in to MongoDB, you still may see
performance issues down the road, but then again it should be about the right
tool for the right job. I'd reiterate Ken Walger's post to checkout his blog,
it does a great job of comparing MongoDB 2012 vs. MongoDB today. Also, if
administration/operations are a concern, then cloud provided MongoDB is the
way to go, MongoDB Atlas seems to be at the forefront since it's run by
MongoDB itself. Good luck with your apps!

~~~
nikkwong
Thanks so much! We currently use Atlas and it's been pretty great, although
prohibitively expensive for my small side projects, where mLab instead has
been awesome.

~~~
rlmongo
Are you aware that MongoDB Atlas has a free tier too?
([https://www.mongodb.com/blog/post/announcing-free-tier-
and-l...](https://www.mongodb.com/blog/post/announcing-free-tier-and-live-
migration-tool-for-mongodb-atlas))

------
smt88
The hatred and fear of Mongo is justified. That doesn't necessarily mean you
need to switch right now.

If you're just using a document DB instead of a relational DB, you won't have
a hard time moving away from Mongo. There just isn't that much to learn.

Even better, there are various databases that actually have Mongo
compatibility[1][2], but internally will be more reliable and scalable.

If you have the dev bandwidth, look into switching now and maybe give it a try
in your dev environment.

1\. [https://www.torodb.com/](https://www.torodb.com/)

2\. [https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-
int...](https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction)

~~~
jd_mongodb
'Hatred and fear" ? This is a database we are talking about?

Companies all over the globe are betting their businesses on MongoDB and
succeeding.

e.g. most recently Ticketek

[http://www.theaustralian.com.au/business/technology/mongo-
mi...](http://www.theaustralian.com.au/business/technology/mongo-migration-
just-the-ticket/news-story/fa3356b5ac731fa606b1bfa6252ab218)

~~~
jaydestro
mongodb employee here

[https://www.mongodb.com/who-uses-mongodb](https://www.mongodb.com/who-uses-
mongodb)

I don't see a ton of hatred and fear from Cisco, Facebook and Google.

I dig what they've done, especially facebook, with MongoDB. Reconsider 2012
opinions and read about 2017's MongoDB.

~~~
smt88
Instead of insulting me with the implication that I don't keep up with major
technologies in my industry, you probably would've been more convincing if
you'd told me what's changed since 2012. However, I do keep up with Mongo, and
I do know what's changed.

It still doesn't make me want to use it. Relational data is better for most
applications, Redis is better for many others, and I can have both documents
and relational data in the same database with PG[1].

It seems like many other people with Mongo experience feel the same way[2].

1\. [http://www.aptuz.com/blog/is-postgres-nosql-database-
better-...](http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-
mongodb/)

2\.
[https://news.ycombinator.com/item?id=15125984](https://news.ycombinator.com/item?id=15125984)

------
twobyfour
Mongo is the right tool for some jobs, but it's a poor choice for many.

I recommend you learn at least one alternative database paradigm
(relational/SQL databases are probably a good choice) so that you can make
informed decisions about the trade-offs between data stores each time you
start a new project.

------
giaour
Running your own Mongo instance will probably be fine for now. I remember
Mongo administration being a massive time sink, but it only gets truly hairy
when you need to shard and cluster. You can always use a hosted Mongo instance
or a hosted Mongo-compatible solution like CosmosDB.

------
jaydestro
hey there, i am a person from mdb:

one thing i should express, many of the negative sentiments of mongodb are
related to outdated facts or commentary. review some of the new features to
ensure you're getting all the benefits mongodb has produced since the days of
2012.

~~~
dsirola
That's not the problem in my opinion. The problem is advertising any kind of
document DB as a general purpose storage. If you have a use case of making
different aggregates from data, you'll have a bad time duplicating data or
creating your own consistency layer.

------
johnpython
MongoDB is the wrong choice 99.9% of the time. Just use Postgres.

