Hacker News Reader

Comment by primitivesuave | Hacker News Reader

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.

View on HN

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

so what is the right application for mongodb? only when you don't need ACID? Can you give some example?

Genuinely curious

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.

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.

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.)

Reply on news.ycombinator.com