首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >PG 还是 ClickHouse?先别急着二选一

PG 还是 ClickHouse?先别急着二选一

作者头像
不吃草的牛德
发布2026-07-21 15:51:46
发布2026-07-21 15:51:46
1140
举报
文章被收录于专栏:RustRust

每隔一阵,技术群里就会有人甩过来一句:"新项目数据库用 PostgreSQL 还是 ClickHouse?"

每次看到我都想叹口气。不是嫌这问题蠢,是它问错了方向——把两个根本不在一条赛道上的东西,摆成了二选一。

我见过太多团队在选型会上为"哪个更强"吵半天,最后拍脑门定了一个,跑半年才发现踩坑。其实这俩货的"甜区"几乎不重叠,真要较真,它们连对手都算不上。

它们到底是个啥

PostgreSQL 是个正经的关系型数据库,设计目标就是把业务数据稳稳当当地存住。事务、约束、外键、回滚,这些保证数据不丢不错的东西,它全包了。你半夜发现一条脏数据,一句 UPDATE 改完 rollback 都来得及。

ClickHouse 不是"另一个数据库",它本质是个列式分析引擎。它的世界里没有"改一行"这种操作的概念——数据进来基本就是追加,然后等着被海量地扫描、聚合。它的全部才华都用在了一件事上:让你在几十亿行数据上跑 GROUP BY,还能秒回。

一个是会计,一个是统计员。你拿统计员去收账,或者让会计去做全国人口普查,都不对口。

按场景说人话

场景一:你在做业务系统(订单、用户、交易、支付) 毋庸置疑,必须是PostgreSQL。需要事务、需要约束、需要"这笔扣了那笔必须加上"。ClickHouse 在这种场景中会让你怀疑人生——它改一条数据要重写一整块数据块(part),而且还是异步的,你刚 UPDATE 完去查,可能还没生效。业务系统用 ClickHouse 当作主库,可能会出现大量数据不致的问题。

场景二:你要分析一大堆历史数据(日志、埋点、行情、链上数据) ClickHouse 主场。PostgreSQL 也能查,但当你的数据达到几十亿行,随便一个 GROUP BY 能让 PG 跑到地老天荒,索引也救不了你——因为分析查询本质上是全列扫描,B+ 树索引帮不上忙。ClickHouse 的列式存储只读出需要的列,加上向量化执行,速度根本不是一个量级。

场景三:实时看板,每秒几万条写入,前端要秒级出图 ClickHouse。高吞吐写入是它的看家本领,批量插进去跟玩一样。PG 在高并发写入下,Vacuum 和索引维护迟早让你头疼,连接池打满都是轻的。

场景四:你就一个人,一个库,啥都得干 老实用 PostgreSQL,先用起来。等哪天你真被某个分析查询卡脖子了,再接 ClickHouse 当分析从库也不迟。我见过最典型的过度设计之一就是——过早引入 ClickHouse ,为了一年用不到几次的分析需求,养一整套完全不同的运维体系,值吗?

场景五:复杂关联查询(join 七八张表还带子查询) ClickHouse 的 join 一直是软肋,早年单线程、吃内存,官方文档甚至建议你把数据拉平(denormalize)别 join。最近版本好了不少,但真要复杂的多表关联,还是 PG 稳。

场景六:时序数据(监控指标、IoT、tick 级行情) 两个都能干。PG 挂个 TimescaleDB 插件很香,自带降采样和连续聚合,对熟悉 PG 的团队几乎零成本。CH 用 MergeTree 加物化视图也能做,而且体量再大一个数量级也更稳。看你的数据量和团队底子。

大多数公司真正的做法是:两个一起用

PG 作为主库,通过逻辑复制或者 CDC 把数据同步到 ClickHouse,专门负责算。ClickHouse 只管"算",不管"记"。

这是很多团队的现实架构,不是非此即彼。我就见过一个做金融风控数据的团队,订单和用户跑在 PG 上,每天的借贷、还款快照和交易流水同步进ClickHouse 做风控和因子计算——各司其职,谁也不抢谁的活。

几个别被忽悠的点

  • • ClickHouse 不是银弹。它用更新灵活性和事务能力,换来了扫描速度。你想要的如果是"随时改一条",它给不了。
  • • PostgreSQL 也不是万金油。分析量大了就是会慢,别硬撑着不承认,到时候加从库、上列存插件,或者干脆分流,都比死扛强。
  • • 别被"性能对比 benchmark"带节奏。那些跑分文章,大多是拿 ClickHouse 最舒服的聚合查询去锤 PG 最弱的项。换个事务场景,结论立刻反过来。

要是我是你,我这么选

  • • 创业 MVP、小团队、业务系统 → PostgreSQL 一把梭,别想太多
  • • 日志平台、埋点分析、监控后端 → ClickHouse 主战场
  • • 交易、支付、ERP 这类不能出错的 → PostgreSQL,没得商量
  • • 既要跑业务又要做分析 → PostgreSQL 主 + ClickHouse 从,经典组合

选型的核心就一句话:你主要的读写模式是什么? 事务优先选 PG,扫描聚合优先选 CH。先把这个问题答清楚,比看一百篇"XX vs YY 谁更强"都有用。

所以下次再有人问你 PG 还是 ClickHouse,先反问一句:你到底要它干什么?

工具没有高低,只有合不合适。这话听着像句废话,但被错误选型坑过的团队都懂,它不是。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Rust火箭工坊 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 每隔一阵,技术群里就会有人甩过来一句:"新项目数据库用 PostgreSQL 还是 ClickHouse?"
    • 它们到底是个啥
    • 按场景说人话
    • 大多数公司真正的做法是:两个一起用
    • 几个别被忽悠的点
    • 要是我是你,我这么选
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档