7 ms·
I never used/tried MongoDB, what are the reasons people choose MongoDB over other DBs?
by goenning 3y ago
I never used/tried MongoDB, what are the reasons people choose MongoDB over other DBs?
- webappguy 3y agoEasy, flexible scheme nosql, plenty of baked in features. Has it's place, and many times when it would not be a good choice too.
- salil999 3y agoIt's pretty easy to start with. MQL is also pretty easy to understand + MongoDB kinda makes it fun. Note: I work at MongoDB
- 010101010101 3y agoIt was an early player when everyone thought NoSQL document databases solved every problem.
- jtriangle 3y agoThey did solve many problems, and then they caused many more problems... At first at least, haven't checked in on that in awhile
- throwawaaarrgh 3y agoAnd now everyone knows RDBMS solves every problem. Especially when it's SQLite.
- sgift 3y ago[flagged]
- sigzero 3y agoSo nothing has changed in the 3 years since that article?
- chx 3y agoI am not sure what's going on with Jepsen any more. https://jepsen.io/analyses https://jepsen.io/analyses there were zero done in 2021, two in early 2022 and even the footer copyright say 2022.
- sgift 3y agoaphyr seems to still work on it, so probably just not that many companies who want to pay to get told the truth anymore: https://github.com/jepsen-io/jepsen https://github.com/jepsen-io/jepsen
- salil999 3y agoI see this Jepsen link posted all the time. People: PLEASE don't use outdated software. MongoDB has made mistakes and they are public about their data issues on https://www.mongodb.com/alerts https://www.mongodb.com/alerts. MongoDB 4.2.6 is old and I believe it's approaching EoL based on https://www.mongodb.com/support-policy/lifecycles https://www.mongodb.com/support-policy/lifecycles I'm not going to push for you to use MongoDB but am merely trying to provide some context around that Jepsen analysis.
- lolinder 3y agoBased on that lifecycle doc, the 4.2 line is already EOL, and 4.4 will be soon.
- sgift 3y agoThat's why I've added the last part. Mongodb highlights old Jepsen analysis' on their page (https://www.mongodb.com/jepsen https://www.mongodb.com/jepsen), but they never got around to ask them for another analysis to show things are so much better with MongoDB 5 or 6? Yeah. Sure. People are free to believe whatever they want, I'll continue to highlight the best info available.
- Jonovono 3y agoIt's a really great alternative to firebase for mobile apps. Works pretty nicely with Realm so you get offline first db with powerful syncing. All the benefits of realm on the edge device with the power of the mongo platform. I dismissed mongo atlas for years because "mongo", until I finally gave it a chance. Overall been pretty pleased.
- kagevf 3y ago> It's a really great alternative to firebase for mobile apps. Isn't firebase built on top of mongoDb?
- endisneigh 3y agoNo
- tgv 3y agoI use it on-prem (well, on a VPS). It stores JSON documents, and it's easy to work with. If your data looks like a tree, it works pretty well, also for large documents. If you depend on relations between documents, you're better off with an SQL database, but note that for many cases --I'd say practically all mundane cases-- there's really no need for relations the SQL way. MongoDB also does relations, but a bit more convoluted.
- cpursley 3y agoPostgres does all that plus 100x.
- winrid 3y agoBut the horizontal scaling is easier with Mongo than Citus.
- yawaramin 3y agoBut you don't need to horizontally scale if you use a beefy Postgres instance. Horizontal scaling is a problem created by using an inefficient DB in the first place.
- winrid 3y agoI have DB clusters with masters with a terrabyte of ram. Going beyond that is a PITA with warming up cache, backups, and so on. There is a reason there's a huge industry for shared databases. Also, query for query, Mongo isn't going to be that much slower than PG, and faster for some usage patterns...
- winrid 3y ago*sharded
- tgv 3y agoI've also tried SQLite, but they didn't do large documents that well. And the project was started before I was aware Postgresql had json support. But what's the advantage of Postgresql in this case?
- bossyTeacher 3y agoMongo is the main nosql choice. Mongo is great if you think a flexible schema is good. Mongo is not great if you think a flexible schema is bad. That sums it up
- iLoveOncall 3y agoThis is too reductive, you can essentially have flexible schemas with most modern relational databases and without the downsides of document-based DBs. In 99% of the cases, even if you need a flexible schema, PostgreSQL will remain the best choice.
- insanitybit 3y agoEnterprise support, lots of documentation, does what it says it does.
- deleted 3y ago[deleted]
- rglover 3y ago- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. - Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries. - Little to no concern over injection attacks (you have to go out of your way to create potential for them). - Easier to write non-trivial queries than with SQL (IMO). - Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp. - A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it). - Scales reasonably well (and easily) for a majority of use cases. - No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.
- djrobstep 3y ago> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.
- winrid 3y agoIt could be rephrased as "worry about them later" :P gotta get those returns on the VC money and pawn those issues onto the next team in 7yrs :)
- rglover 3y agoNot necessarily. If you're utterly careless, sure. A MongoDB migration is far less of a headache than a SQL one (you're just writing code to map/replace values). With SQL, you have to be frustratingly surgical about everything which can slow momentum to a crawl (read: punishment for mistakes in the migration is far worse than with MongoDB in my experience).
- DandyDev 3y agoWe use MongoDB in conjunction with RealmDB to build an offline first mobile app. For this specifically it works very well. You basically define which parts of your document collection should be synced to which device, for example based on a query that contains the user id. MongoDB takes care of syncing the right data to the right device when internet connection is available. On the device, the data is stored locally in RealmDB, which represents the other side of the sync. This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.