七周七数据库（2025年）
作者：Matt Blewitt，原文：七周七数据库（2025年）
译者：冯若航，数据库老司机，云计算泥石流
https://matt.blwt.io/post/7-databases-in-7-weeks-for-2025/
长期以来，我一直在运营数据库即服务（Databases-as-a-Service），这个领域总有新鲜事物需要跟进 —— 新技术、解决问题的不同方法，更别提大学里不断涌现的研究成果了。展望2025年，考虑花一周时间深入了解以下每项数据库技术吧。
前言
这不是 “七大最佳数据库” 之类的文章，更不是给报菜单念书名式的列表做铺垫——这里只是我认为值得你花一周左右时间认真研究的七个数据库。你可能会问，“为什么不选Neo4j、MongoDB、MySQL / Vitess 或者其他数据库呢？”答案大多是：我觉得它们没啥意思。同时，我也不会涉及 Kafka 或其他类似的流数据服务——它们确实值得你花时间学习，但不在本文讨论范围内。
目录
1. PostgreSQL
默认数据库
“一切皆用 Postgres” 几乎成了一个梗，原因很简单。PostgreSQL 是 枯燥技术 的巅峰之作，当你需要 客户端-服务器 模型的数据库时，它应该是你的首选。PG 遵循ACID原则，拥有丰富的复制方法 —— 包括物理和逻辑复制—— 并且在所有主要供应商中都有极好的支持。
然而，我最喜欢 Postgres 功能是 扩展。在这一点上，Postgres 展现出了其他数据库难以企及的生命力。几乎你想要的功能都有相应的扩展——AGE支持图数据结构和Cypher查询语言，TimescaleDB支持时间序列工作负载，Hydra Columnar提供了另一种列式存储引擎，等等。如果你有兴趣亲自尝试，我最近写了一篇关于编写扩展的文章。
正因为如此，Postgres 作为一个优秀的 “默认” 数据库熠熠生辉，我们还看到越来越多的非 Postgres 服务使用 Postgres 线缆协议 作为通用的七层协议，以提供客户端兼容性。拥有丰富的生态系统、合理的默认行为，甚至可以用 Wasm 跑在浏览器中，这使得它成为一个值得深入理解的数据库。
花一周时间了解 Postgres 的各种可能性，同时也了解它的一些限制 ——MVCC 可能有些任性。用你最喜欢的编程语言实现一个简单的CRUD应用程序，甚至可以尝试构建一个 Postgres 扩展。
2. SQLite
本地优先数据库
离开客户端-服务器模型，我们绕道进入 “嵌入式” 数据库，首先介绍 SQLite。我将其称为“本地优先”数据库，因为SQLite数据库与应用程序直接共存。一个更著名的例子是WhatsApp，它将聊天记录存储为设备上的本地 SQLite 数据库。Signal 也是如此。
除此之外，我们开始看到更多 SQLite 的创新玩法，而不仅仅是将其当成一个本地ACID数据库。像 Litestream 这样的工具提供了流式备份的能力， LiteFS 提供了分布式访问的能力，这让我们可以设计出更有趣的拓扑架构。像CR-SQLite 这样的扩展允许使用 CRDTs，以避免在合并变更集时需要冲突解决，正如 Corrosion 的例子一样。
得益于Ruby on Rails 8.0，SQLite也迎来了一个小型复兴 ——37signals 全面投入 SQLite，构建了一系列 Rails 模块，如 Solid Queue，并通过database.yml配置 Rails 以操作多个 SQLite 数据库。Bluesky 使用SQLite作为个人数据服务器 —— 每个用户都有自己的 SQLite 数据库。
花一周时间使用 SQLite ，探索一下本地优先架构，你甚至可以研究下是否能将使用 Postgres 的客户端-服务器模型迁移到只使用 SQLite 的模式上。
3. DuckDB
万能查询数据库
接下来是另一个嵌入式数据库，DuckDB。与SQLite类似，DuckDB旨在成为一个内嵌于进程的数据库系统，但更侧重于在线分析处理（OLAP）而非在线事务处理（OLTP）。
DuckDB 的亮点在于它作为一个“万能查询”数据库，使用 SQL 作为首选方言。它可以原生地从 CSV、TSV、JSON ，甚至像 Parquet 这样的格式中导入数据 —— 看看 DuckDB的数据源列表 支持的数据源列表吧！这赋予了它极大的灵活性 —— 不妨看看 查询Bluesky火焰管道的这个示例。
与 Postgres 类似，DuckDB 也有 扩展，尽管生态系统没有那么丰富 —— 毕竟DuckDB还相对年轻。许多社区贡献的扩展可以在社区扩展列表中找到，我特别喜欢gsheets。
花一周时间使用DuckDB进行一些数据分析和处理——无论是通过 Python Notebook，还是像Evidence这样的工具，甚至看看它如何与SQLite的“本地优先”方法结合，将SQLite数据库的分析查询卸载到DuckDB，毕竟 DuckDB 也可以读取SQLite数据。
4. ClickHouse
列式数据库
离开嵌入式数据库领域，但继续看看分析领域，我们会遇上 ClickHouse。如果我只能选择两种数据库，我会非常乐意只用 Postgres 和 ClickHouse——前者用于OLTP，后者用于OLAP。
ClickHouse 专注于分析工作负载，并且通过横向扩展和分片存储，支持非常高的摄取率。它还支持分层存储，允许你将“热”数据和“冷”数据分开—— GitLab对此有相当详尽的文档。
当你需要在一个 DuckDB 吃不下的大数据集上运行分析查询，或者需要 “实时” 分析时，ClickHouse 会有优势。关于这些数据集已经有很多 “Benchmarketing”（打榜营销）了，所以我就不再赘述了。
我建议你了解 ClickHouse 的另一个原因是它的操作体验极佳 —— 部署、扩展、备份等都有详尽的文档——甚至包括设置 合适的 CPU Governor。
花一周时间探索一些更大的分析数据集，或者将上面 DuckDB 分析转换为 ClickHouse 部署。ClickHouse 还有一个嵌入式版本 —— chDB—— 可以提供更直接的对比。
5. FoundationDB
分层数据库
现在我们进入了这个列表中的 “脑洞大开” 部分，FoundationDB 登场。可以说，FoundationDB 不是一个数据库，而是数据库的基础组件。被 Apple、Snowflake 和 Tigris Data 等公司用于生产环境，FoundationDB 值得你花点时间，因为它在键值存储世界中相当独特。
是的，它是一个有序的键值存储，但这并不是它有趣的点。乍看它有一些奇特的限制——例如事务不能影响超过10MB 以上的数据，事务首次读取后必须在五秒内结束。但正如他们所说，限制让我们自由。通过施加这些限制，它可以在非常大的规模上实现完整的 ACID 事务—— 我知道有超过 100 TiB 的集群在运行。
FoundationDB 针对特定的工作负载而设计，并使用仿真方法试进行了广泛地测试，这种测试方法被其他技术采纳，包括本列表中的另一个数据库和由一些前 FoundationDB 成员创立的 Antithesis。关于这一部分请参阅 Tyler Neely 和 PhilEaton 的相关笔记。
如前所述，FoundationDB 具有一些非常特定的语义，需要一些时间来适应——他们的 特性 文档和 反特性 （不打算在数据库中提供的功能）文档值得去了解，以理解他们试图解决的问题。
但为什么它是“分层”数据库？因为它提出了分层的概念，而不是选择将存储引擎与数据模型耦合在一起，而是设计了一个足够灵活的存储引擎，可以将其功能重新映射到不同的层面上。Tigris Data有一篇关于构建此类层的优秀文章，FoundationDB 组织还有一些示例，如 记录层 和 文档层。
花一周时间浏览 教程，思考如何使用FoundationDB替代像 RocksDB 这样的数据库。也许可以看看一些 设计方案 并阅读 论文。
6. TigerBeetle
极致正确数据库
继确定性仿真测试之后，TigerBeetle 打破了先前数据库的模式，因为它明确表示自己 不是一个通用数据库 —— 它完全专注于金融事务场景。
为什么值得一看？单一用途的数据库很少见，而像 TigerBeetle 这样痴迷于正确性的数据库更是稀有，尤其是考虑到它是开源的。它们包含了从 NASA的十律 和 协议感知恢复 到严格的串行化和 Direct I/O 以避免内核页面缓存问题，这一切的一切真是 非常 令人印象深刻——看看他们的 安全文档 和他们称之为 Tiger Style 的编程方法 吧！
另一个有趣的点是，TigerBeetle是用 Zig 编写的——这是一门相对新兴的系统编程语言，但显然与 TigerBeetle 团队的目标非常契合。
花一周时间在本地部署的 TigerBeetle 中建模你的金融账户——按照 快速入门 操作，并看看系统架构文档，了解如何将其与上述更通用的数据库结合使用。
7. CockroachDB
全球分布数据库
最后，我们回到了起点。在最后一个位置上，我有点纠结。我最初的想法是 Valkey，但 FoundationDB 已经满足了键值存储的需求。我还考虑过图数据库，或者像 ScyllaDB 或 Cassandra 这样的数据库。我还考虑过 DynamoDB，但无法本地/免费运行让我打消了这个想法。
最终，我决定以一个全球分布式数据库结束 —— CockroachDB。它兼容 Postgres 线缆协议，并继承了前面讨论的一些有趣特性——大规模横向扩展、强一致性——还拥有自己的一些有趣功能。
CockroachDB 实现了跨多个地理区域的数据库伸缩能力，生态位与 Google Spanner 系统重叠，但 Spanner 依赖原子钟和GPS时钟进行极其精确的时间同步，然而普通硬件没有这样的奢侈配置，因此 CockroachDB 有一些巧妙的解决方案，通过重试或延迟读取以应对 NTP 时钟同步延迟，节点之间还会比较时钟漂移，如果超过最大偏移量则会终止成员。
CockroachDB 的另一个有趣特性是如何使用多区域配置，包括表的本地性，根据你想要的读写利弊权衡提供不同的选项。花一周时间在你选择的语言和框架中重新实现 movr 示例吧。
总结
我们探索了许多不同的数据库，这些数据库都被地球上一些最大的公司在生产环境中使用，希望这能让你接触到一些之前不熟悉的技术。带着这些知识，去解决有趣的问题吧！
老冯评论
在 2013 年有一本书叫《七周七数据库》。那本书介绍了当时的 7 种 “新生（或者重生）” 的数据库技术，给我留下了印象。12 年后，这个系列又开始有更新了。
回头看看当年的七数据库，除了原本的 “锤子” PostgreSQL 还在，其他的数据库都已经物是人非了。而 PostgreSQL 已经从 “锤子” 成为了 “枯燥数据库之王” —— 成为了不会翻车的 “默认数据库”。
在这个列表中的数据库，基本都是我已经实践过或者感兴趣/有好感的对象。当然 ClickHouse 除外，CK 不错，但我觉得 DuckDB 以及其与 PostgreSQL 的组合有潜力把 CK 给拱翻，再加上是 MySQL 协议兼容生态，所以对它确实没有什么兴趣。如果让我来设计这份名单，我大概会把 CK 换成 Supabase 或 Neon 中的一个。
我认为作者非常精准的把握了数据库技术发展的趋势，我高度赞同他对数据库技术的选择。实际上在这七个数据库中，我已经深入涉猎了其中三个。Pigsty 本身是一个高可用的 PostgreSQL 发行版，里面也整合了 DuckDB，以及 DuckDB 缝合的PG扩展。Tigerbettle 我也做好了 RPM/DEB 包，作为专业版中默认下载的金融事务专用数据库。
另外两个数据库，正在我的整合 TODOLIST 中，SQLite 除了 FDW，下一步就是把 ElectricSQL 给弄进来；提供本地 PG 与远端 SQLite / PGLite 的同步能力；CockroachDB 则一直在我的 TODOLIST 中，准备一有空闲就做个部署支持。FoundationDB 是我感兴趣的对象，下一个我愿意花时间深入研究的数据库不出意料会是这个。
总的来说，我认为这些技术代表着领域前沿的发展趋势。如果让我设想一下十年后的格局，那么大概会是这样的： FoundationDB，TigerBeetle，CockRoachDB 能有自己的小众基本盘生态位。DuckDB 大概会在分析领域大放异彩，SQLite 会在本地优先的端侧继续攻城略地，而 PostgreSQL 会从 “默认数据库” 变成无处不在的的 “Linux 内核”，数据库领域的主旋律变成 Neon，Supabase，Vercel，RDS，Pigsty 这样 PostgreSQL 发行版竞争的战场。
毕竟，PostgreSQL 吞噬数据库世界可不只是说说而已，PostgreSQL生态的公司几乎拿光了这两年资本市场数据库领域的钱，早就有无数真金白银用脚投票押注上去了。当然，未来到底如何，还是让我们拭目以待吧。