3 ms·

Can some people who have used Mongo in production elaborate on their experiences where Mongo worked well or didn't work well? I see a lot of more hate than I do

Can some people who have used Mongo in production elaborate on their experiences where Mongo worked well or didn't work well? I see a lot of more hate than I do love for Mongo on HN and I'm curious why.

disbelief 12y ago
I've used Mongo in two large projects and have mixed feelings about it. Pros: It's great for building your MVP. Super easy to get up and running, super easy to work with at a superficial level (I'm talking about storing data and querying here more than ops and administration), dataset can grow to a fairly large size without you having to think about your database at all, freeing you to think about your business. Mongo was my first brush with "schemaless" and that's a big advantage particularly for early-stage projects where things are in flux. I also enjoy using JS as the query language, because I like JS, but YMMV. Also for certain use cases, particularly the single document case, it's probably one of the best solutions available. However, in my experience, this ends up being a limitation if your data doesn't fit nicely into a single document, and the types of data that do fit this use case are rare. The cons you've probably heard before: no transactions, no joins, not ACID compliant, until very recently writes locked the entire database, scaling/sharding just works until it doesn't.
tim333 12y ago
Haven't used it but you may find https://news.ycombinator.com/item?id=6712703 https://news.ycombinator.com/item?id=6712703 of interest
weddpros 12y ago
I find Mongodb works well (OLTP) when you use it as a powerful Key-Value store with secondary indices. You'll get easy replication/failover (rolling updates of the DB server are easy), ease of use (with node.js for example) and very decent performance... Good for an application where you need frequent access to a "row" except that row is complex, with subobjects, sets and arrays (in this use case, a relational model performs much worse because of joins) Not so good for an application where you need frequent access to lists of tabular data and list/details access (where relational models shine) Your mileage may vary. Some use it for logging, for analytics, for which I have no need or experience. GridFS also works very well (but I use nginx as a cache in front of it).

disbelief 12y ago

I've used Mongo in two large projects and have mixed feelings about it. Pros: It's great for building your MVP. Super easy to get up and running, super easy to work with at a superficial level (I'm talking about storing data and querying here more than ops and administration), dataset can grow to a fairly large size without you having to think about your database at all, freeing you to think about your business. Mongo was my first brush with "schemaless" and that's a big advantage particularly for early-stage projects where things are in flux. I also enjoy using JS as the query language, because I like JS, but YMMV. Also for certain use cases, particularly the single document case, it's probably one of the best solutions available. However, in my experience, this ends up being a limitation if your data doesn't fit nicely into a single document, and the types of data that do fit this use case are rare. The cons you've probably heard before: no transactions, no joins, not ACID compliant, until very recently writes locked the entire database, scaling/sharding just works until it doesn't.

tim333 12y ago

Haven't used it but you may find https://news.ycombinator.com/item?id=6712703 https://news.ycombinator.com/item?id=6712703 of interest

weddpros 12y ago

I find Mongodb works well (OLTP) when you use it as a powerful Key-Value store with secondary indices. You'll get easy replication/failover (rolling updates of the DB server are easy), ease of use (with node.js for example) and very decent performance... Good for an application where you need frequent access to a "row" except that row is complex, with subobjects, sets and arrays (in this use case, a relational model performs much worse because of joins) Not so good for an application where you need frequent access to lists of tabular data and list/details access (where relational models shine) Your mileage may vary. Some use it for logging, for analytics, for which I have no need or experience. GridFS also works very well (but I use nginx as a cache in front of it).