"NoSQL" took the idea of a rejection of syntax (SQL) but also, in practice, burned in with it a rejection of vast swathes of database theory that resulted in the modern RDBMSes. It was a meme that was generally easy to ignore and identify the "bad ideas" within if you understood the history of databases. SQL obviously is just an incidental syntactic detail on top of a fairly sound, generalized model for databases -- relational algebra combined with a clear semantic model for transactions (ACID, etc.)<p>These two things I believe will stand the test of time. Everything else, I think, is ultimately incidental complexity to meet operational goals (like indexing, or caching methods, or sharding, or replication, or denormalization) or conceptually useful models and interfaces (like graphs, or literate APIs, or query langauges, or ORMs, etc) on top of these basic facilities that need to be provided by a database system.<p>The trend of NoSQL databases I think can be summarized as people building systems that tilted towards letting these bits of incidental complexity dictate the design of the system as a whole. The overriding concern seemed to be "scalability and performance" with "easy APIs" a close second and so that resulted in specific data structure and API needs or access patterns dictating everything about how the database system itself worked, and how data was modeled in that system.<p>For example, MongoDB was hearalded as finally letting you access a hierarchical data structure without SQL JOINs, but did so not by just providing a nice abstraction on top of a sound relational schema that allowed you to "re-project" your thinking and access patterns to a document-oriented one when it was the right model contextually, but instead by burning that denormalized, document-oriented data structure into the entire conceptual and technical stack for the whole system!<p>The cost, of course, is self-evident since choosing to reject the relational model also chooses to reject the benefits that were explicitly recognized as a reason for the relational model to be a good choice for database systems: normalized data allows a much more rich set of transformations and projections on that data to be unambiguously expressed and fulfilled by the system. In other words, it's much more future proofed since you now have the flexibility to mix-and-match and analyze it in arbitrary ways, decoupled from your choice of schema. So the effect of choosing MongoDB meant that you had minimal future-proofing if you got your document structure wrong and suddenly needed to re-project your data in a new way. The supported path, of course, was to "just run map reduce on it" -- ie, lets force every application developer to do the job the database is supposed to do :(<p>It's nice to see things are moving forward on this again, hopefully the trend doesn't just reverse now and we have a flood of "SQL access" APIs to poorly grounded database systems.