No Sql

See http://en.wikipedia.org/wiki/Nosql

NoSql was the revolt against using a RelationalDatabase for data which was neither relational nor transactional. Think DataWarehouse or log records storage. Putting 10 billion entries that were never going to be changed into MySql, in a distributed reliable fashion, where consistency was not a requirement, was just causing too many GreyHairs?. -- DerekWoolverton

It hasn't been clear within this movement whether the "problem" is the SQL language or the implementations. Ideally, they should be separated as we don't want hardware to dictate languages if possible.

It's the implementations. Whilst there's been an insignificant adoption of NoSql by naive developers trying to avoid learning a query language, most adopters have used it for solutions where the volume of updates and/or queries, and/or the volume of records, and/or the need for distribution, and/or the need for dynamic record contents, far exceeds the capability of conventional SQL DBMSes.

Re: "It's the implementations" - Then the movement is misnamed. But, I'm at a loss for a better one that describes their reasons for revolt. The existing set of RDBMS is generally influenced by Oracle's products. Oracle was the first major seller of RDBMS, arguably creating the industry[1], and other firms followed suit with semi-copy-cat products. "No-Oracle-Clones"?

(For discussions of SQL language flaws, see SqlFlaws and HowOtherQueryLanguagesAddressSqlFlaws.)

Alleged Shortcomings of "Traditional" RDBMS:

Not dynamic enough. On-the-fly schema change or attribute addition is sometimes wanted. (See also DynamicRelational).
Poor support for distributed servers or repositories.
Insufficient ability to relax "data integrity" features to benefit other factors such as speed, server/load distribution, and/or schema dynamic-ness if such trade-offs are desired.
SQL language complaints (See SqlFlaws).
Lack of support for hierarchical structures
Lack of support for text or document-oriented processing
Too restrictive or expensive: requires a specialized DBA to make changes or design decisions.

An open issue is whether these features can be added to traditional RDBMS, or if one has to throw the baby out with the bathwater.

Alleged Shortcomings of the NoSql Movement:

Lack of standards comparable to SQL and ODBC/JDBC.
The different products emphasize different things: one may emphasize distributed servers, another hierarchies, and so forth. (It could be a case of IncompatibleGoals and they are merely intentionally niche-oriented.)
Lack of ACID and other data integrity features.
Confusion between different query languages versus different implementation.
May not serve general-purpose needs as well as traditional databases such that "back room" operations may need a different DB product than "front-room" applications, making cross-system communication and tool knowledge sharing difficult.
Query languages and interfaces being driven by hardware viewpoints instead of logic and abstraction considerations. This may limit future expansion or flexibility being that hardware changes quickly.

I question whether some of these contraptions even qualify as a "database".

Depends how you define "database".

A database is something that stores and processes LaynesLaw.

BagSetImpedanceMismatchDiscussion discusses some NoSql-related techniques and trade-offs.

Footnotes

[1] IBM created most of the SQL language, but didn't appear interested in promoting it at first. This is probably because of fear it would hurt sales of IMS, a popular and profitable NavigationalDatabase. Only when Oracle started significantly eating into their market did IBM put sufficient resources into their RDBMS.

Oracle in turn "Denounced the NoSql Hype", concluding "compared to relational databases, their feature set is primitive. [...] Go for the tried and true path. Don't be risking your data on NoSQL databases." just a few months before releasing their own NoSql database system. [http://www.wired.com/wiredenterprise/2011/10/oracle-nosql-database/]