Given how our ponies are snuggly-friendly with relational database technology, there's a sense of outreach as well as girding for a possible future, in which NoSQL takes off a lot more than it has. Buzz words in this namespace today include: HBase, MongoDB, Riak, Voldemort, Neo4J, Cassandra, Hypertable, HyperGraphDB, Memcached, Tokyo Cabinet, Redis, CouchDB.
Alex Gaynor, soon to turn 20, spent a Google summer of code wrestling with the task of fitting Django's ORM API to a MongoDB back end. Some on the panel questioned the advisability of fitting a schemaless database into such a schema-based framework, but then Django is somewhat characterized by this API. What else would it mean, to add support for a NoSQL back end, if not keeping the API streamlined and powerful.
It's not a given that every back end key-value or document store is a good fit. In the case of MongoDB, there's enough of a one-to-one mapping to make the bridge or database adapter. Google's BigTable is likewise "close enough" to a SQL engine (though it isn't one) to support a somewhat Django-like API within it's Appengine framework.
One has other ways of using such NoSQL utilities as redis inside Django. Django is just Python after all, so if its a matter of simply importing another module and using it, you may do so directly, through whatever API Python natively provides. Use this alongside ORM connections to SQL engines. It's not either or (like, use the zodb module why not?). How is redis different from just using a memory cache like memecache? The API does a lot more.
On the whole, the panel was reassuring the PostgreSQL would always be enough of an "out of the box" solution to throw at so many of life's many challenges. Don't let the "rip tide of lies" (i.e. all the empty hype) around NoSQL pull you off balance. The Django community is experimenting, outside of core-dev.
