3 ms·

(Author here) You can read parts 1 and 2 of the three part series: - Part 1, Why Did So Many Startups Choose MongoDB: https://www.nemil.com/mongo/1.html https:

by nemild 9y ago

(Author here) You can read parts 1 and 2 of the three part series: - Part 1, Why Did So Many Startups Choose MongoDB: https://www.nemil.com/mongo/1.html https://www.nemil.com/mongo/1.html - Part 2, Startup Engineers and Our Mistakes with MongoDB: https://www.nemil.com/mongo/2.html https://www.nemil.com/mongo/2.html You can see most of the notes from my interview with MongoDB's CTO, Eliot here: https://news.ycombinator.com/item?id=14804765 https://news.ycombinator.com/item?id=14804765 And the interview notes related to MongoDB's marketing are somewhere in this HN post: https://news.ycombinator.com/item?id=15124316 https://news.ycombinator.com/item?id=15124316

primitivesuave 9y ago
I really enjoy your writing style and how you wrote about the "story of humans" rather than writing YAMTT (Yet Another MongoDB Trash Talk). I'm actually a lot more comfortable now using MongoDB in production after understanding its level of maturity and what the right application is. For the last couple years I was scared off by all the negative HN comments on MongoDB articles.
- nemild 9y ago
  Thanks for the kind words. Most thoughtful engineers I've met are believers in right tool for the job and thinking in tradeoffs, not good and bad - and so I'm a big fan about digging into MongoDB's value and understanding your projects' needs. MongoDB has matured as well over the last decade, and it's a testament to the hard work of their engineering team. You may like this old post that I wrote which echoes the broader points I make in this series about thoughtfully making eng choices and having better eng debates: https://www.nemil.com/musings/betterdebates.html https://www.nemil.com/musings/betterdebates.html
- bulldoa 9y ago
  so what is the right application for mongodb? only when you don't need ACID? Can you give some example? Genuinely curious
  - mandevil 9y ago
    We used Couchbase (a NoSQL like MongoDB) for email batch sending (think invitations to a party) and it worked very well. We could store each email sent as a separate, denormalized document so the sender could see EXACTLY how their contact data was replaced in each individual instance, the "View as a Web Page" functionality was trivial (instead of recalculating everything from the normalized forms- which can be blown up by contact data changes, just load the document that you sent out), and it's lovely TTL feature meant we could handle the configurable retention policies trivially as well. It wasn't so good at doing reports (how many customers viewed the email yet, responded, etc.). One thing we talked about doing was just storing a sqlite or h2 database as a document for reporting purposes (if we had been more single threaded that could have worked nicely). We ended up using a separate Sql DB for that. There are cases where denormalized data is the "right" way to view stuff, and cases where the data really is easier if its normalized, and that is a good reason to push your DB selection one way or another.
    - lilbobbytables 9y ago
      Interesting. Seems like that would just be one part of a larger application, though. And for that, my mind just jumps to something like Postgres with `jsonb` fields to store it all denormalized, then using columns to store relations, like the contact it was sent to. Along with other tables for other parts of the application, of course. This way your aren't complicating your stack by adding more services sooner.
      - mandevil 9y ago
        We were replacing a fully SQL email engine (that was starting to fall over due to load) with this more hybrid approach; we had customers, we knew that the business case closed, but the load was starting to overpower the main database, so we spun off separate databases, and bought ourselves a little more overhead by splitting out the normalized and denormalized data. Could well have been a mistake, but we weren't thrilled with postgres ability to scale horizontally, so went to CB so we could scale a bit more. (As I recall, we were doing 7m emails a day, our goal was to support up to 70m with that structure.)
drdrey 9y ago
Interesting choice to have people sign up for free stickers. I expect a follow-up article on "The Marketing Behind the Marketing Behind MongoDB" :)
- nemild 9y ago
  Both the stickers and three-part series were conscious choices. Etsy did a three-part series on the benefits of MongoDB in the early 2010s. MongoDB was also well known for its stickers, and their marketing team wrote online about how these stickers helped solicit emails: "Give away swag: This is a low cost, easy way to build a lead database and get developers to decorate their laptops with your logo!"
  - drdrey 9y ago
    I see, thanks for the extra context. By the way, the notion of "marketing attacks" is a powerful one, it's going to stick with me.
    - 52-6F-62 9y ago
      I take it you never skateboarded. If you really want to see a veritable marketing orgy, look at the skateboarding world. It's gotten even crazier last time I looked. This is like the kale salad of that type of marketing. It is definitely effective, though.
  - hwayne 9y ago
    Do you know if it ended up ever being a full series? The Etsy site only has the first two parts.
    - nemild 9y ago
      It ended at two, but these were later follow-ups that seemed inspired by the early experience. The first one below especially felt like a coda to the first two: http://mcfunley.com/why-mongodb-never-worked-out-at-etsy http://mcfunley.com/why-mongodb-never-worked-out-at-etsy http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
burgerdev 9y ago
I maybe missed it in the posts, but would you mind to explain why you focus on MongoDB in particular and NoSQL in general?
- nemild 9y ago
  I was in the startup world in the early 2010s, and saw MongoDB used in a number of startups (over ~5 years). These companies included everything from very early stage Y Combinator backed startups to one of the most famous unicorns (tech issues at growing companies are rarely discussed publicly, so I was lucky that my friends were willing to privately share; compare that to successful tech decisions, which are widely discussed and blogged). In that time, I heard many stories about the issues companies had with it - and angry debates about whether it was the right choice. In the early years, you were ancient if you used something more conventional than Mongo; in later years, you were dumb if you used Mongo in many startups (both views have their issues). I wanted to understand: - Why was MongoDB so popular - What issues did startup engineers have with it - Given these issues, why was it chosen in the first place And most importantly, what lessons does this case study have for future dev tool decisions.
