一、有没有什么基于postgresql的newsql

只关心外部接口的话：CockroachDB, YugaByte DB。降低点要求的话，比如MPP数据库：开源的Greenplum，扩容可以在线进行，但是需要人工介入。最“官方”的的版本应该是 PostgreSQL-XL，也是更新的比较及时的横向扩展版本，基本能跟上主流版本升级。

重点介绍一下CockroachDB：

说明：

构建于事务处理及强一致性KV存储上的分布式SQL数据库，支持水平扩展、自动容错处理、强一致性事务，并且提供SQL接口用于数据处理，是Google Spanner/F1的开源实现。 CockroachDB适用于应用对数据要求精确、可靠、完全正确的场景，支持自动复制、均匀分布、基于极小配置的数据恢复，可用于分布式的、可复制的联机事务处理（OLTP），多数据中心的部署，私有云的基础构建，它不适用于读少写多的场景，可以用内存数据库来代替，也不适用于复杂的join查询，重量级的数据分析及联机分析处理（OLAP）。

特性：

支持PostgreSQL

对标准SQL支持较完善

较稳定

延伸阅读：

二、TiDB和Cockroach之间的区别

1.用户界面和生态系统尽管TiDB和CockroachDB都支持SQL，但TiDB与MySQL协议兼容，而Cockroach选择PostgreSQL。您可以使用任何MySQL客户端直接连接到TiDB服务器。

2.体系结构整个TiDB项目在逻辑上分为两部分：无状态SQL层（TiDB）和分布式存储层（TiKV）。由于TiDB建立在TiKV之上，开发人员可以根据自己的业务自由选择使用TiDB或TiKV。如果您只需要分布式键值数据库，则可以单独使用TiKV以获得更高的性能和更低的延迟。

总之，我们的系统是高度分层和模块化的，而CockroachDB是一个P2P系统。我们系统的设计导致我们使用两种编程语言：Go for TiDB和Rust for TiKV以提高存储性能。

并且受益于高度分层的架构，我们构建了另一个项目[1]，以便在TiDB / TiKV之上运行Apache Spark来回答复杂的OLAP查询。它利用了Spark平台和分布式TiKV集群的优势。

3.事务模型尽管CockroachDB和TiDB都支持ACID事务，但TiDB使用了Google的Percolator引入的模型。该模型的关键特性是它需要一个独立的时间戳分配器。与Spanner一样，TiDB中的每个事务都有一个时间戳来隔离不同的事务。

CockroachDB使用的模型类似于Google在其论文中描述的TrueTime API。然而，与Google不同，CockroachDB没有构建原子钟和GPS接收器来保持不同数据中心的时间一致。相反，它使用NTP进行时钟同步，这导致了不确定错误的问题。为了解决这个问题，CockroachDB采用了混合逻辑时钟（HLC）算法。

4.编程语言TiDB使用Go作为SQL层，使用Rust作为存储引擎层。由于Go具有垃圾收集器（GC）和运行时，我们认为调整性能将花费我们几天的时间。因此，我们对TiKV使用Rust，一种静态语言。它的表现要好得多。CockroachDB只使用Go。