It's for creating an abstraction layer that allows to write portable apps and that provides a much more powerful API than boring hashmaps (as you might have noticed, lots of APIs for those DBs try to get away from the hashmap representation). How often have you written manual denormalization code or manual in-memory JOIN code? How often did you manually keep track of counters? What are you trying to achieve with that, anyway? You're "manualating" features you get for free with SQL. That's waste. It's something you shouldn't have to do. It can be automated and that's our long-term goal.

These DBs are like writing with Assembler just to get more speed (or scale in this case). The point is, you can use a high-level language (here, Django's ORM plus a few "optimization" specifications) to achieve the same result much faster and in a portable way.

For anything that goes beyond the ORM's features we can still provide MapReduce and other mechanisms, but again with a higher-level API. Do you really believe 10 years from now we'll still be using hashmaps to access those DBs? (just trying to provoke some thought; I don't really believe that you think that way)

But that is a defense of ORMs, not using ORMs for NoSQL solutions. The value of document stores for me is that I don't have to worry about JOINs or normalization - and thus the layer of abstraction between the object oriented system and the document store is no longer necessary.

This is opposed to relational databases, where you generally either go with a DAL if you want to be low-level or an ORM if you're willing to sacrifice some scalability. And the loss in scalability is not comparable to that of going from assembly to a higher level language. ORMs include often unnecessary JOINs and other logarithmic queries whose performance degrades with the size of the data set. With programming languages, performance loss is usually "constant" so it's a much less painful pill to swallow.

Well, instead of thinking about normalization you now have to think about denormalization. It's just the other extreme. This isn't really a philosophical decision. Either you want to have an abstraction layer that takes care of these things for you or you want to write your code manually. I prefer the abstraction because it gives me more time to think about the problems that matter.

Maybe I'm dense, but I still don't understand. I'm guessing denormalization means going from relational data to non-relational data. When you're working with a document store, data never has to be normalized, and as a consequence, it never has to be denormalized either.

Take, for instance, getting a user with the first name 'Martha'. In a document store, it might look like:

  store.get({first='Martha'})

Whereas in Django's ORM, it might look like:

  User.objects.filter(first='Martha')

And for reference, the SQL might look like:

  query("SELECT * FROM User JOIN Preferences ON User.Id=Preferences.UserId WHERE First=%s", 'Martha')

The first two are obviously simpler than the third. But how is the Django ORM inherently superior to the document store's? When your atomic unit is a document, there's no longer a need for Django models.

i think full blown ORM-style is the wrong abstraction, at least for now. until the abstractions are good enough, staying close to the metal is a good idea. also querying is easy (there's not a lot of options), but keeping multiple indexes updated and partitioning them etc. is where the fun begins.

for my own needs, i've started building a thin (transparent) abstraction layer for cassandra . take a look here for a code example: http://github.com/enki/tragedy

Weird, I wrote something almost identical to this. Still waiting on permission to open source though.