For us, the reason to run with MongoDB in 2009 were twofold: a) for one of our products which was consuming the Twitter gardenhose, unverified writes were a ble

For us, the reason to run with MongoDB in 2009 were twofold: a) for one of our products which was consuming the Twitter gardenhose, unverified writes were a blessing. We got away with a single dedicated server running mongodb (and it was not a particularly expensive server). I would need to do serious research again whether there's a better solution for this today. It was using Stanford NLP to highlight breaking news before anyone realized. We never got a single subscriber because every newsdesk that saw it wanted to acquire us immediately LOL. Eventually one did. b) For another, the ability to store and index complex documents which in SQL would've needed JOINs and you couldn't index across JOINs at least in MySQL and our previous experience in PostgreSQL vs MySQL support didn't favor PostgreSQL at the time at all. It worked -- although it didn't have a journal back then. We were ready for a failure but the failure never came. The landscape today is much different with PostgreSQL and MySQL and SQLite all embracing JSON storage and indexing on expressions are there for all three.