目前来说，各厂商的云原生数据库在演进路线上分成了两个略有不同的路径来解决不同的问题。

一种是各大公有云厂商选择的，优先保证上云兼容性的路线，就是基于存算分离架构对传统数据库进行改造的路线：通过把大量的日志操作放到后台异步处理，实现存储独立扩展，解决了 MySQL 数据库单库的数据量不能太大的痛点。并且云原生数据库提供了又兼容又能扩展的能力，在存储层面实现了扩展的同时，又保留了计算层面的不变和兼容，从而基本实现了完全的兼容性。像典型产品就有 AWS 的 Aurora，阿里云的 PolarDB，腾讯云的 TDSQL-C 和百度智能云的 GaiaDB。可以完美兼容传统的使用习惯，对交易类场景可以提供很低延迟的写事务能力。同时读扩展性与存储扩展性由于借助了分布式存储池化能力，也得到了极大增强。

而另外一种则是优先将系统的扩展性放在首位，通过规模来解决各类业务对写扩展能力的要求，像 OceanBase 和 TiDB 就是两个比较典型的产品。它们的典型特征就是将事务系统和锁系统角色拆分为单独的模块负责，计算层通过与这些模块交互实现了多个节点都可接受写请求，然后由统一的新事务+锁中心节点来进行仲裁。这样对于写负载本身需要较多计算资源的场景下会有很好的提升，但是由于事务和锁都需要跨网络进行交互，所以事务延迟是相对比较高的，在锁负载较重的负载下会成为一定的瓶颈。