Part of what I've felt is missing in the debate is where early MongoDB versions were a good choice, and where they were a poor choice. For example, I've seen it used in a number of places where transactions are really important (a number of fintech companies) - and I'll assume this was not a need for your team?
And as I've stressed in this series, my goal is not to argue that MongoDB is a poor choice, especially as it has matured. Rather, it is to argue that we have to pick the right tool for the job - and can't blindly follow hype or marketing.
I always hear you can iterate fast but for most usecases I cannot see how mongodb is quicker to iterate than a relational database. Would love to learn though.
I really think a lot of Mongo's success came from that "It just works" experience the first time people tried it.
I later came to see it as a bad tradeoff. Open, unauthenticated access by default created more costs in security than it saved in early prototyping. Automating the creation of my dev environment made it not such a big deal to make Postgres configured right when it booted. And once I'd gotten a SQL migration system that I liked, I just kept re-using it. These things took some time for me to develop and learn, though.
That is literally 30 seconds work!
To someone new who is just trying to work through some web framework tutorial or hack out a half-formed proof of concept, it can be several minutes (or much longer) of trying, failing, copying error messages into Google, and following some guide written for Debian but failing to get it working because you're running Red Hat (or vice versa). When you stack up enough similar problems getting the rest of the stack to work (e.g. configuring Apache or nginx), it stops a lot of new people in their tracks. When they're given something that just works, it's a godsend.
It otherwise required a lot of state handling of JSON objects on the front end that required a lot of parsing to be compatible with the tables and repairing and rewriting large swaths of that code can still happen, but could not in time for the deadlines.
I was able to pull the whole works together from the ground up (with improved UX) because of the document model. In this case documents are quite the thing being passed around and managed in the application, though.
In the long term, if the app is implemented into larger projects underway, then I would probably set up some sort of persistent store -- but until then it's been eye-openingly great.
For suitable projects, I agree fully. And for smaller applications, or tentative solutions (that are required in some environments) it's a more efficient option.
If software engineering was like civil engineering then using MongoDB would be like building a bridge out of noodles.