近期在 Hacker News 的讨论中，关于 OrioleDB 和 Neon 的差异存在一些混淆，二者乍看相似，都宣称是“下一代 Postgres”且都支持云原生存储。

核心差异

• OrioleDB：是 Postgres 扩展，实现了表访问方法以替代默认存储方法（堆），提供基于 UNDO 的 MVCC、IO 友好的写时复制检查点及基于 squizzled 指针的有效共享内存缓存层等关键特征。

• Neon：使用默认表访问方法（堆）并替换存储层，WAL 写入守护者，块从对象存储支持的页面服务器读取，提供即时分支和缩至零能力。

  架构比较

• CPU 可扩展性：OrioleDB 通过引入新的基于 squizzled 指针的共享内存缓存层和行级预写日志消除了 PostgreSQL 缓冲区管理器和 WAL 写入器的可扩展性瓶颈，可处理大型虚拟机上的高强度读写工作负载；Neon 计算节点与原生 PostgreSQL 大致具有相同的可扩展性，但允许即时添加连接到同一多租户存储的更多只读计算节点。
• IO 可扩展性：OrioleDB 实现写时复制检查点，提高了写入的局部性，其行级 WAL 因体积小而节省了写入 IOPS；Neon 实现了可潜在扩展到无限的分布式网络存储层，但缺点是网络延迟，与快速本地 NVMe 相比可能非常显著。

• VACUUM 和数据膨胀：OrioleDB 实现了块级和行级 UNDO 日志，无需常规 VACUUM 操作，UNDO 日志与稀疏页面的自动合并相结合，最大限度地降低了膨胀风险；Neon 在主计算节点上使用原生 PostgreSQL VACUUM，多租户存储的可扩展性减轻了 VACUUM 的缺点和膨胀风险。

  存储和计算分离

• Neon：从一开始就围绕硬拆分设计，无状态（除节点共享内存外）计算节点将 WAL 流式传输到守护者的法定人数，并通过从页面服务器拉取 8KB 页面来提供读取服务，页面服务器将热块保存在 SSD 中，但将冷层推送到 S3 兼容的对象存储，由于计算没有持久状态，可在数秒内启动、暂停、克隆或丢弃，实现即时分支、缩至零和一键读取副本等功能，存储层是多租户的并在多个可用区复制数据。

• OrioleDB：也可利用分布式 S3 对象存储，在实验模式下可自动将冷数据驱逐到 S3，在检查点时将热存储与 S3 同步，并将 WAL 文件归档到 S3，本地存储充当 S3 中存储数据的缓存，多个副本可连接到相同的 S3 存储（开发中），在数据库无负载时可无缝缩至零。

  生产准备就绪

• OrioleDB：当前处于公共 beta10 阶段，仍不建议用于生产环境；需要修补的 PostgreSQL 17 版本，核心补丁正在审查中但尚未合并；在 GitHub 上提供社区支持，Supabase 在实验项目中提供 OrioleDB。

• Neon：自 2024 年 8 月在 AWS 上全面可用，自 2025 年 5 月 14 日在 Azure 上全面可用（原生集成）；计算节点运行修补的 PostgreSQL（增强的 WAL 流协议、远程存储钩子、调整的 fsync 设置），补丁集由 Neon 维护并在每个主要 PostgreSQL 版本上重新设置基础，在商业/企业层级提供 24×7 支持和 99.95%的可用性 SLA，有公共状态页面和多区域部署。

  结论

  PostgreSQL 的灵活性和可扩展性一直是其优势，OrioleDB 和 Neon 在不同方向推动这些特性，OrioleDB 适用于最关注单节点原始吞吐量、可预测延迟以及免受 VACUUM 和膨胀影响的情况；Neon 在需要免操作、即时分支和弹性计算时表现出色。两个项目都发展迅速，关注 OrioleDB 的 S3 模式进入全面可用以及自托管 Neon 集群的成熟。2026 年部署的 Postgres 可能与今天所知的非常不同。