4 ms·

I have used Mongo for 9 years. First at a game company, then for several prototypes that made it to production in my current role. We have not lost data once. M

by htsh 6y ago

I have used Mongo for 9 years. First at a game company, then for several prototypes that made it to production in my current role. We have not lost data once. Many of my friends at medium-sized companies use Mongo for much larger projects and have not lost data a single time, either. And it is it not just me and my friends -- HSBC recently announced they are moving 65 of its relational databases to mongodb. I am not sure that is wise, but I think it furthers my view that data-loss is not a concern in many contexts. The data-loss thing was most certainly real, but has not been since wiredtiger if one manages it the right way or uses it as a service. I would not say that I would say that HN != reality, maybe !== reality :). Neither side of the debate is wholly right, and neither is wholly wrong. The reason I use it is that for many projects, all you need is a relatively fast JSON document store, and mongo is so developer-friendly such that speed-to-prototype is so much shorter than anything else I have used in 25 years of building database-backed applications. Rethink was the only product that I would have used in its place and I was extremely sad to see it go. I agree with the commenter elsewhere in the belief that it would have thrived had it survived. I was using it for my personal/learning projects and was ready to switch everywhere. We have stuck with Mongo in production for a few products, one relatively large, and I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. You need to prove, first, that the thing you are building is useful, and Mongo will let you get to that really fast. I believe what is happening here is that the happy folks are quiet, and the aggrieved folks' experiences are real but it likely was a bad fit for their particular situation. For the subset of situations where we use it, it has allowed my teams quickly in our experimental work. All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. -h

eternalban 6y ago
> All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. The very RAD reasons you note regarding Mongo also encourage Mongo Cancer (tm). What is Mongo Cancer you ask? It is the phenomena where Mongo use is manifest from API to home-grown "relational logic" in business tier. This simply doesn't happen with any other NoSQL DB afaik, but Mongo Cancer uniquely marches right up to the user's face in the API. > I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. I'll hold you to that "I think" and assume you have never actually done this. Because Mongo Cancer patients typically love the RAD aspect of grabing JSON hot off the http stack and shoving it in the "database", touching every API in the way. The last M.C. project I saw required effectively a rebuild to actually swap the misused Mongo. tldr; Mongo Cancer is very easy to catch but requires very expensive surgery to cure.
- htsh 6y ago
  No, we have migrated prototypes to redshift. You just need to keep your database logic in a separate layer, which is something one should do anyway. I say "I think" because I agree with you that most will not. If you implement mongo such that you will be stuck on mongo, then do not use it. You always want to have a layer that handles your database operations, with any database, but obviously you are safer in SQL-land as switching costs are lower. I do not think the "cancer" metaphor is valuable here. What you describe are bad ideas that I agree are bad ideas but really one has to know the tool they are using and what it is bad at. I think the thing you describe can happen but that is just poor planning more than anything. Why does the database have anything to do with the design of your API layer? That sounds bonkers. And I would not blame the underlying database tech. I would blame the implementer. But really, please consider that many of us have, or are as we speak, losing loved ones to a deadly sickness which you have compared to a poor database implementation.
  - eternalban 6y ago
    But the technology encourages this type of behavior. And I am not speaking of hypothetical "can happen". I very recently had to deal with this precise issue. > But really, please consider that many of us have, or are as we speak, losing loved ones to a deadly sickness which you have compared to a poor database implementation. Sorry for your loss. Use of the word for non-medical concerns is common. Mongo Metastasis works too. Again disagree regarding "poor database implementation". Trivializing the "database implementation" is precisely Mongo's value proposition and the very reason they got their market share.
    - htsh 6y ago
      I agree that it is very easy to make bad decisions with this product, but I do not think it is unique to Mongo. And it is the role of a good architect or a good team lead to make sure that this does not happen or that developers do not go down these roads. I would even say the strengths that I have pointed out are precisely what makes it easier to take shortcuts. It gets out of your way, makes collections if they do not exist, allows for different document types in the same collections. It has no guard rails whatsoever. I think we are in agreement -- one needs to be very careful using this. You can use it and put yourself in a spot where you have to throw out your entire codebase. Well, me saying "can happen" does not mean it does not happen or that people have not seen it. It is saying the opposite. My point is it does not have to or that it does not always happen. Developers take shortcuts, often because they do not know better, and you are right that some products make it easier to go down these roads. I still do not think you want to use medical diseases as metaphors. You would not say "mongo aids" or "mongo alzheimers" or "mongo diabetes." Even if it is common, it is not particularly useful. Metastasis is better.
