苍狼白鹿，星霜几度｜万字长文回顾 2022 年数据库行业

快速冷却的市场

21 年是有史以来数据库融资最火的一年，22 年上半年开始似乎还延续着势头，Timescale，Dbt Labs，Starburst，DataStax，SingleStore 都完成了上亿美金的融资。不过马上随着宏观环境的每况愈下，下半年就再也没有出现中后期数据库公司的融资事件了。早期项目里，值得一提的是 Neon 3000 万美金，以及 MotherDuck 4750 万美金的融资，但这两者都是全明星创始团队，一上来就到 A 轮。

相同的情绪也蔓延到了国内，年初还有沿着 21 年惯性 SelectDB 超 3 亿人民币天使轮这样破纪录的融资事件，接着整个行业就冻结了，直到临近年底，才又看到 Greptime 几百万美金的融资。

年末 MariaDB 通过 SPAC 上市，也立马一路从 11 块跌到 3 块出头。他的股价表现就是今年数据库融资市场的缩影，出道巅峰，一路向下。虽然融资环境大不如前，但数据库行业的发展相比去年却有更多的亮点。

年度技术 - Velox

每一个数据库都需要一个执行引擎（Execution Engine），之前不同的数据库系统都是各自研发的，比如 Presto 一个， Spark 一个。但这些执行引擎要实现的功能又都是类似的。Velox 就把这些通用的能力提取了出来，封装出了一个库（Library），主要的组件包括：

• Type - 通用类型系统。

• Vector - 基于兼容 Apache Arrow 列式内存的向量化能力。

• Expression Eval - 表达式运算，也包括利用前面提到的向量能力。

• Function - 函数框架。

• Operators - 算子，比如 SQL 数据库里的 TableScan（全表扫描），Project （映射），Filter（过滤），Aggregation（聚合），Order （排序），Join（连接）。

• IO - 和 IO 系统对接。

• Resource Management - 计算资源管理。

Velox 作为一个执行引擎，需要效率优先，兼顾工程，所以采用了 C++ 来实现。其实 Velox 也可以简单理解成数据库引擎里的 C++ STL 库，而就像 STL 库之于 C++ 一样，Velox 之于数据库引擎也有里程碑式的意义。

要理解这点，我们要看一下数据库引擎的架构，处理一条 Query 的流程大致是 Language Frontend -> IR -> Optimizer -> Execution Engine -> Execution Runtime。其中 Language Frontend + IR 大家已经都统一到了 SQL，而在 SQL 方言里，也有逐渐收敛到 PostgreSQL 的趋势，所以数据库引擎的前端已经基本标准化了。而一旦 Velox 把 Execution Engine 标准化，那么剩下的就是 Optimizer 和 Execution Runtime，这两块也正是引擎之间真正的差异化点。

物理世界中最接近数据库的应该是 F1 ，我们也就用 F1 来个类比。

Language Frontend + IR 相当于驾驶指令集；Optimizer 相当于策略，比如进站两停还是三停，用干胎还是雨胎；Execution Engine 相当于车身材料，齿轮，尾翼 ，传动轴等整套传动系统；Execution Runtime 相当于悬挂硬度，齿轮比等的调校；不同的 F1 赛道 + 天气这些环境因素则相当于不同的业务场景。

在有了标准化的 Velox 之后等于是大家装车的部件都是一样的，研发数据库引擎就像是把 F1 比赛的竞争简化成了「策略 (Optimizer）+ 调校（Execution Runtime)」 和「赛道+天气（业务场景）」的适配。这带来的结果自然是各个车队拼命卷前面两块，每条赛道的最快圈速被不断刷新。

当然现在市面上主流的数据库都拥有了自己的 Execution Engine，要替换成 Velox 的可能性并不大，但新的数据库项目就很有可能采用 Velox 了。毕竟有了它，像给数据库加入向量能力，大概花几周就搞定了，就像车队不需要自己做风洞试验去研发尾翼，只要研究如何把现成的尾翼安装到合适的位置。

年度功能 - ReadySet

