I agree, although I think the use cases for non-relational databases is overstated, but I view MongoDB as one of the most dangerous pieces of software I’ve had to touch. It demos great, but long term usage of MongoDB has been nothing but pain for me. Lost writes, all three nodes deciding the other is primary, crappy performance if you’re just outside of the indices, and extremely painful migrations all come to mind.
I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.
Let me echo that sentiment, I also hate MongoDb. I had to setup / manage a MongoDb cluster in 2012-2013. It was a giant shitshow. Maybe things have gotten better, but I have little desire to test the waters with MongoDb again. I'd rather use https://www.rethinkdb.com/ if I really needed NoSQL / scalability.
I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).
Performance is definitely an important aspect, but coming from a background working at smaller companies, bootstrapping time and development time are a factor as well -- and while Postgres is easy to set up if you're familiar with it (and I dare say it makes DB design fairly straightforward), Mongo and other NoSQLs are pretty objectively easier to just get working if you aren't fluent in relational databases.
No offense, but if you don't know how to design/develop a database schema, making it easier to shoot yourself in the foot by using NoSQL database is not the answer.
None taken. And I agree -- but database design is inherently different under SQL and non-/noSQL. Constraints and relationships may be modelled completely differently in either case.
Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))
The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...
You're technically correct, but this case study was really eye-opening to me: http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht... They migrated from a RethinkDB cluster (similar to MongoDB) to a single Postgres server and the result was faster. And a single server is very large today, like 48 cores and 384 GB RAM.
While Postgres definitely has support for document-store like behaviors and can function in that capacity just fine, that's not the same thing as saying you can just substitute it for a document-oriented store like MongoDB.
Having said that, for someone who's already using Postgres, it's a great way to introduce some document-related behaviors (as opposed to strictly relational ones) by using the features it already has.
Even MariaDB is taking steps in this direction with many non-traditional relational types of storage options now available.
I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.