3 ms·

I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not

I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not depend upon bashing of any X DB on the internet. I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB" Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for. Following are the things most people miss: 1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API. 2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2. 3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it. 4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data. 5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?

deleted 7y ago
[deleted]
octohedron 7y ago
As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said. Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet. People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases. Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time. Also it's what's taught in courses as superior to non relational databases. I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.

deleted 7y ago

[deleted]

octohedron 7y ago

As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said. Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet. People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases. Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time. Also it's what's taught in courses as superior to non relational databases. I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.