Using MongoDB as your primary Django database

I was on a project a few years ago (first PoC with Mongo 1.2, started properly in 1.4, delivered with 1.8). Have the following things improved?

- RAM usage was a killer. For some datasets, key names took up more memory than values. - Throwing custom JS at mongo nodes was kind of fun, and we could do interesting stuff with it that we couldn't easily do on the previous (non-sharded) datastore. But out-of-memory situations in the JS runtime was less than graceful and caused mysterious replica breakage/hangs. Eventually it was suggested that we were using MongoDB in a way that wasn't typical or intended, which was fair enough. - We had trouble using it as a truly "schemaless" database (scientist users defining, maintaining, collaborating on their own data with object-level access controls and versioning): when you sort the result of a query (needed for paging), you either needed indexes (exploding RAM usage, finite number of indexes possible per collection) or if you could tolerate slowness (as we could) then you could use .limit() but it was hard to get the what-should-the-limit-be heuristic right, our object sizes varied wildly (sometimes exceeding BSON data size limit at times).

In another project we used MongoDB to back a read-only HTTP API representation of some 10s GiBs of reasonably stable and predictable external data, in that case it felt we were fighting it a lot less and it worked reasonably well.

I've also messed with eXist, Neo4j (which was fascinating) and a few other NoSQL things - at the end of the day I have to believe that for large sprawling heterogeneous systems (i.e. not the lone django web-app use-case) you will always want to keep authoritative data in something else and treat the NoSQL thing as a cache that can be rebuilt at any time.

Curating arbitrarily connected business objects in a graph (or having different codebases with slightly different understanding of the data mess with a given mongo collection) is infinitely harder than orderly relational tables, especially for the traditional DBA people who know how to read business process from a well-designed relational DB and likewise write such a thing by understanding those processes themselves quite well (something I didn't give them much credit for until a few jobs ago).