3 ms·
Mongo is also proving the success of vendor lock-in: you (or the engineers before you, and the engineers before them) make a mess in Mongo, because there are no
by vosper 6y ago
Mongo is also proving the success of vendor lock-in: you (or the engineers before you, and the engineers before them) make a mess in Mongo, because there are no relations and no schemas [0], and it becomes really difficult to get off it.
The effort required just to get your data in a state that's clean enough to consider moving to the RDBMS you should have started with can be overwhelming.
Then you have to rewrite your queries out of their custom query language.
Is it Mongo's fault you made a mess in your database? No, of course not. And their dashboard is actually pretty nice. But you are massively locked-in.
Source: own a production Mongo DB with years of accumulated mess in it. Desperate to get off it. Paying customer of Mongo's hosting (it's one less Mongo thing to deal with, at least).
[0] There is schema support now, but it's only JSON schema and it's relatively new in the scheme [sorry] of things
- breakfastduck 6y agoAgreed. MongoDB makes it far too easy to make terrible decisions in regard to data design.
- bonestormii_ 6y agoThis isn't really vendor lock-in, though. It's simply a technical/design lock-in. Going from unstructured to structured data presents problems, and if you do that, it's rightfully up to you to fix. It is different from the vendor lock-in that prevents one from migrating from AWS to Google Cloud because all of your code uses their APIs and libraries specifically. However, the effect is the same, of course. You are locked in! It's not necessarily a bad thing, but this is why you must choose your poison carefully.
- vosper 6y ago> This isn't really vendor lock-in, though. It's simply a technical/design lock-in. Going from unstructured to structured data presents problems, and if you do that, it's rightfully up to you to fix. This is true, but it's also kind of vendor lock-in because there's a whole query language and aggregation pipeline for Mongo that's completely different to other databases. If I was using an RDBMS and was switching from MySQL to Postgres I think I would likely have a much easier time, because fundamentally it's all SQL (I know, there are differences between Postgres and MySQL, but it's a lot less, and a good ORM will smooth some of it out for you - at least initially) I think this is basically equivalent to your example of not being able to easily move from AWS to Google Cloud because of their different APIs. It doesn't seem like SQL-to-Mongo is impossible to implement, because there is third-party tooling for that (which I haven't tried): https://studio3t.com/knowledge-base/articles/sql-query/ https://studio3t.com/knowledge-base/articles/sql-query/
- bonestormii_ 6y agoYeah you are right. There is no standardization to the way you interact with such things.
- FpUser 6y agoI very much prefer to use RDBMS first and the rest as the last resort. Still I do not believe that quality of data design could be enforced just by the fact of using RDBMS. I sometimes encountered RDBMS schemas that look like they were designed by lunatics.
- zozbot234 6y agoPostgresql supports JSON-in-db out of the box, so I'm not sure that there's any real lockin wrt. Mongo. It's just that those who care about not being tied to a single vendor are less likely to use something like Mongo in the first place.
- nradov 6y agoRDBMS doesn't work for some of the complex hierarchical data I have to deal with. Shredding it out into a 3NF relational schema would require joining 20+ tables in every query to do anything useful. No thanks. Use the right database type for the job.
- joshspankit 6y agoGenuinely curious: Have you looked at moving to a graph database? I can’t conceptualize a dataset that could survive(/be performant) in a document store, but not a graph.