一些NoSQL数据库添加了自己的“类SQL”的查询语言，如Cassandra的CQL。但这往往使问题更糟。使用几乎相同的界面，却让内心更纠结：工程师不知道什么是支持的，什么不是。
社区中的一些人在早期就看到了NoSQL的问题(例如，DeWitt和Stonebraker在2008年就看到了)。经过时间的实战检验，以及使用过程中的经验积累，越来越多的软件开发人员也看到了这一点。
第3部分：回归SQL
经历了黎明前的黑暗，软件社区看到了曙光，那就是回归SQL。
首先是Hadoop(之后的Spark)之上的SQL接口，引导业界兴起了NoSQL ,NoSQL“不仅仅是SQL”。
然后，NewSQL的兴起：新的可扩展性数据库，完全支持SQL。来自于麻省理工学院(MIT)和布朗大学(Brown)研究人员的H-Store (2008年发布)是第一个可扩展OLTP数据库之一。Google在发布的第一份Spanner论文(2012年发布)(其作者包括最初的MapReduce作者)中揭示这是基于 SQL 的查询语言，可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性，从而开创了可地理复制的SQL界面的数据库，接着是CockroachDB(2014)这样的先驱者。
与此同时，PostgreSQL社区开始复苏，增加了JSON数据类型(2012)，以及PostgreSQL 10 的新特性：对分区和复制更好的本地支持，JSON的全文搜索支持等(今年晚些时候发布)。其他像CitusDB(2016)和其他的公司(今年发布的TimescaleDB)发现了新的方法从而针对特定数据工作负载的扩展PostgreSQL。
事实上，我们开发TimescaleDB的过程与业界的发展轨迹密切相关。早期的TimescaleDB内部版本使用了我们自己的类sql查询语言“ioQL”。是的，我们正是被困难驱动着：构建我们自己的查询语言才能更强大。但是，虽然看似简单，但我们很快意识到，我们必须做更多的工作：例如，决定语法，构建各种连接器，培训用户等。我们还发现自己需要不断地去查找合适的语法，去查询那些已经可以用SQL进行查询的内容。
有一天，我们意识到建立自己的查询语言是没有意义的。关键还是要拥抱SQL。这是我们做出的最好的决策之一。同时也开启了一个全新的世界。今天，即使我们的数据库才问世5个月，但我们的用户完全可以使用我们的产品，并获得各种各样支持：可视化工具(Tableau)，通用ORM连接器，各种工具和备份选项，大量的在线教程和语法说明等。
但是不要把我们的话放在心上，看看谷歌
Google已经十多年来一直处于数据工程和基础设施的领先地位。我们应该密切关注他们正在做什么。
看看谷歌的第二大Spanner论文，仅在四个月前发布(Spanner：成为一个SQL系统，2017年5月)，你会发现它支持我们的发现成果。
例如，Google开始在Bigtable之上开发，但是后来发现缺少SQL产生了一系列问题(在下面的所有引号中有强调)：
“虽然这些系统提供了数据库系统的一些优势，但它们缺乏应用程序开发人员常常依赖的许多传统数据库功能。一个关键的例子是强大的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合应用程序中的数据。因此，我们决定将Spanner变成一个功能齐全的SQL系统，其查询执行与Spanner的其他架构功能(如强一致性和全局复制)紧密集成。
在本文的后面，他们进一步了解从NoSQL转换到SQL的理由：Spanner的原始API提供了为单个和交叉表的点查找和范围扫描的NoSQL方法。虽然NoSQL方法提供了启动Spanner的简单路径，并且在简单的检索方案中继续有用， 但SQL在表达更复杂的数据访问模式并将计算推送到数据方面提供了重要的附加价值。
本文还介绍了如何在Spanner上使用SQL并不会停止，哪怕某一个数据中心停止运转,仍然可用。但实际上扩展到Google的其余部分，其中多个系统共享一个通用的SQL语言：
Spanner的SQL引擎与Google的其他几个系统共享一个称为“标准SQL”的常见SQL语言，包括内部系统，如F1和Dremel(以及其他)以及外部系统，如BigQuery 。
对于Google用户，这会降低跨系统的工作障碍。对Spanner数据库编写SQL的开发人员或数据分析师可以将他们对语言的理解转移到Dremel，而不用担心语法，NULL处理等方面的微妙差异。
这就是这种方法的成功奥秘。当“潜在云客户对SQL有浓厚兴趣”时，Spanner已经成为Google主要系统的根基(包括AdWords和Google Play) 。
考虑到Google最先启动了NoSQL的运动，这是非常显著的，它今天正在回归SQL。(引起一些人反思：“ Google 10年前挺进大数据市场就是个大忽悠吗” )