首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >MongoDB CEO 炮轰 PostgreSQL

MongoDB CEO 炮轰 PostgreSQL

作者头像
用户4035096
发布2026-07-09 20:15:59
发布2026-07-09 20:15:59
10
举报

MongoDB CEO 炮轰 PostgreSQL 根本扩展不了

上周 MongoDB 的 CEO 一鸣惊人,对外宣布说他们搞 AI 的“超级高增长”客户从 PostgreSQL 阵营叛逃了,理由是 “PostgreSQL 根本扩展不了”

这一下可点燃了 PGer 的“斗志”:咱们夸自己牛逼就得了,踩别人干啥呀? 我可是天天在 PostgreSQL 的生产问题里摸爬滚打的行家,啥性能、高可用、救火队我都干过,我的观点可不是什么季度财报上的漂亮话!

让我们看看作者如何反击 MongoDB CEO: https://stormatics.tech/blogs/postgresql-mongodb-and-what-cannot-scale-really-means

PostgreSQL 到底能不能“扛得住”?

缩放(Scale)的故事,比 CEO 的金句复杂得多!

当一个大佬说 “PostgreSQL 扛不住” 的时候,他省略了太多细节,比如:

  • 人家的表结构访问模式长啥样?
  • 连接事务是怎么管理的?是云托管的还是自己搭的草台班子?
  • 垂直(加硬件)和水平(分库分表)的方案都试过了吗?
  • 请 PostgreSQL 专家了吗? 还是用的默认设置?(这才是重点吧喂!)

MongoDB 在处理多变文档、快速迭代方面确实牛,有它的江湖地位。但咱不能忍的是 “PostgreSQL 这种技术本身就不行” 的说法,毕竟它现在可是专业开发者里最受欢迎的数据库

📣 PostgreSQL :“我不是不行,是你不会用!”

有人说 PostgreSQL 扩展性差?那得问问:是哪种扩展?哪种设计?

1. 垂直扩展:单节点也能很能打!💪

一个配置得当的 PostgreSQL 单节点,能轻松处理:

  • 每秒数十万的事务(Transactoins Per Second, TPS)。
  • 数十 TB 的数据

很多 SaaS 和金融科技(Fintech)公司都靠着一个调优过的强大单节点,安安稳稳地跑了好几年。关键在于:砸钱上最好的 NVMe 存储,调优 Linux 参数,加上连接池 PgBouncer

2. 水平扩展:分身术和魔法阵!✨

单节点不够?PostgreSQL 的“分身术”早就准备好了:

  • 读写分离:用流复制(streaming replication)搞一堆只读副本(Read Replicas)。
  • 分区(Partitioning) :用原生分区,把大表分成一个个小桌子,减少索引和表膨胀,提高缓存命中率
  • 分片(Sharding) :像 Citus 这样的扩展,能把 PostgreSQL 变成一个分布式集群

更别提市面上还有 AWS Aurora、Google AlloyDB、Citus 等一堆专门搞大并发的 PostgreSQL 服务,这不就是为了解决“大规模”问题而生的吗?

🤖 AI 工作负载?不过是另一种工作负载!

别被 “AI 工作负载” 这个高大上的标签吓到,剥去外衣,它们无非就是:大量事件写入 + 矢量搜索 + 配置信息存储 + 运行分析查询

PostgreSQL 照样能搞定:

  • pgvector 扩展:完美支持矢量搜索。
  • 分区和扩展:处理时序数据和高容量事件。
  • 事务和成熟工具链:稳稳地支撑计费、权限这些“核心业务”。

所以,“AI 工作负载”只是个行为描述,不是给某类数据库发“免死金牌”

🚨 现场救援的经验之谈:问题出在“人”和“设计”!

作者天天处理的都是“快不行了”的系统,PostgreSQL 这个技术本身很少是瓶颈,真正的罪魁祸首是:

  • 设计不合理:热数据路径没隔离、后台任务没分开。
  • 实现不到位:连接池没用或没配置好。
  • 运维纪律差:复制配置马马虎虎,都是默认设置。

PostgreSQL 扩展得很顺利,只要架构能匹配上问题!

🤝 友情提醒:MongoDB 也是好同志!

为了公平起见,咱也承认,在某些情况下 MongoDB 确实是更明智的选择

  • 数据结构多变,需要频繁改 Schema。
  • 主要都是文档级别访问,很少跨文档联表查询。
  • 团队本身就是 MongoDB 的老司机

所以,结论是:夸 MongoDB 是更好的选择,没毛病;说 PostgreSQL 根本不能扩展,那就是瞎j b胡扯!

最终总结:扩展性是个工程活,不是个品牌标签!

做数据库选择,得从以下三步走:

  1. 看工作负载: 读写量、数据模型、一致性要求。
  2. 看团队能力: 谁是 SQL 大师?谁有 MongoDB 运维经验?
  3. 看方案匹配: 垂直、副本、分区都试了吗?实在不行再考虑分布式。
  4. 老实做基准测试: 别只看 QPS,还要看 P99 延迟和故障处理!

请问企业的CTO 和数据库工程师们:你真的把 PostgreSQL 的潜能都榨干了吗? 垂直扩展、只读副本、分区这些都做好了吗?如果还没,你还有很大的“发挥空间”!


一句话总结:MongoDB CEO 唱衰 PostgreSQL “不能扩展”,但咱用实际经验告诉你:别听他j b瞎说!扩展性不是品牌之争,而是工程设计和调优的艺术!在抱怨数据库不行之前,先问问自己是不是个合格的“架构师”吧!

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

本文分享自 digoal德哥 微信公众号,前往查看

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • MongoDB CEO 炮轰 PostgreSQL 根本扩展不了
  • PostgreSQL 到底能不能“扛得住”?
    • 缩放(Scale)的故事,比 CEO 的金句复杂得多!
    • 📣 PostgreSQL :“我不是不行,是你不会用!”
      • 1. 垂直扩展:单节点也能很能打!💪
      • 2. 水平扩展:分身术和魔法阵!✨
    • 🤖 AI 工作负载?不过是另一种工作负载!
    • 🚨 现场救援的经验之谈:问题出在“人”和“设计”!
    • 🤝 友情提醒:MongoDB 也是好同志!
    • 最终总结:扩展性是个工程活,不是个品牌标签!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档