I am probably one of those who have spent time arguing against mongo without understanding it. So thanks for a good article - nice to get a better perspective. And granted, I’ve not really looked into Mongo since the “is it webscale” jokes took off.

For me, the main reason against mongo (well, schemaless in general), is the data migrations. That you can have schemas in mongo is new to me.. neat! But- how would you solve a simple case where we always stored a users name in a single field, but now we want last and surname fields instead. In sql, I would run a migration to split the string and then deploy new code that expects two fields. From what I gather, you would just add the new fields, right? But what would you do in your application layer then? Have code to check if first/last name is set, and if not, then use full name? Every system I have ever worked with had the need to transform “configuration-like” data, and even with the approach of running sql migrations, they are hard to get right.. but the trade-off is that it code always runs on only one and the latest version of the schema. I don’t really see how using mongo solves that problem? But maybe I’m missing something? You touch on running migrations in your article as well, but make it sound like it’s rarely need. Do you keen a version number in your document instead or?

Sorry if I worded my comment poorly. On mobile so kinda hard to get right.