nicoburns 6y ago
Genuine question: What does mongo give you as a JSON store that postgres's JSONB doesn't?
- htsh 6y ago
  Querying is in pure JS, easy to do stuff programmatically. But if starting new, with a team that did not know Mongo well already, not a real advantage. I still prefer querying something nested in mongo to querying something nested in JSONB, but I can work with either. And back when I started with it, JSONb did not exist. I would say JSONB was also a godsend though as our roadmaps now have a clear path to something we may prefer later. People up the chain are often terrified when they hear the word "mongo" so the existence of JSONB makes it easier to swap out your layer that handles database interactions. But the speed advantage really lies in the early-stage prototype development. If I have to do it in postgres, the amount of code necessary up front, when inevitable schema changes happen, etc. makes mongo preferable until things settle down. But again, it all depends on how well you know the thing up front. If you can anticipate a lot of iteration on the data model as you learn how people use your product, mongo is handy early. If I am given a spec for something where all of the things are known and foreseen, I am going with postgresql. I assume that the hardest thing to do is making something people want to use. If I can achieve that with whatever I use, I have some good (and fun) problems on my hands. And it is all about structuring the work so that I am not tied to any database product. I am no longer working on startups with little-to-no funding, so right now I assume AWS or Azure will manage a database better than I can. And I assume new things are always coming.
  - hnedeotes 6y ago
    I can't follow this through, I'm interested in nosql databases because there are indeed patterns of access where a db as a key value store is helpful. > Querying is in pure JS, easy to do stuff programmatically. You mean you do your logic at the application layer? Like if you need X objects and Y objects where Y have an identifier to the X objects they're related to you build them in JS after retrieving them? What is the difference from getting a json object and doing the "querying" in pure js? And isn't it easier "programatically" to just join the data at the source? > But the speed advantage really lies in the early-stage prototype development. If I have to do it in postgres, the amount of code necessary up front, when inevitable schema changes happen, etc. makes mongo preferable until things settle down. But again, what is the difference of having a record with a column with json, that you just do rodeo dump? (I think pg even allows you to do all sorts of indexing on inner fields of json if I'm not mistaken?)

by htsh 6y ago

eternalban 6y ago

> All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. The very RAD reasons you note regarding Mongo also encourage Mongo Cancer (tm). What is Mongo Cancer you ask? It is the phenomena where Mongo use is manifest from API to home-grown "relational logic" in business tier. This simply doesn't happen with any other NoSQL DB afaik, but Mongo Cancer uniquely marches right up to the user's face in the API. > I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. I'll hold you to that "I think" and assume you have never actually done this. Because Mongo Cancer patients typically love the RAD aspect of grabing JSON hot off the http stack and shoving it in the "database", touching every API in the way. The last M.C. project I saw required effectively a rebuild to actually swap the misused Mongo. tldr; Mongo Cancer is very easy to catch but requires very expensive surgery to cure.

htsh 6y ago
No, we have migrated prototypes to redshift. You just need to keep your database logic in a separate layer, which is something one should do anyway. I say "I think" because I agree with you that most will not. If you implement mongo such that you will be stuck on mongo, then do not use it. You always want to have a layer that handles your database operations, with any database, but obviously you are safer in SQL-land as switching costs are lower. I do not think the "cancer" metaphor is valuable here. What you describe are bad ideas that I agree are bad ideas but really one has to know the tool they are using and what it is bad at. I think the thing you describe can happen but that is just poor planning more than anything. Why does the database have anything to do with the design of your API layer? That sounds bonkers. And I would not blame the underlying database tech. I would blame the implementer. But really, please consider that many of us have, or are as we speak, losing loved ones to a deadly sickness which you have compared to a poor database implementation.
- eternalban 6y ago
  But the technology encourages this type of behavior. And I am not speaking of hypothetical "can happen". I very recently had to deal with this precise issue. > But really, please consider that many of us have, or are as we speak, losing loved ones to a deadly sickness which you have compared to a poor database implementation. Sorry for your loss. Use of the word for non-medical concerns is common. Mongo Metastasis works too. Again disagree regarding "poor database implementation". Trivializing the "database implementation" is precisely Mongo's value proposition and the very reason they got their market share.
  - htsh 6y ago
    I agree that it is very easy to make bad decisions with this product, but I do not think it is unique to Mongo. And it is the role of a good architect or a good team lead to make sure that this does not happen or that developers do not go down these roads. I would even say the strengths that I have pointed out are precisely what makes it easier to take shortcuts. It gets out of your way, makes collections if they do not exist, allows for different document types in the same collections. It has no guard rails whatsoever. I think we are in agreement -- one needs to be very careful using this. You can use it and put yourself in a spot where you have to throw out your entire codebase. Well, me saying "can happen" does not mean it does not happen or that people have not seen it. It is saying the opposite. My point is it does not have to or that it does not always happen. Developers take shortcuts, often because they do not know better, and you are right that some products make it easier to go down these roads. I still do not think you want to use medical diseases as metaphors. You would not say "mongo aids" or "mongo alzheimers" or "mongo diabetes." Even if it is common, it is not particularly useful. Metastasis is better.

nicoburns 6y ago

Genuine question: What does mongo give you as a JSON store that postgres's JSONB doesn't?

htsh 6y ago
Querying is in pure JS, easy to do stuff programmatically. But if starting new, with a team that did not know Mongo well already, not a real advantage. I still prefer querying something nested in mongo to querying something nested in JSONB, but I can work with either. And back when I started with it, JSONb did not exist. I would say JSONB was also a godsend though as our roadmaps now have a clear path to something we may prefer later. People up the chain are often terrified when they hear the word "mongo" so the existence of JSONB makes it easier to swap out your layer that handles database interactions. But the speed advantage really lies in the early-stage prototype development. If I have to do it in postgres, the amount of code necessary up front, when inevitable schema changes happen, etc. makes mongo preferable until things settle down. But again, it all depends on how well you know the thing up front. If you can anticipate a lot of iteration on the data model as you learn how people use your product, mongo is handy early. If I am given a spec for something where all of the things are known and foreseen, I am going with postgresql. I assume that the hardest thing to do is making something people want to use. If I can achieve that with whatever I use, I have some good (and fun) problems on my hands. And it is all about structuring the work so that I am not tied to any database product. I am no longer working on startups with little-to-no funding, so right now I assume AWS or Azure will manage a database better than I can. And I assume new things are always coming.
- hnedeotes 6y ago
  I can't follow this through, I'm interested in nosql databases because there are indeed patterns of access where a db as a key value store is helpful. > Querying is in pure JS, easy to do stuff programmatically. You mean you do your logic at the application layer? Like if you need X objects and Y objects where Y have an identifier to the X objects they're related to you build them in JS after retrieving them? What is the difference from getting a json object and doing the "querying" in pure js? And isn't it easier "programatically" to just join the data at the source? > But the speed advantage really lies in the early-stage prototype development. If I have to do it in postgres, the amount of code necessary up front, when inevitable schema changes happen, etc. makes mongo preferable until things settle down. But again, what is the difference of having a record with a column with json, that you just do rodeo dump? (I think pg even allows you to do all sorts of indexing on inner fields of json if I'm not mistaken?)