mathattack 9y ago
There's 100X the interest in hyping technologies, as opposed to realistic analysis. I appreciate that you chose the latter.

by nemild 9y ago

primitivesuave 9y ago

I really enjoy your writing style and how you wrote about the "story of humans" rather than writing YAMTT (Yet Another MongoDB Trash Talk). I'm actually a lot more comfortable now using MongoDB in production after understanding its level of maturity and what the right application is. For the last couple years I was scared off by all the negative HN comments on MongoDB articles.

nemild 9y ago
Thanks for the kind words. Most thoughtful engineers I've met are believers in right tool for the job and thinking in tradeoffs, not good and bad - and so I'm a big fan about digging into MongoDB's value and understanding your projects' needs. MongoDB has matured as well over the last decade, and it's a testament to the hard work of their engineering team. You may like this old post that I wrote which echoes the broader points I make in this series about thoughtfully making eng choices and having better eng debates: https://www.nemil.com/musings/betterdebates.html https://www.nemil.com/musings/betterdebates.html
bulldoa 9y ago
so what is the right application for mongodb? only when you don't need ACID? Can you give some example? Genuinely curious
- mandevil 9y ago
  We used Couchbase (a NoSQL like MongoDB) for email batch sending (think invitations to a party) and it worked very well. We could store each email sent as a separate, denormalized document so the sender could see EXACTLY how their contact data was replaced in each individual instance, the "View as a Web Page" functionality was trivial (instead of recalculating everything from the normalized forms- which can be blown up by contact data changes, just load the document that you sent out), and it's lovely TTL feature meant we could handle the configurable retention policies trivially as well. It wasn't so good at doing reports (how many customers viewed the email yet, responded, etc.). One thing we talked about doing was just storing a sqlite or h2 database as a document for reporting purposes (if we had been more single threaded that could have worked nicely). We ended up using a separate Sql DB for that. There are cases where denormalized data is the "right" way to view stuff, and cases where the data really is easier if its normalized, and that is a good reason to push your DB selection one way or another.
  - lilbobbytables 9y ago
    Interesting. Seems like that would just be one part of a larger application, though. And for that, my mind just jumps to something like Postgres with `jsonb` fields to store it all denormalized, then using columns to store relations, like the contact it was sent to. Along with other tables for other parts of the application, of course. This way your aren't complicating your stack by adding more services sooner.
    - mandevil 9y ago
      We were replacing a fully SQL email engine (that was starting to fall over due to load) with this more hybrid approach; we had customers, we knew that the business case closed, but the load was starting to overpower the main database, so we spun off separate databases, and bought ourselves a little more overhead by splitting out the normalized and denormalized data. Could well have been a mistake, but we weren't thrilled with postgres ability to scale horizontally, so went to CB so we could scale a bit more. (As I recall, we were doing 7m emails a day, our goal was to support up to 70m with that structure.)

drdrey 9y ago

Interesting choice to have people sign up for free stickers. I expect a follow-up article on "The Marketing Behind the Marketing Behind MongoDB" :)

nemild 9y ago
Both the stickers and three-part series were conscious choices. Etsy did a three-part series on the benefits of MongoDB in the early 2010s. MongoDB was also well known for its stickers, and their marketing team wrote online about how these stickers helped solicit emails: "Give away swag: This is a low cost, easy way to build a lead database and get developers to decorate their laptops with your logo!"
- drdrey 9y ago
  I see, thanks for the extra context. By the way, the notion of "marketing attacks" is a powerful one, it's going to stick with me.
  - 52-6F-62 9y ago
    I take it you never skateboarded. If you really want to see a veritable marketing orgy, look at the skateboarding world. It's gotten even crazier last time I looked. This is like the kale salad of that type of marketing. It is definitely effective, though.
- hwayne 9y ago
  Do you know if it ended up ever being a full series? The Etsy site only has the first two parts.
  - nemild 9y ago
    It ended at two, but these were later follow-ups that seemed inspired by the early experience. The first one below especially felt like a coda to the first two: http://mcfunley.com/why-mongodb-never-worked-out-at-etsy http://mcfunley.com/why-mongodb-never-worked-out-at-etsy http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology

burgerdev 9y ago

I maybe missed it in the posts, but would you mind to explain why you focus on MongoDB in particular and NoSQL in general?

nemild 9y ago
I was in the startup world in the early 2010s, and saw MongoDB used in a number of startups (over ~5 years). These companies included everything from very early stage Y Combinator backed startups to one of the most famous unicorns (tech issues at growing companies are rarely discussed publicly, so I was lucky that my friends were willing to privately share; compare that to successful tech decisions, which are widely discussed and blogged). In that time, I heard many stories about the issues companies had with it - and angry debates about whether it was the right choice. In the early years, you were ancient if you used something more conventional than Mongo; in later years, you were dumb if you used Mongo in many startups (both views have their issues). I wanted to understand: - Why was MongoDB so popular - What issues did startup engineers have with it - Given these issues, why was it chosen in the first place And most importantly, what lessons does this case study have for future dev tool decisions.

mathattack 9y ago

There's 100X the interest in hyping technologies, as opposed to realistic analysis. I appreciate that you chose the latter.