If you look carefully, you'll find that a whole heck of a lot of those banks, insurance companies, and so forth are already using something that falls into the

If you look carefully, you'll find that a whole heck of a lot of those banks, insurance companies, and so forth are already using something that falls into the NoSQL realm -- Lotus Notes/Domino. The use case for a document-based, schemaless database is already well understood, if not always by the developers using it (or by the developers who grew up on a strict diet of relational databases). It boils down to this: do you need addressing that would not be well-served by structured, tabular data? Relational databases are (or should be) extremely efficient at accessing data that can be arranged neatly into tables and read using the equivalent of pointer math. They suck, though, when the data is stored outside of the table (as large text fields, blobs, and so forth would be). The more heterogeneous and variable the data, the worse performance gets. A schemaless database gives up efficiency with tabular data, often precluding efficient runtime joins and, consequently, multiple orthogonal data access paths (data normalization) for a more efficient generalized access. As a thought experiment, imagine a data quagmire where, in order to make the data fit a SQL table, every cell in every row in the database would need to be varchar(17767) and may contain multiple character-delimited values (or not --each record can be unique) and every row can have an arbitrary number of cells. That's what schemaless data can, and often does, look like -- and something like Notes or CouchDB can work with that comfortably and with an efficiency that cannot be matched by a relational representation of the same data.