4 ms·

Just to counterbalance the amount of negative sentiment here, we've used MongoDB for Artsy.net, following a recommendation from Foursquare's CTO (and others) si

by dblock 9y ago

Just to counterbalance the amount of negative sentiment here, we've used MongoDB for Artsy.net, following a recommendation from Foursquare's CTO (and others) since 2010. Elliott has also been very generous with his time, too. MongoDB enabled us to iterate fast and continues to serve well.

nemild 9y ago
Thanks for sharing. It'd be really helpful for others to understand the use cases that made MongoDB a good choice for you in 2010. Part of what I've felt is missing in the debate is where early MongoDB versions were a good choice, and where they were a poor choice. For example, I've seen it used in a number of places where transactions are really important (a number of fintech companies) - and I'll assume this was not a need for your team? And as I've stressed in this series, my goal is not to argue that MongoDB is a poor choice, especially as it has matured. Rather, it is to argue that we have to pick the right tool for the job - and can't blindly follow hype or marketing.
infecto 9y ago
I would love to know what mongodb offered you above MySQL/Postgres? I always hear you can iterate fast but for most usecases I cannot see how mongodb is quicker to iterate than a relational database. Would love to learn though.
- revmoo 9y ago
  > for most usecases I cannot see how mongodb is quicker to iterate than a relational database Neither can I. What part of RDBMS make it hard to iterate exactly?
- bjt 9y ago
  I can't speak for the parent, but there was a time around 2011 when I was pretty excited that MongoDB would let me just start coding without needing to 1) configure postgres's listening port and pg_hba.conf to allow easy local access, and 2) churn through a dozen or so revisions to the schema without having to set up a system for running migration scripts. I really think a lot of Mongo's success came from that "It just works" experience the first time people tried it. I later came to see it as a bad tradeoff. Open, unauthenticated access by default created more costs in security than it saved in early prototyping. Automating the creation of my dev environment made it not such a big deal to make Postgres configured right when it booted. And once I'd gotten a SQL migration system that I liked, I just kept re-using it. These things took some time for me to develop and learn, though.
  - gaius 9y ago
    onfigure postgres's listening port and pg_hba.conf to allow easy local access That is literally 30 seconds work!
    - bjt 9y ago
      Only with the benefit of hindsight, which isn't helpful to the newcomer. To someone new who is just trying to work through some web framework tutorial or hack out a half-formed proof of concept, it can be several minutes (or much longer) of trying, failing, copying error messages into Google, and following some guide written for Debian but failing to get it working because you're running Red Hat (or vice versa). When you stack up enough similar problems getting the rest of the stack to work (e.g. configuring Apache or nginx), it stops a lot of new people in their tracks. When they're given something that just works, it's a godsend.
      - 52-6F-62 9y ago
        As someone who has worked largely with MySQL until a recent project that is internal to the media enterprise I work for, MongoDB was a godsend in rapidly developing an app that was formerly using MySQL. I faced an extremely tight deadline to rewrite it in order to be ready for a production period for a national publication and it just worked for the purpose of the app. It otherwise required a lot of state handling of JSON objects on the front end that required a lot of parsing to be compatible with the tables and repairing and rewriting large swaths of that code can still happen, but could not in time for the deadlines. I was able to pull the whole works together from the ground up (with improved UX) because of the document model. In this case documents are quite the thing being passed around and managed in the application, though. In the long term, if the app is implemented into larger projects underway, then I would probably set up some sort of persistent store -- but until then it's been eye-openingly great. For suitable projects, I agree fully. And for smaller applications, or tentative solutions (that are required in some environments) it's a more efficient option.
      - Karrot_Kream 9y ago
        How is someone like that qualified to work as a software engineer? These were things I did when I was 13 on our old family Pentium, not something I would want a production engineer to do.

by dblock 9y ago

nemild 9y ago

Thanks for sharing. It'd be really helpful for others to understand the use cases that made MongoDB a good choice for you in 2010. Part of what I've felt is missing in the debate is where early MongoDB versions were a good choice, and where they were a poor choice. For example, I've seen it used in a number of places where transactions are really important (a number of fintech companies) - and I'll assume this was not a need for your team? And as I've stressed in this series, my goal is not to argue that MongoDB is a poor choice, especially as it has matured. Rather, it is to argue that we have to pick the right tool for the job - and can't blindly follow hype or marketing.

infecto 9y ago

I would love to know what mongodb offered you above MySQL/Postgres? I always hear you can iterate fast but for most usecases I cannot see how mongodb is quicker to iterate than a relational database. Would love to learn though.

revmoo 9y ago
> for most usecases I cannot see how mongodb is quicker to iterate than a relational database Neither can I. What part of RDBMS make it hard to iterate exactly?
bjt 9y ago
I can't speak for the parent, but there was a time around 2011 when I was pretty excited that MongoDB would let me just start coding without needing to 1) configure postgres's listening port and pg_hba.conf to allow easy local access, and 2) churn through a dozen or so revisions to the schema without having to set up a system for running migration scripts. I really think a lot of Mongo's success came from that "It just works" experience the first time people tried it. I later came to see it as a bad tradeoff. Open, unauthenticated access by default created more costs in security than it saved in early prototyping. Automating the creation of my dev environment made it not such a big deal to make Postgres configured right when it booted. And once I'd gotten a SQL migration system that I liked, I just kept re-using it. These things took some time for me to develop and learn, though.
- gaius 9y ago
  onfigure postgres's listening port and pg_hba.conf to allow easy local access That is literally 30 seconds work!
  - bjt 9y ago
    Only with the benefit of hindsight, which isn't helpful to the newcomer. To someone new who is just trying to work through some web framework tutorial or hack out a half-formed proof of concept, it can be several minutes (or much longer) of trying, failing, copying error messages into Google, and following some guide written for Debian but failing to get it working because you're running Red Hat (or vice versa). When you stack up enough similar problems getting the rest of the stack to work (e.g. configuring Apache or nginx), it stops a lot of new people in their tracks. When they're given something that just works, it's a godsend.
    - 52-6F-62 9y ago
      As someone who has worked largely with MySQL until a recent project that is internal to the media enterprise I work for, MongoDB was a godsend in rapidly developing an app that was formerly using MySQL. I faced an extremely tight deadline to rewrite it in order to be ready for a production period for a national publication and it just worked for the purpose of the app. It otherwise required a lot of state handling of JSON objects on the front end that required a lot of parsing to be compatible with the tables and repairing and rewriting large swaths of that code can still happen, but could not in time for the deadlines. I was able to pull the whole works together from the ground up (with improved UX) because of the document model. In this case documents are quite the thing being passed around and managed in the application, though. In the long term, if the app is implemented into larger projects underway, then I would probably set up some sort of persistent store -- but until then it's been eye-openingly great. For suitable projects, I agree fully. And for smaller applications, or tentative solutions (that are required in some environments) it's a more efficient option.
    - Karrot_Kream 9y ago
      How is someone like that qualified to work as a software engineer? These were things I did when I was 13 on our old family Pentium, not something I would want a production engineer to do.