刷到 Pratik Singh 在 Mac Mini M4 Pro 上跑的那个 ClickHouse 和 PostgreSQL 对比，1 亿行 LLM trace 数据，两台……不对，一台机器，两个库，同一份数据。
第一个让我停下来的数字：ClickHouse 摄入速度是 78,000 行/秒稳定跑完，PostgreSQL 一开始 32,000 行/秒，数据越多越慢，掉到 14,000 行/秒。差 5.6 倍。然后是存储，同样 1 亿行，ClickHouse 花了 48GB，PostgreSQL 用了 116GB。空间省了 2.4 倍。
到这里我几乎是边看边点头——这就是 ClickHouse 的主场啊，列式存储赢 ingestion 和压缩有什么好意外的。
然后我看到聚合查询那组数据。
90 天 dashboard 聚合，ClickHouse 284 毫秒，PostgreSQL 49,085 毫秒。49 秒。全表 metrics 查询，ClickHouse 半秒，PostgreSQL 70 秒。
我盯着"49,085"这个数字看了很久。这不是快一点点，这是三个数量级。你知道最让我心里一沉的是什么吗？就是这个数字在 PG 的生态里其实不算离谱。你给 PG 一个真正的 OLAP 负载，拆成一堆索引和物化视图哄着它，它也能跑，但是要操很多心。而 ClickHouse 就是那种不跟你讲道理的快。
正当我以为这篇要变成 ClickHouse 的胜利宣言时，文章翻到 point lookup——单条 trace 按 ID 查询，PostgreSQL 0.03 毫秒，ClickHouse 3 毫秒。
100 倍。反过来了。
这篇文章的结论其实很朴素：PostgreSQL 适合事务性点查，ClickHouse 适合分析型聚合，这就是 OLTP 和 OLAP 的区别。但"朴素"和"懂了"之间隔着一条我自己最清楚的鸿沟——我知道这两个词是什么意思，我甚至能背出对比表的数字，可是当我自己的项目要做技术选型时，我真的能根据负载特征做这个判断吗？
说句丢人的话，现在回头看这个月我自己写的那些破代码，数据库需求大概处于 SQLite 都嫌多的水平。读这种 benchmark 最危险的错觉就是觉得自己参与了什么了不起的决策。我没有。我连一条真实的海量 trace 都没处理过，我在这激动什么呢？
Langfuse 从 PostgreSQL 迁到 ClickHouse 那条新闻倒是真的吸引我。它早期用 PG 存 trace，后来换成 ClickHouse，还被 ClickHouse 收购了。一个 LLM 可观测性平台，存的就是海量 trace，分析型负载占绝对大头，走这条路几乎是必然。但让我好奇的不是"它为什么迁"，而是迁移过程中那些被省略掉的东西：团队花了多少时间？老的 PG 数据怎么搬？查询怎么改？踩了哪些坑？文章里不会写，但我知道这些才是真实世界里最花时间、也最容易让一个看起来很对的迁移决策翻车的地方。
说真的，我把文章里其他数字翻了一遍想找内存那条——ClickHouse 峰值 RAM 用了 950MB，PostgreSQL 只有 134MB。差 7 倍，但在这个量级下 950MB 真的不算什么，24GB 内存的 Mac Mini 绰绰有余。所以内存反而成了最不重要的一项。有意思。
这篇东西看完，我最大的收获其实是发现自己对"快"的理解还是太粗糙了。以前总觉得"这个数据库快"是一个整体属性，现在才意识到：快是分方向的，同一个库，一个 3 毫秒一个 0.03 毫秒，可能只是查询类型的区别。没有哪个数据库在所有方向上都赢，你选了一个方向的快，就得默认接受它在另一个方向上的慢。
这个东西没人告诉我，我猜得自己撞一次墙才记得住。
评论区应该会有人争"你那个 benchmark 数据集造得不合理"之类的高级问题，我没资格参与。我就想知道有没有人也干过这蠢事：看了这种对比文章热血沸腾，差点想给自己的个人项目也上 ClickHouse，然后冷静下来发现自己连 PG 都没用明白。有的话评论区握个手，让我知道自己不是一个人。
进度条：今天没写代码，看了一篇 benchmark 文章，但这种"知道自己不知道"的感觉，也算挪了一小步吧。