Maybe you should never use MongoDB

I have been working on a large project (10+ devs) running MongoDB in production for the last 2.5 years.

I agree with this post, for a few reasons:

• lack of schemas cause lots of runtime errors unless your super diligent with migrations/validations. You can use the their JSONSchema functionality, but there’s not great tooling around it
• most application data is relational, and you end up implementing a lot of relational stuff in your application tier. No foreign key constraints if you have reference between docs. Denormalization means it’s hard to update simple things.
• BSON object ids are super long and confusing. It’s so much easier to look up things with integer ids. Good luck trying to implement incrementing ids in Mongo.
• for some advanced use cases, aggregation pipelines fall down. It’s hard to do advanced searching in a performance way across collections. Also, aggregation pipeline syntax is so hard to reason about and develop. Every developer I’ve worked with (including myself) struggles with it.
• too much vendor lock-in to make me comfortable. Mongo changes its license recently so Mongo Corp is the only company that can offer hosting, etc. with SQL, you’ve got a number of stable open source options that mostly interop.

I agree that Mongo can be fast for application prototyping, but it’s then hard to get off it once you’ve got a prototype. I don’t really think prototyping in SQL is that much slower if you use a high-productivity framework like Rails or Laravel.

There are definitely some valid use cases for Mongo, I just don’t think the majority of business applications where Mongo is the primary storage tier is one of them.

Just remember, you can’t spell Mongo with “OMG NO”. ;P

PostgreSQL supports the JSONB datatype which can allow for some document db like use cases to exist alongside a proper relational schema.

I have been exploring Postgres lately and there is a ton you can do if you learn SQL.

It's really is not that black & white. We've also failed with MongoDB at SoundCloud

https://developers.soundcloud.com/blog/web-scale-statistics-failing-with-mongodb

That still doesn't mean I would completely rule it out for all use cases. It all depends.

How much data do you have? How fix is your schema? What read/write loads do you expect? What are the access patterns? Will you use it in a cluster setup? There are many angles to this.

What I also like to note: Not all NoSQL databases are the same. They are often very niche products - and in that niche, can do a pretty darn great job. But your data and even more so, your data modeling skills must align. Coming into this with a SQL mindset might well end up in some tears.

SQL databases are old, trusty work horses that do a fine job for 80% of the problems. After all these years we have somewhat decent tools and more importantly experience with them. But also be aware of that bias. In fact - if you take a step back, isn't it really a bit awkward we are still pressing object graphs into tables? We just have gotten very good and accustomed to it.

Just use what you feel comfortable with and what does the job for now. Just watch the dataset in comparison to your indices and memory usage. When you need to scale it's a good problem to have. Often enough that doesn't just impact your database but your architecture as a whole.

Feel free to reach out when you get into trouble or have more specific questions.
https://twitter.com/tcurdt

Great timing, yesterday I made the jump on an internal work project from PHP/MySQL to Electron/React/MongoDB. The common "stick with what you know" was shadowed by "cool new stuff".

I used to be guilty on making decisions under the influence of the shiny object syndrome. I tried to build some projects using nosql instead of sql. It's way easier and faster to start development and get it running, but once you start adding more and more, you end up fighting the limitations of such database.

It all boils down to the requirements, and in 99% of the cases, the core functionality of a web application is relational data (if you have users, no matter what the other data models/resources are, you end up with at least the ownership relationship between users/teams/companies and those resources.

Nowadays, as NoSQL, I use mostly redis for caching and a search engine (elasticsearch or solr) for indexing big quantities of data that need searching. I have MongoDB too many chances and each time, I was ending up fighting it more than it helping me.

Yeah, I actually find it advantageous to prototype using MongoDB, especially if you can expect your schemas to change rapidly. Less overhead early on, but maybe not the greatest choice long term.

Mongodb and other similar db designs have its role. If you know what the data will be beforehand, an SQL structured scheme isn’t so bad.

The biggest problem with MongoDB is that it's most often used as an RDS anyway. So why are they just not using an RDS? MongoDB has serious drawbacks when you try to use it in this way. Just use Posters, it has the best of both worlds.

The problem I think is that Mongo is sold in a lot of cases as a rapid prototyping tool, and something where you can store data and not "really" care about how you're saving that. That makes it very attractive to a lot of newer or more front-end focused devs, but really presents a lot of issues when you move passed a prototyping stage.

I recall the first time I used Mongo it was nice not really having to worry about schema and just saving my data. As you can imagine, this ended up causing problems down the line and the speed I saved upfront I probably lost trying to fix my data.

That said, Mongo isn't a bad choice but I always say to keep in mind that

1. Most data is inherently relational. Think long and hard before you use Mongo (or any NoSql database for that matter) and think through why it seems beneficial.

2. Understand that your schema shouldn't be a free for all. Especially as a project grows, having some sort of schema enforcement or validation is going to be crucial. If you're just randomly saving documents with differing fields and not really thinking through the repercussions of that you're going to have a bad time.

I agree... I used to be in the same boat...now I use Nextjs+firebase for almost all my side hustles

This is a great discussion! I've used both SQL and NoSQL as a developer, and have wondered about the "hype vs functionality" paradigm many times. This discussion has made it clear that my concerns were valid.

It's always interesting to me that new devs reach for NoSQL first. I've always found SQL + relational DBs (preferably PostgreSQL) to be much easier to work with, and to reason about. The "hard part" is figuring out the schema, but that's the same with NoSQL, but now I don't end up with runtime errors as often.

It depends on the use case/context. Pretty informative article though.

It depends what you need. Doing a non relational database and simulating relational DB is always a bad idea.

things are made different with a purpose, and if we are using new things with an old, existing approaches, it will always result in some form of Frankenstein.

I mostly agree with you. But also I think you can mitigate a lot of these problems by using a ODM like Mongoose.

I feel like NoSQL is good for prototyping and a more lean approach to get out an MVP, because in most cases you don't how the data will look like. Long term though, it's not as reliable as SQL.

i have bought a project with a previous owner had it on mongodb , performance was very bad and it impacted the project so hard that he saw no way out anymore. first thing i did was migrate it to mysql.

but in another instance i bought a project that was on mysql , and the performance was bad too ... it was a 10 minute fix : adding indexes to the tables ...

whatever you select to store your data , take the time to find the best solution and invest time in reading some articles how to get good performance out of your stack

With any new tech, my instinct is to take a look and maybe play around with it, but wait a couple years before using it for anything serious - enough time for the hype to wear off, the success/failure stories from early adopters to come out, the ecosystem to grow and the bugs to be fixed. In the case of MongoDB that would probably have been a wise decision. It's still around, but there is more clarity about where it shines and where you'd be better off with an RDBMS.

Having or not having the schema has it's own pros and cons. As you mentioned, the biggest advantage of schema is consistency of your data.
But in some cases, when you work with unstructured data (from third-party services, for example) or for rapid development not having the schema could be advantage.