[nnq]

Wake up. People don't use Mongo because of it's better write performance. They use it because it increases junior developer productivity at building a shipable MVP and allows for more "natural" data models 99% of the time.

Reason: real-world data is almost never relational by nature, and you never really need ACID (even for financial data you can find a subset of ACID that's appropriate for you use case and complies with your regulations, and tweak a nosql solution to achieve it) and any relational model of data will be "awkward" in one way or another. Trying to get a more natural data model, it's always a question of either (1) storing graphs in a tree db (read "document db") or (2) trees in a graph db (no good open-source and easily scalable graph dbs around, too much developer inertia). Couple (1) > (2) for now, with the fact that write performance is more important than versioning for most (mostly because "naive" versioning at "big data scales" takes too much space), hence CouchDB < MongoDB and also "column dbs" being really odd for most general use cases and "nosql document dbs" remain the only sensitive choice for most projects.

I've finally seen the light and stopped recommending Postgres over Mongo to people :)

Rethink is probably a better idea. And there's also Arango. And I happen to love Neo4j. But Mongo is "good enough" for most, hence the obvious choice for a general purpose web framework.

[dang]

> Wake up.

Please don't. Your comment becomes much better if you simply take out that rude bit.

[k__]

Really?

I had the feeling that data-models of document stores like MongoDB often only fit one use-case and fail after that.

A blog, for example.

You have Article and Comment and when using a document store, it comes naturally to embed Comment in Article, because, well the first thing you need is to display comments below articles.

Then you want to show the comments of a user, but they are stored inside the articles...

If you had a relational data-store the way to retrieve the data for both cases would be the same mechanism, a join.