[octix]

From personal experience.

1) MongoDB allows me to be more agile. I don't have to deal with database migrations (No locks when adding new column for example), which allows deployments at any time.

2) Indexed arrays. Allows to add "tags" to any entity which are useful in production (A/B testing, force specific behavior).

3) Easier to manage. I don't need an expensive PostgreSQL consultant to setup and hope for the best.

Your mileage can vary.

[drodgers]

> I don't have to deal with database migrations

We've actually just started having the pain of Mongo migrations; adding indexes to large collections. If you just create the index on the primary and let it propagate throughout the cluster, then it will block further oplog replication on the secondaries and the whole cluster will go down for majority writes. The proper way is to take each secondary out of the cluster in turn, add the index, then step-down the primary and migrate it.

It's just as much of a pain as migrating your favourite SQL database, although at least you don't need to do it for small collections and for adding columns (which is a big bonus).

[octix]

Thanks for sharing. "adding indexes to large collections" - how many records are we talking here?

Thanks.

[drodgers]

Collections with tens of Gigabytes and hundreds of millions of records can take a few hours per-node to build an index. You'll need to think about index migration strategies before that point though. I'd guess that once you have gigabytes of data in a collection you'll probably have less downtime with an election than you will waiting for the index to build.

[kureikain]

If it's truely zero downtime if you are doing background indexing.