DuckDB

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？ 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 把旧版本直接放主表的设计，让「时间旅行」「闪回查询」这类能力成为可能。 ...