There are a lot of people who would like a full-fledged relational database that scales up to large clusters. Just because you're not one of them doesn't mean they don't exist, or that they're "completely missing the point."

I was referring more to the marketing aspects of the term (and proposing their solution as a counterpart to "NoSQL"), than the concept itself. There are a lot of people who think that "NoSQL" is all about magic scaling sauce, and this isn't really helping.

I don't really understand why one would accept the trade-offs of "NoSQL" if you aren't interested in "magic scaling sauce" (and clustered redundancy).

What's the advantage here? Less rigorous schema, moving data modeling and constraints into the more complex application code that's much more likely to have bugs?

I can't tell you how many times database constraints have caught application bugs with fatal data correctness consequences on the products we've worked on.

The only reason I can see for abandoning those declarative constraints is because of the scalability issues one must contend with (and even then, I'm somewhat unconvinced that they matter for all but the highest-load entities).

Some the the databases grouped under the over-broad NoSQL umbrella have reasons to use them other than magic scaling sauce. Redis, for example, is a ridiculously fast in-memory database that gives you data structures like sets, lists, hash tables, strings, numbers, and so on. It's tremendously useful for some problems.

For example, at Greplin we're using Redis for our document analysis pipeline. We're pushing thousands of documents through Redis every second, using it to durably hold data while it gets passed around through our various back-end worker server clusters. We've been very happy with how Redis has been performing; it handles the write-heavy workload beautifully, and is way more resistant to data loss than most systems for doing this sort of thing. We'll be even happier when it gets server-side Lua scripting in a stable release, and we can define our own commands. The point is, though, that this would be crazy to do with a traditional SQL database, or even something like Riak or CouchDB or most of the other NoSQL databases. Redis fills a different niche, and filling a lot of cool niches is what I think the NoSQL stuff should be about.

OK, you're rational. Unfortunately you're in the minority.

Exactly. I use MongoDB because schema-less databases make prototyping my applications easier. Migrations became a pain point.