同一个「存数据」的需求，为什么长出了三种完全不同的数据库？

Tue, 04 Aug 2026 11:53:09 +0800

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？

PostgreSQL、Redis、DuckDB——三者都管自己叫「数据库」，但架构几乎没有一处相同。本文从一个问题出发：为什么「存数据」这一件事，需要三种截然不同的答案？

先说个真实感受：新人问我「该用什么数据库」时，我最怕听到的是「就……存点数据」。因为「存数据」这个需求背后，至少藏着三个互相矛盾的目标：要快（延迟）、要对（一致性）、要能算（分析吞吐）。这三个目标在物理层面就是打架的，所以业界长出了三种完全不同形态的数据库，各自押注一个目标。

这篇拿 PostgreSQL（75K+ Star 里的常青树）、Redis（75K Star）、DuckDB（40K Star）当样本——它们恰好是三条路线的教科书级代表。

三种数据库，三种「世界观」

	PostgreSQL	Redis	DuckDB
一句话定位	数据的基础设施	远程数据结构接口	SQLite for Analytics
押注的目标	正确性 > 性能	延迟 > 一切	分析吞吐 + 零部署
数据在哪	磁盘（缓冲进内存）	内存	就在文件里（CSV/Parquet/S3）
并发模型	多进程、MVCC 多版本	单线程事件循环	单写者、Morsel 并行读
典型场景	金融、ERP、订单	缓存、会话、排行榜、限流	数据科学家本地跑 SQL 分析

注意：这三行的每一列差异都不是「实现细节」，全是世界观分歧。往下看。

PostgreSQL：把「正确」放在所有选项的前面

PostgreSQL 从 1986 年 Berkeley 的学术项目走到今天，38 年没死，靠的不是快——它从来不追求最快。它的护城河是正确性和可信度的复利。

几个能看出价值观的设计：

1. Process-per-connection：每个连接一个独立进程。 MySQL（InnoDB）用线程池，PG 用进程。进程更重、启动更慢，但一个连接崩了不会带走别人——内存隔离是操作系统保证的，不是代码纪律保证的。这是「可靠性高于便利」的字面体现。

2. MVCC 的代价是 VACUUM。 读写互不阻塞的代价是旧版本数据堆在表里，得靠 VACUUM 回收。很多人骂 VACUUM 烦，但这笔交易是明码标价的：读永远不阻塞写、写永远不阻塞读，换来的运维成本。对比 MySQL undo log 的回收方式，各有取舍，但 PG 把旧版本直接放主表的设计，让「时间旅行」「闪回查询」这类能力成为可能。

DuckDB on FXIO 技术博客

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？

三种数据库，三种「世界观」

PostgreSQL：把「正确」放在所有选项的前面