ReadySet 是创始人 Jon Gjengset 基于他在 MIT 的博士论文 「Partial State in Dataflow-Based Materialized Views」创立的公司。简单来说，就是做了一层 Cache，但和 Redis 这种专门的缓存数据库不同的是，ReadySet 是和 MySQL / PostgreSQL 协议兼容的，所以对于应用来说，是完全透明的，所以也可以把 ReadySet 看作 MySQL / PostgreSQL 本身的一部分。有了 ReadySet，应用就不需要写额外的 Cache 处理逻辑，这可不得了，一下子解决了计算机科学两大难题之一的缓存失效（准确的说不完全是，但差不多能覆盖 95% 的场景）。

ReadySet 虽然是一个独立产品，但是从它的形态上归类为数据库的一个功能点更为合适。事实上 PlanetScale 就借鉴了 ReadySet 的思路，给自己的数据库加上了 PlanetScale Boost 的功能。

ReadySet 相关的资料很全，ReadSet 的代码开源在了 https://github.com/readysettech/readyset，如果技术人员想快速了解大致实现，推荐阅读 How PlanetScale Boost serves your SQL queries instantly (https://planetscale.com/blog/how-planetscale-boost-serves-your-sql-queries-instantly)。而对于非技术人员来说，通过 Jon 博士论文附录里图书馆的类比，也能知道个大概。

ReadySet 是近两年学术界到工业界眼前一亮的成果转化，估计接下来其他数据库都会相继引入这套技术方案。

年度数据库 - Neon

从产品侧来说，Neon 是 PostgreSQL 版的 PlanetScale，一样把引擎开源，一样主打 Serverless 和 Developer Workflow，但从技术侧来说，Neon 采用的是更加现代的架构，他的存储引擎在顶层设计上就考虑了 Branching 这样的功能点 （也被作为它产品的主要差异化点，专门放在了网站一级页面）。

Neon 的另一个亮点是它的上手体验，是试下来最快能完成从创建到连接上数据库的整个流程：

像 PlanetScale 这样基于分布式中间件的数据库还会存在和原生 MySQL 兼容的问题，而 Neon 的存算分离架构则完全没有这个问题，Server 层直接用的就是 PostgreSQL 本身的 Server 层。Neon 的另外一个优势是它是基于 PostgreSQL 的，这使得它在企业场景的上限会高许多。另外 Neon 虽然目前针对的是 TP 场景，但它的架构结合 PostgreSQL 本身的扩展性，也有拓展到 AP，时序数据库这些的空间。

其他数据库盘点

Google AlloyDB

Google Cloud 今年发布了同样基于 PostgreSQL 协议的 AlloyDB，整体架构是 AWS Aurora 的升级版。AlloyDB 采取了和 Aurora, Neon 类似的基于 WAL 的存算分离架构，不过 AlloyDB 在 TP 基础上先点了 AP 的技能树，而不是像 Neon 点了 Developer Workflow。AP 的场景确实更为广阔，但市面上 HTAP 数据库也有几个了，而且 AlloyDB 又是闭源的，所以在前面还是把年度数据库给了更具原创性和开放度的 Neon。

在 AlloyDB 推出之前，Google Cloud 拥有的 TP/AP 数据库产品线：

• 原生 (vanilla) OLTP MySQL, PostgreSQL, SQL Server - Cloud SQL。

• 云原生数仓 OLAP - BigQuery。

• 云原生分布式 OLTP 数据库 - Cloud Spanner。

而 AlloyDB 和这三者的能力都有交集，就像

