| I manage a team that's responsible for the Mongo DB that powers essentially the whole business. This is a 10 year old company that started right about when Mongo was trendy. After 10 years it's a nightmare to understand what's going on in that database. And it's now extremely difficult to get off of it precisely because it doesn't have the schema and referential integrity and constraints that we need to be able to understand our data well enough to actually do the migration. We really want to switch to an RDBMS, but it's going to be risky and difficult. You could say this is all bad engineering, and I guess that's true in a reductive sense. But it's like arguing that you don't need to climb with a safety rope because good climbers don't fall. Over 10 years and many engineers "bad" engineering happens. I also believe that reasoning about data is hard, and you should therefore try to avoid doing it. You should do that hard thinking one time, and then rely on your database to enforce the rules until they need changing. Aka: Don't Make Me Think (About This Constantly). If I believed in conspiracy theories I'd say that Mongo was one of the best vendor lock-in plays in tech. Mongo Corp is going to be profitable for a while because once you're down the Mongo rabbit hole it's a real pain to climb back out. But they'll host your database at least, so you don't also have to deal with that. I will give them credit for having a nice management UI. But from my experience of the past few years I would never choose Mongo. For documents, Elasticsearch, or Postgres if you don't have too many. For relational data, a relational DB. And Mongo's slow, too. |