7 ms·
They seem to be indeed going strong. I don't really see a viable alternative to MongoDB (document db). Fits well in a lot of use cases. Edit: we (Syncari) use M
by neeleshs 4y ago
They seem to be indeed going strong. I don't really see a viable alternative to MongoDB (document db). Fits well in a lot of use cases.
Edit: we (Syncari) use MongoDB, we are not a very large customer but have a cluster that handles billions of documents
- bigDinosaur 4y agoNo viable alternative? Why not one of the many other document db's, such as CouchDB? Genuinely curious what MongoDB does better in general than all the other document oriented databases.
- bombcar 4y agoBecause MongoDB is web scale. (Honest answer: a company can continue way longer than you think just supporting legacy customers - need Lotus Notes? https://www.hcltechsw.com/notes https://www.hcltechsw.com/notes )
- PheonixPharts 4y ago> what MongoDB does better Hosting and infrastructure? Sure for your weekend project there are plenty of alternatives. At enterprise level you aren't paying for just the base product you're paying to have someone else worry about all the other stuff that keeps it up and running. Yes you can find Couchdb hosting services but it's very nice to have the company that builds the product also control the hosting. I've worked at a company that was fairly large MongoDB customers. Even though MongoDB was a major part of our overall product there was never a second of considering hosting our own solution, and there was likewise never a time I remember Mongo being responsible for a major outage or other infrastructure issue. That's worth quite a lot of money to not have to worry about an essential part of your own internal product infra.
- bigDinosaur 4y agoI see, so it's more the managed infrastructure than the actual DB itself?
- asadawadia 4y ago>Fits well in a lot of use cases. Can you share the use cases? Why Mongo works better than Postgres?
- NomDePlum 4y agoMongo (similar for other NoSql propositions) is most suitable for specific data access patterns. The most obvious one being where you are requesting data and related data based upon a unique business identifier. NoSql DBs mostly make this both trivial and fast. Postgres and other SQL options become relevant where aggregation and reporting become primary considerations.
- hardwaresofton 4y agoJust to explain a little bit why the notion you're pointing to is incorrect -- identity and referential integrity fundamental concepts in the "SQL options" i.e. relational database management systems (RDBMS), based on the relational model[0], rooted in relational algebra[1]. NoSQL Databases arose from a realization that sometimes you don't need all the features of a relational database, for example: - Redis which at the most basic level is a key value cache - MongoDB which stores (denormalized) documents NoSQL Databases like MongoDB are best when: - All data related to a certain entity can be reasonably self contained (i.e. does not require relating to other possibly dynamic pieces of data) - referential integrity (knowing that User.storeId can be treated as just a string) does not need to be maintained - Constraint checking does not need to be performed or can be performed at the application level - Schemas are either wildly variable or do not change at all, or checking them just isn't important. The best example I hear often is a news site or blog -- if your main model is something like an Article that contains the author, content, tags and all data necessary to display one entry (and 99% of the time you get one Article and are not required to request related data that exist in separate collections), then NoSQL makes sense. It's a tired conversation I think people have had repeatedly for a long time, so I won't go into it again (I'm also VERY biased towards RDBMS and in particular Postgres) -- would love to hear from experienced MongoDB proponents though! One case I know Mongo was trusted for very early on was large scale out use cases, and after WiredTiger their execution engine improved immensely as well. I assume it's still great for that, where scale out is often quite lacking in RDBMS or not in the core experience. [0]: https://en.wikipedia.org/wiki/Relational_database#Relational_model https://en.wikipedia.org/wiki/Relational_database#Relational... [1]: https://en.wikipedia.org/wiki/Relational_algebra https://en.wikipedia.org/wiki/Relational_algebra