确实是 Alloy (合金）嘛。

Snowflake Unistore

云原生数仓的王者也卷入 HTAP 赛道，之前的几家都是从 TP 切入 AP，Snowflake 应该是第一个从 AP 切入 TP 的数据库。Snowflake 做 HTAP 有几个优势：

1. 渠道（Distribution）。

2. 本身的产品力和整套平台。

3. AP 切 TP 更匹配大客户画像，愿意给 100 分 AP + 60 分 TP 买单的公司比 60 分 AP + 100 分 TP 的公司要多不少。

但从 AP 切同样也面临挑战：

1. 公司总是先有 TP 系统，之后业务规模上去后再引入 AP 系统。一开始很难去说服研发团队 / DBA 用一个数仓出身的数据库来接管在线业务，何况 Snowflake 又卖的那么贵。

2. 如果后续想再换 TP 系统也很难，TP 是 AP 的上游，通常都是上游强势。而且 TP 是在线系统，AP 是离线系统（排除极少量反向 ETL），换 TP 相当于给飞行中的飞机换引擎。而想推动 TP 更换 Unistore 的一定是大数据团队，但单纯站在 TP 团队的角度，缺少能够打动他们更换成 Unistore 的价值点。

所以对于研发组织来说，在畅想 Unistore 能带来的生产力提升前，先要评估是否有配套的生产关系保障。理想中，AP + TP 数据放在一起，组织间的数据更加通畅了。但现实中却很可能是：

1. TP 数据库团队不掰应 Unistore 这样 AP 出生的混血系统（就像 AP 团队不掰应 TP 出生的混血系统）。

2. AP 团队利用 Unistore 拓展 TP 场景，和 TP 团队开始打架，重复建设。

SQLite

如果只是扫了一眼 Richard Hipp 博士的 2022 Recap (https://sqlite.org/forum/forumpost/df285a4182688791)，可能会觉得是挺平常的一年。

其实 22 年 SQLite 的生态又往前迈了一大步，社区中最大的演进是 SQLite WASM 成为了官方项目。

商业方面，Cloudflare 推出了基于 SQLite 的 D1，搭配它的 Cloudflare Worker。

Litestream 的作者 Ben Johnson 加入了 fly.io，随后又推出了开源的 LiteFS。

LiteFS 是一个专为 SQLite 构建的，基于 FUSE 的文件系统。有了 LiteFS，你只要花上 10 分钟，就可以搭好一个全球分布式 SQLite。

AP 版 SQLite  - DuckDB 22 年同样发展迅速。

基于 DuckDB 的商业公司 MotherDuck 聚拢了一支全明星团队，在 22 年的大环境下，还能年底一上来就融了 4750 万美金。

来展望一下 SQLite 基础技术的演进路线：

1. SQLite + WASM，SQLite in your Browser (2022）

2. SQLite + WASM + LiteFS，Globally Distributed SQLite in your Browser（2023）

3. SQLite + WASM + LiteFS + DuckDB ，Globally Distributed HTAP in your Browser（2023/2024）

而在基础技术演进的过程中，行业也会去探索杀手级解决方案。在「MotherDuck，从 SQLite 走向数据届的 Docker」里展望过 MotherDuck 可以成为数据届的 Docker。更广义的讲，应该是以 SQLite 或者类似架构 (比如 DuckDB）为底座的方案能成为数据届的 Docker。Datasette (https://datasette.io/) 这个项目已经展现了这方面的可能性，只是还需要更好的产品化。

PostgreSQL

PostgreSQL 22 年虽然在 DB-Engines 年度排名里下降了一位，排在 Snowflake，BigQuery 之后，位居第三，但还是所有开源数据里表现最好的。而且在 Stack Overflow 的年度最喜爱数据库评选中，PostgreSQL 还拿下了第一。

另外从职业开发者的使用比例看，PostgreSQL 这次还略微超过了 MySQL。

前面提到的新数据库 AlloyDB，Neon 都属于 PG 阵营的，就连 Snowflake 的语法也大多继承自 PG。另外像 Supabase，Render 这些提供 PostgreSQL 服务的 PaaS 平台也在继续蓬勃发展；AWS 在 re:Invent 上也推出了 针对 PG 的 Trusted Language Extensions (TLE)。

还是去年讲 PostgreSQL 的那条公式：

PostgreSQL = MySQL + 穷人版 (ClickHouse + MongoDB + Elasticsearch + InfluxDB) + Geospatial + Multi-tenancy

PostgreSQL 有出色的架构，严谨的代码，独立而专业的社区，时间是站在 PostgreSQL 的这边。就是希望 17 年提的 64 bit XID 可以早日合进主干 🫠

数据库趋势

应用开发者

21 年 PlanetScale 从 Vitess 托管数据库转型到面向应用开发者主打 Developer Workflow，22 年继续做文章，相继推出了 Revert 以及类似 ReadySet 的 Boost。

当然今年 PlanetScale 迎来了一个知音/对手，同样主打 Developer Workflow 的 Neon。两者的宣言也很类似

最主要的区别一个是 MySQL 系，一个是 PostgreSQL 系。看来 MySQL 和 PostgreSQL 的相爱相杀是没完没了了，从原生 MySQL vs PostgreSQL，到分布式的 TiDB vs CockroachDB，再到云原生的 AWS Aurora vs GCP AlloyDB，现在又有主打开发者工作流的 PlanetScale vs Neon。

工具

22 年 AWS re:Invent 2022 数据线最重磅的发布并不是数据库，而是 DataZone - A data management service to catalog, discover, share and govern data。

数据库引擎功能日趋强大，整个数据栈愈发复杂，就需要更好的方向盘，导航仪，刹车板这一套驾驶系统来驾驭他们。引擎厂商素有收购数据库客户端工具的传统，MongoDB 收购 Compass，Databricks 收购 Redash，还有 22 年 ClickHouse 收购 Arctype。但整体上还缺少像 Oracle Enterprise Manager, SQL Developer, SQL Server Management Studio 这样全面的工具。

所以相对于引擎市场的饱和，数据库工具赛道反而有更多的空间。公有云大厂要通过 DataZone 这样的服务打通整条数据产品线的任督二脉；数据库厂商要打造自己的数据库 IDE，提供一站式的数据库使用体验；而像 Bytebase 这样的产品，则是让团队能用一套统一的数据库开发流程，完成云上云下，不同的云，不同的数据库种类，各种各样的数据库开发活动。

融合

融合的好处是减少异构系统因为数据同步带来的延迟，不一致，打破数据之间的孤岛。最理想的情况，最上游 TP 数据库一个变更， CI 的运行报告能反馈对于 BI 报表的影响，甚至能评估出 reverse-ETL 链路对于自己的影响，就像扔出一个回旋镖，转了一圈还能回到自己手上。

当前数据库技术正在融合，SQL 语言统一，执行引擎统一，基于日志的存储统一，这使得数据库引擎可以在一套大的框架下，去处理不同场景。之前提到的 PostgreSQL，通过插件的组装，已经可以基本承载各种业务场景。云上我们已经看到了 AP + TP 的 HTAP，AP + Lake 的湖仓一体，那这三者融合在一起的 ALT 还会遥远么？

AI 智能化

2019 年前后，因为当时 Oracle 一直在推 Autonomous Database（自治数据库）的概念，于是在国庆期间阅读了相关领域的论文和产品资料，最后得出的结论是这东西还不成熟，建议团队应该投入更多在 HTAP 上（不过最后资源还是倾斜到了自治数据库，毕竟 AI 能讲出一个更好的故事🫠）。从市场角度，AI 能画出很多好的故事，但即使到了今天，我对 AI 在数据库引擎层的实际应用还是持保留态度，工程能力而不是 AI 能力依然是解决当下数据库痛点的瓶颈：

• 如何基于云底座实现扎实的 serverless 形态，存算分离，spot instance，tiered storage，给云上的多租户提供高性价比的数据库服务。

• 如何把 TP，AP 甚至数据湖结合在一起。

• 如何让数据库变更的开发工作流更接近代码变更的工作流。

基于 GPT-3 这样的技术，可以通过自然语言快速生成 SQL 语句，这确实比当年 AppleScript 有局限性的自然语言有了质的飞跃。但是从对话场景 (conversational) 生成近似的结果， 到优化器这样，每次都需要确定性结果的场景，还有很长的一段路。而相比做一个 AI 数据库，更具可操作性的是去做一个更好地为 AI 场景服务的数据库，把从 TP，AP，Lake，ETL，reverse-ETL 的整条数据链路打通，依赖类似 DataZone 这样的平台治理数据，再通过扩展 SQL 语法去便捷地使用 AI/ML 能力。

22 年的预测打分

我们来回顾一下「千帆竞速，各领江湖 | 万字长文回顾 2021 年数据库行业」里做的预测。

PlanetScale 会有很好的发展，Vercel + PlanetScale 的 VP 组合会给开发 workflow 带来一个新的 paradigm shift，尤其吸引到很多的前端和全栈开发者。

50% 准确。PlanetScale 市场宣传做得很棒，但整体没有达到席卷开发者，带来范式转移（Paradigm Shift） 的程度。相比而言，接下来也更看好 Vercel + Neon 的组合。

会有新的数据库问世，主打点也会是开发 workflow。

100% 准确。前面提到的 Neon，还有年末推出的 Xata，主打点都是 development workflow。

会出现做 ClickHouse 工具的初创公司，并获得不菲融资。

50% 准确。没有出现新的初创公司，但 ClickHouse Inc. 收购了 Arctype 作为自己的客户端。

Firebolt 会成为史上融资速度最快的数据库公司

0%。还好没去买股票。

PostgreSQL 会拿下 2022 DB-Engine of the year

0%。第一名是 Snowflake，PG 以微弱劣势屈居 BigQuery 之后，排第三。

会诞生基于 SQLite 的杀手级解决方案。

30%。Cloudflare D1，LiteFS,  官方 SQLite WASM 都算亮点，但去年这些都还是技术方案，解决方案层面的还没有看到。

开源数据库应用开发场景，会出现一款重量级工具产品。

20%。这条其实是 Bytebase 自己认领的 KPI。一年下来，Bytebase 被 CNCF Landscape 收录为这个领域里唯一的产品，但离成为约定俗成的工具，还需 23 年继续努力。

总体准确率 35.7%。(๑¯∀¯๑) 

23 年的预测

• OpenAI 的技术会接入微软的 SQL Server 以及 Power BI，不管接入程度是多少，至少产品宣传上会重点强调。

• Snowflake 会推出自己的 BI 产品，也可能进行 BI 方向的收购。

• Snowflake Unistore 更进一步，把数据湖 (Data Lake）也纳入进来。从 Hybrid Table 到 Hyper Table？希望 TimescaleDB 不要介意吧 🙃

• 去年在展望 SQLite 发展的时候，一念之差，没有点名 Cloudflare。今年就直接点名一下 fly.io，正式推出 Globally Distributed SQLite in your Browser 的产品。

• DB-Engine 的年度前三，1）Snowflake  2）PostgreSQL  3）SQLite。看去年 Snowflake 的领先优势，今年的第一也没有什么悬念，所以就猜前三吧。

• 会有新的数据库问世，主打点是处理 AI/ML 场景，会采用 PostgreSQL 协议。

• 开源数据库应用开发场景，会出现一款重量级工具产品 （再接再厉吧 Bytebase，也只有指望你了 💪）。

最后的总结

苍狼和白鹿是蒙古传说中的两位民族始祖，分别象征了扩张的野心和强悍的生命，而扩张和生存也正是接下来几年数据库公司们的主题。一方面数据库技术正在融合，厂商们很容易涉足彼此的领域，大玩家会吞并小玩家。另一方面大家一边在激烈的数据库赛道上互相竞争，一边还要穿越当下的周期。

当然从 50 年前给 IBM 大型机配的几套 System R，到现在跑在各种 App，IoT 设备上的亿万 SQLite，经历几度的经济周期，数据库总是向前。艰难的 2022 年之下，行业依然涌现了不少的创新，期待这些创新能在 23 年结合业务场景打磨出更好的解决方案。就像 ReadySet 创始人 Jon 在博士论文里的致谢：

The appendix that explains Noria in simpler terms would never have existed were it not for my mom’s endless desire to understand what I was working on combined with her lack of interest in listening to long-winded technical descriptions.

在反复的提炼中，找到最佳的隐喻。

---

---

作者 22 年其他的数据库相关文章：