博客

和 PostgreSQL 的二十年·6 篇,共 7

为什么我二十年没有换掉它

Cover Image for 为什么我二十年没有换掉它

有人问过我,为什么一直用 PostgreSQL。

我想了一下,发现这个问题没有一个干净的答案。不是因为它最快,不是因为它最流行,不是因为公司规定,也不是因为没用过别的。

答案散落在前面五篇里,我试着把它收拢一下。


2009 年,我有一次机会加入数据仓库团队。

总公司派来的总经理,自己也是技术出身,专门来问我有没有意愿。我当场拒绝了。理由是:数据仓库多无聊,哪有做 Web 业务系统带劲。

那个团队后来发展得很好。

命运呐。

如果当时答应了,第一次做数据分析就不是 2016 年骑着一台 Mac 笔记本磕磕绊绊地跑,而是在一个有资源、有方向、有人带的环境里。少走多少弯路,我不知道。

但弯路也是路。那些绕过来的经历,让我对很多事情的理解比直线走过来的人多了一些角度。不一定更好,但确实是自己的。


最近在研究美股,看 neocloud 赛道,发现 NBIS 背后的团队是 ClickHouse 的原班人马。

我第一次用 ClickHouse,是在那家金融公司,把实时计费这条线从 PostgreSQL 里抽出来,交给它来做。那是工作层面的选择,看的是性能和生态。

现在看 NBIS,看的是投资判断,看的是团队背景、技术壁垒、市场空间。

同一批人,同一个技术,在我的人生里出现了两次,用途完全不同。

数据库用多了,你会开始理解一件事:技术不只是工具,它是你认识世界的一套语言。 用什么工具,你就能看懂什么东西,看不懂什么东西。

PostgreSQL 用了二十年,让我能在某些角落里,比别人多看一层。


这二十年里,我见过很多"更好的方案"。

分布式数据库,存算分离,NewSQL,各种声称要替代传统关系型数据库的东西。有些活下来了,有些消失了,有些找到了自己的位置。PostgreSQL 还在,而且越来越好。

不是因为它没有缺点。

它的并发写入在极端场景下不如一些专用系统。VACUUM 机制在高频更新的表上需要认真调优,否则会有麻烦。大规模 upsert 代价高昂——第五篇里那个 48 小时的故事就是真实的。replication lag 在某些场景下是个需要认真对待的问题。

这些都是真实的限制,不是偏见。

但二十年下来,我学到的一件事是:没有没有缺点的工具,只有适不适合当下的工具。 PostgreSQL 的缺点我都知道,我知道在哪里它会让你为难,也知道在哪里它会让你如鱼得水。这种熟悉本身,就是一种很难转移的资产。


前几年整个行业往复杂走——微服务、容器编排、分布式事务、消息队列、各种中间件。每一步都有它的道理,但累积下来,很多系统的基础设施比它要解决的问题复杂得多。

现在风向在变。

Neon 是一个 URL。D1 是一个 API。pg_notify 替代了 Kafka。DuckDB 在单机上跑赢了很多 Hadoop 集群。ScaleFlux 一块盘解决了本来需要重新设计存储架构的问题。

工具在变,但方向是往简单走。

从 LAMP 开始的互联网,绕了二十年,正在某种意义上回到 LAMP——不是退步,是在更高的抽象层上重新找到了简单。那个 L 变成了云,那个 A 变成了 edge function,那个 M 变成了 Neon,那个 P 变成了任何你喜欢的语言。

大道至简。少即是多。

做多了,经历多了,才能真正理解这两句话不是口号。


关系数据库这个赛道,这二十年发生了很多事。

Oracle 是先驱,但为了股价转头去做 neocloud 生意了,数据库反而成了副业。MySQL 卖身 Sun,Sun 卖身 Oracle,现在活在各种营销稿里,影响力大不如前。SQLite 是另一种存在——无处不在,几亿台设备上跑着它的代码,作者 Richard Hipp 一个人维护至今,主动不接受外部 PR。他的逻辑是:接受别人的 PR,就像接受别人送你的小猫,看起来可爱,到手的一刻起就是负担。一个人,几十年,扛住了整个互联网的重量。

PostgreSQL 是另一种战士。有社区,有方向,有人在认真推进。它是关系数据库和 SQL 真正的代言人——没有被资本收购,没有被商业利益带偏,二十年来一直在把关系数据库推向新的高度,没有被任何竞争者打倒过。

这件事,我觉得值得说出来。


所以,为什么二十年没有换掉 PostgreSQL?

因为它足够好,好到我从来没有遇到一个让我必须换掉它的理由。

因为我了解它,知道它的边界,知道在边界之外用什么来补——DuckDB、ClickHouse、ScaleFlux,都是它的补丁,不是它的替代。

因为它还在进化。逻辑复制、分区表、jsonb、并行查询——每个大版本都有让人惊喜的东西,它没有停在原地等着被淘汰。

但最诚实的答案,可能是这个:

我们能做的,就是专心把 PostgreSQL 运维好。

不是因为它完美,而是因为把一个足够好的工具用到极致,比频繁地寻找更好的工具,往往要值得得多。


2009 年,我在北欧银行项目的前辈故事里,第一次记住了 PostgreSQL 这个名字。

那时候我不知道它会陪我走这么久。

现在知道了。