3 ms·
Reading past marketing blurbs and using products for the things they are designed is part of any engineer's job. I was irritated by MongoDB's claims and default
by Jare 6y ago
Reading past marketing blurbs and using products for the things they are designed is part of any engineer's job. I was irritated by MongoDB's claims and defaults, but that didn't stop us from putting it in production. We used it from 2012 to 2016 (their most infamous years?), and for our use cases, scale, size+expertise, and feature set, it was a perfect match. In our case, durability was a smaller concern by design (lots of write-only data, lots of ephemeral data), but we still configured it carefully and never ran into any data loss whatsoever; snapshots worked, migrations worked, etc.
If the service had lasted longer, scaled bigger, and the business it supported had been more successful, we might have ended up with a now-classic MongoDB to pg migration. That was always an acceptable outcome, and it would have not invalidated going with Mongo at the start.
- collyw 6y ago>In our case, durability was a smaller concern by design (lots of write-only data, lots of ephemeral data), I assume that you mean write once data. If you mean write only you might as well use /dev/null.
- haimez 6y agoThe performance gains are very impressive https://tech.wayfair.com/2013/04/devnull-vs-mongodb-benchmark-bake-off/ https://tech.wayfair.com/2013/04/devnull-vs-mongodb-benchmar...
- Jare 6y agoMost backups are never actually read / used after writing but /dev/null is not a good substitute for them. [Edit] in case I wasn't clear: Imagine data that is written and rewritten and overwritten before it gets read; a user that never returns to your product - his state data was written but will never be read. That sort of thing.