I'm of a similar opinion. I experienced all the issues of MongoDB's infancy; it wasn't a good time, but the mmap functionality seemed worth it at the time if you had enough memory or constrained your access patterns appropriately.
Nowadays, PostgreSQL has JSON/JSONB types, a full suite of extensions like pgvector and PostGIS, and I can scale with Citus or use it in any of the big managed clouds.
From a functionality perspective, MS SQL Server makes a more compelling alternative to me simply by way of its native graph database support.
Mostly that Postgres is amazing, runs anywhere and supports jsonb (which I use a lot). And I don't want to worry too much about mis-modeling; that's the entire point of a relational database with a type system.
Plus all the Mongo horror stories from people who I know and hold in high esteem. And recently talking to a data person explaining what a pita getting data out of their Mongo monstrosity into a format adequate for analysis.
We started our startup on Mongo. Hit some pretty hard performance problems and eventually did a multi month long migration to Postgres (Aurora on AWS).
MongoDB is only a valid choice if all you're doing is story key document pairs. The moment you need joins or any sort of aggregations like count/sum e.t.c - Mongo perf is horrendous. Postgres runs circles around Mongo in every way.
With jsonb columns, not much is lost. SQL is a huuuuge bonus. Mongo query language is a giant pain for everyone on team to learn and manage.
Much like saying “no offense” doesn’t make something not offensive, saying “honest question” doesn’t make a question not disingenuous. If you find yourself typing “don’t downvote” you should consider rephrasing your question to not be worthy of downvotes.
This post could just be “can you explain your experiences that have lead you to this conclusion” and we’d all be better off.
Are you basing this opinion on:
- popular HN opinion
- issues that Mongo experienced in its infancy
- mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems
Or are you basing it on extensive experience with wide range of use cases?