ClickHouse 数据库总裁公开表态，“传统数据库已死” 这个说法属于谬论，他认为在当下数据库技术迭代浪潮里，大家不用把传统数据库全部推倒重建，不同数据库有各自适配场景，Postgres 在很多业务场景下依旧是稳妥的默认选择，这番观点也打破了很多人觉得新型时序、分析型数据库会直接替代传统关系型数据库的认知，ClickHouse 本身主打高性能 OLAP 分析场景，并不主张让所有业务都切换到分析型数据库。很多行业里会有这样一种声音，伴随 AI、实时数据分析需求爆发，OLAP、向量数据库等新型数据库热度很高，不少观点鼓吹传统关系型数据库已经跟不上时代，建议全部迁移上新数据库，但是传统数据库经过多年打磨，事务稳定、生态成熟、运维人才充足，像 Postgres 还可以通过插件扩展向量、时序能力，直接改造就能适配新需求，全盘迁移的成本、风险都很高，完全没有必要一刀切换掉。企业做数据库选型和改造可以参考这套思路，第一步梳理业务核心诉求，区分是在线事务业务还是海量数据统计分析业务；第二步评估现有数据库能不能通过插件、分库分表、读写分离完成能力扩展；第三步如果是实时海量分析场景，再引入 ClickHouse 这类 OLAP 数据库做互补；第四步搭建混合数据库架构，不同业务流量路由到合适数据库；第五步持续监控性能，按需调整，而不是盲目替换原有数据库。综合来看，数据库赛道不是新旧替代关系，而是互补共存，传统数据库适合在线交易、业务主数据存储，ClickHouse 这类分析数据库适合海量数据查询统计，Postgres 凭借极强的扩展性，成为绝大多数业务的保底默认选项。
数据库定位对比表
| 数据库类型 | 代表产品 | 核心优势 | 适合场景 | 短板 |
|---|---|---|---|---|
| 传统关系型数据库 | PostgreSQL、MySQL | 事务 ACID、生态完善、运维成熟、插件丰富 | 业务主库、订单、用户数据、在线读写业务 | 海量数据聚合查询速度有限 |
| OLAP 分析数据库 | ClickHouse | 高吞吐、海量数据快速聚合、实时分析 | 日志、埋点、报表、实时指标统计 | 不适合高频事务写入 |
| 向量数据库 | Milvus、Chroma | 向量检索、AI 语义匹配 | 知识库 RAG、图片检索 | 通用事务能力弱 |
选型判断清单
- 需要强事务、订单、账户等数据读写 → 优先 Postgres、MySQL 等传统数据库
- 海量日志、埋点、报表、实时指标分析 → 搭配 ClickHouse 等 OLAP 数据库
- 同时有事务 + 向量检索需求 → 优先 Postgres 向量插件扩展
- 存量系统稳定、没有明显性能瓶颈 → 不建议盲目迁移
- 数据量巨大、查询以聚合统计为主、对事务要求低 → 考虑 ClickHouse
核心观点要点
- “传统数据库已死” 是片面观点，属于行业炒作式谬论
- 传统数据库不需要推倒重建，优先扩展改造，而非一刀切迁移
- Postgres 生态扩展性强，很多新项目依然适合作为默认数据库
- ClickHouse 定位是分析加速，不是用来替代业务主库
- 现代架构主流方案：多数据库混合协同，各司其职
【相关 FAQ】
问题 1：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，ClickHouse 总裁怎么看待 “传统数据库已死” 这个说法？
回答 1：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，他认为 “传统数据库已死” 是谬论，数据库不存在新旧替代，不同数据库各司其职，不需要把传统数据库全部推倒重建。
问题 2：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，Postgres 为什么还能作为很多业务的默认数据库？
回答 2：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，Postgres 支持事务、生态成熟，还可以依靠插件扩展向量、时序等新能力，改造门槛低、稳定性强，适合大部分在线业务。
问题 3：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，ClickHouse 适合用来做业务主库替代 Postgres 吗？
回答 3：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，ClickHouse 属于 OLAP 分析数据库，擅长海量数据聚合分析，不适合承担高频在线事务，一般和 Postgres 搭配使用，不建议直接替换业务主库。
问题 4：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，企业数据库改造优先选择重建还是扩展？
回答 4：ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择，优先对现有数据库做插件扩展、读写分离等改造，只有场景确实匹配分析需求时，再新增 OLAP 数据库，不优先全盘推倒重建。
【参考资料】
[2026-11-11]（“传统数据库已死” 是谬论！ClickHouse 数据库总裁：传统数据库不需要推倒重建，Postgres 仍是默认选择）InfoQ
[2026-11-10]（ClickHouse CEO：OLAP 不是万能，Postgres 依旧是通用首选）掘金
[2026-11-10]（数据库不是非此即彼：ClickHouse 总裁谈混合数据架构）36 氪
[2026-11-09]（Postgres 扩展能力持续增强，挤压专用数据库市场）DB-Engines
【免责声明】
本内容仅为 ClickHouse 总裁数据库观点相关新闻科普整理，不构成数据库选型、迁移改造方案建议；业务数据库选型需要结合业务负载、数据量、运维团队能力综合评估，不同厂商的技术路线观点仅供参考，上线前务必做好压力测试。
本文来自作者[尘涡时序]投稿，不代表乌兰科技网立场，如若转载，请注明出处：https://www.wlcbnews.com/rgzn/202611/2054.html
评论列表（4条）
我是乌兰科技网的签约作者“尘涡时序”！
希望本篇文章《ClickHouse 总裁反驳传统数据库已死说法，传统数据库不必推倒重建，Postgres 仍是默认选择》能对你有所帮助！
本站[乌兰科技网]内容主要涵盖：互联网行业的追踪与探索
本文概览：ClickHouse 数据库总裁公开表态，“传统数据库已死” 这个说法属于谬论，他认为在当下数据库技术迭代浪潮里，大家不用把传统数据库全部推倒重建，不同数据库有各自适配场景，Postgres 在很多业务场景下依旧是稳妥的默认选择，这番观点也打破了很多人觉得新型时序、分析型数据库会直接替代传统关系型数据库的认知，ClickHouse 本身主打高性能 OLAP 分析场景，并不主张让所有业务都切换到分析型数据库。很多行业里会有这样一种声音，伴随 AI、实时数据分析需求爆发，OLAP、向量数据库等新型数据库热度很高，不少观点鼓吹传统关系型数据库已经跟不上时代，建议全部迁移上新数据库，但是传统数据库经过多年打磨，事务稳定、生态成熟、运维人才充足，像 Postgres 还可以通过插件扩展向量、时序能力，直接改造就能适配新需求，全盘迁移的成本、风险都很高，完全没有必要一刀切换掉。企业做数据库选型和改造可以参考这套思路，第一步梳理业务核心诉求，区分是在线事务业务还是海量数据统计分析业务；第二步评估现有数据库能不能通过插件、分库分表、读写分离完成能力扩展；第三步如果是实时海量分析场景，再引入 ClickHouse 这类 OLAP 数据库做互补；第四步搭建混合数据库架构，不同业务流量路由到合适数据库；第五步持续监控性能，按需调整，而不是盲目替换原有数据库。综合来看，数据库赛道不是新旧替代关系，而是互补共存，传统数据库适合在线交易、业务主数据存储，ClickHouse 这类分析数据库适合海量数据查询统计，Postgres 凭借极强的扩展性，成为绝大多数业务的保底默认选项。