Not related to an Section 6.1 database called NoSQL, the "NoSQL movement" has emerged as an approach to databases which originally tended to be a reaction against SQL, but is now more properly "Not only SQL", which tends to relax the Section 5.1 properties that are typical of "RDBMS - Relational Database Management Systems":
Transaction semantics are often unimportant and/or annoying
Locking? Why are we waiting for things?
Joins require consistency assumptions that make it difficult to distribute data
Databases may be so large that they cannot readily fit onto one server
Applications should work well even if connectivity between distributed databases is interrupted
Applications should work well when the database is replicated across host servers and occasionally-connected mobile clients
Schemas are annoying
Many of those represent rather "snide" characterizations of Section 5.1, with rather obvious retorts that may be returned. Sometimes such is deserved...
In many cases, unsophisticated usages are treated as if they are characteristic of "all systems."
This fits with the old scenario where people building simple web commerce systems find Section 3.2.1 fine, and have no particular need for the "complificated features" of PostgreSQL.
Unfortunately, if usage scales up, requirements will, in some fashion, scale up, and there's really little sense in reinventing via trial and error the wheels of transaction semantics, locking, and system consistency when smart people already though through the issues when implementing robust relational database systems. There's the old canard about those that don't remember history being doomed to repeat it...
An effort is ongoing for a query language, UnQL Specification. It bears a remarkable resemblance to SQL...