PG到底能扛多大？亿级流量、PB级数据的底层真相

一、活动概况

2026年7月15日（周三）19:00–20:30，由中国PG分会、IvorySQL社区与TechTalk技术交流社区联合主办的「三十而立・全球时刻——PG 30周年系列直播」第四期圆满举行。本期主题为 “PG到底能扛多大？——亿级用户、PB级数据的架构真相” 。

原定主持人尚雷因身体不适未能出席，由尹海文代班主持。原定嘉宾林春因临时有紧急会议未能上线，实际参与讨论的为唐成与刘智龙两位老师。三位老师围绕大规模PG生产环境的架构真相、性能边界与运维实践，展开了坦诚而深入的对话。

二、嘉宾阵容

• 尹海文（代班主持） ：Oracle ACE Pro、PostgreSQL ACE，IvorySQL专家顾问委员，10年数据库行业经验。
• 唐成：中启乘数科技创始人及CTO，《PostgreSQL修炼之道：从小工到专家》作者，从业20余年。
• 刘智龙：平安科技PG数据库专家，10年运维经验，公众号“最后的DBA”主理人。

三、直播内容回顾

板块一：单机能扛多大？——从OpenAI的8亿用户说起

本期直播以OpenAI用“1主+50从”架构支撑8亿用户的行业热点为切入点。讨论首先围绕单机PG的真实负载能力展开——在真实生产环境中，单机PG可以承载80TB级别的数据量，配合高性能NVMe存储，高峰期每秒写入WAL日志可达GB级别，系统依然能够稳定运行。但从事务ID消耗的角度来看，单机PG的写入TPS上限大约在3000左右，按21亿事务ID计算，一周多就会消耗殆尽，必须面对事务ID回卷的风险。如果硬件配置足够强（如内存1TB以上），TPS也能扛到1万级别，但本质上仍然绕不开回卷问题。

关于OpenAI的案例，讨论中达成了几点共识：OpenAI的成功建立在读多写少的业务模型之上，写操作几乎可以忽略不计；他们使用了微软云896 vCPU、32TB内存的顶配虚拟机，单台月租金高达17.5万美元；最关键的是，OpenAI对业务SQL做了深度优化，而非使用大量多表关联的复杂查询，这才让单主多从的架构成为可能。但大多数行业（金融、互联网）的读写比通常只有2:8，远达不到1:50，盲目复制OpenAI的架构风险极大，且存在主从延迟导致的查询冲突问题，需要根据业务的时效性要求对查询进行分流。

板块二：什么时候必须分布式？——PG扩展方案的真实边界

关于“何时拆数据”，讨论给出了非常务实的建议。

核心观点是不要过早做分库分表。业务还没发展起来就拆分，等到业务真正爆发时，其实硬件投入已经不再是主要矛盾。有真实案例显示，某企业按地市拆库后，最大的一个地市仍然有80TB数据，之所以不再往下拆，是因为业务里有大量复杂的SQL，拆分的应用改造成本太高，最终选择用硬件硬扛。

拆分的优先级应该是先拆业务（分库），再考虑拆表（分片） 。按业务线做逻辑拆库（微服务化），比引入分布式中间件要稳妥得多。分布式方案引入以后，运维成本明显高很多，与集中式PG完全不是一个量级——不要在一个稳定的底座上去添加不稳定的因素。在分布式方案中，Citus是目前PG生态中相对成熟的方案，但引入时机和代价仍然需要审慎评估。

此外，硬件与人力成本的权衡也是一个重要变量。在中国市场，很多传统客户倾向于用硬件堆砌来规避应用改造的人力成本；但随着内存等硬件价格上涨，通过代码优化和架构调整来替代硬件堆砌的趋势正在显现。

板块三：大规模PG最怕什么？——MVCC、膨胀与autovacuum

这是整场直播信息密度最高的板块。

MVCC与垃圾回收是核心议题。讨论指出，Auto Vacuum的调优不能一刀切——大表需要调整vacuum_cost_delay等参数，默认值往往不够用。长事务必须体系化治理，它不仅是元组回收的障碍，更是很多系统性问题的根源。如果元组的生成速度持续快于回收速度，表就会不停膨胀，监控必须到位，并针对性地调整参数、索引个数，或考虑冷热分离。

大表与索引维护是另一个棘手问题。几百GB的表加上几百GB的索引，跑一次VACUUM就要几个小时。如果表在设计之初没有做成分区表，后期维护会极其痛苦。有极端案例显示，一张将近1TB的大表，跑一次VACUUM耗时整整7天。因此，在建表初期就应该识别出可能急剧增长的表并采用分区表策略，避免后期陷入无法在线维护的困境。同时，频繁更新的字段上建立索引会导致严重的写放大和阻塞，索引策略需要审慎设计。

坏块与物理复制陷阱也是一个容易被忽视的风险。物理复制可能将主库的坏块或索引不一致问题同步到备库，切换后仍然报错。更麻烦的是，损坏的块在物理层面看起来可能是旧版本的正常块，不会直接报错，但查询时就会发现表和索引对不上。这种情况下业务不能停，只能通过在线重建索引等方式逐个修复。

板块四：真实案例复盘——那些差点让业务挂掉的事

讨论中分享了两个令人印象深刻的真实故障案例。

第一个案例是逻辑复制溢出文件爆炸。某个 PG 库的溢出文件数量达到上千万个，操作系统扫描这些文件时直接卡住，导致数据库切换后第二个节点也挂了，高可用彻底失效。没有备库可切，只能现场研究问题根因，手工清理操作系统文件才把库拉起来。这个案例的教训是：当高可用已经失效时，你必须真正理解问题才能恢复业务。

第二个案例是插件过度使用带来的隐患。很多生产库里塞了太多插件——超过10个插件就会显著增加不稳定性和维护难度。插件之间可能存在加载顺序冲突，有些插件声称自己必须最后一个加载，但当十几个插件都这么说时，没人能真正管理这个顺序。更严重的是，部分热门插件存在维护停滞的风险，一旦社区大版本升级，兼容性断裂会给运维带来极大痛苦。选型建议很明确：不需要的插件就别装，装了就要做好长期维护的准备。生产环境应仅使用成熟、活跃度高且经过验证的基础插件。

四、AI时代的新挑战：数据库的未来往哪走

讨论还前瞻性地探讨了AI时代对数据库的影响。

AI Agent的操作是全天候、高频次的，它不会像人一样有业务波峰波谷，这意味着数据库将面临持续高压。AI快速调用可能导致CPU频繁突刺，现有的MVCC机制在面对这种场景时显得力不从心。

AI直接操作生产库存在巨大风险。原生PG缺乏闪回查询功能，一旦AI误删数据，恢复成本极高。当前的最佳实践是将AI操作限制在临时库或隔离环境中，而非直接操作核心生产数据。

DBA的价值无法被AI替代。AI擅长在海量监控数据中快速定位问题，但它只能完成分析部分，最终的方案执行和决策仍然需要人来完成。更重要的是，DBA对数据库性能边界的认知——知道什么样的硬件配置能支撑什么样的业务——是长期积累的经验，AI目前无法真正提供这种判断力。

五、总结

本期直播是PG 30周年系列中技术纵深最深的一期。讨论真正回答了大规模PG使用者最关心的问题：PG在什么条件下能扛住亿级用户、扛不住的时候该怎么办、以及那些让你半夜被叫醒的坑到底在哪里。

一个贯穿全场的核心观点是：在真正找到瓶颈之前，别急着把系统拆得七零八落。 与其盲目上分布式，不如先把业务SQL优化好、把Auto Vacuum调优到位、把长事务治理干净——这些基本功做扎实了，单机PG能扛的体量，远比大多数人想象的要大。

而对于即将到来的AI时代，讨论给出的启示是：DBA对数据库边界的认知，仍然是不可替代的核心价值——AI可以帮你分析问题，但最终拍板和执行，还得靠人。

---

线下活动预告

专属PG技术线下沙龙重磅来袭！齐聚行业资深数据库专家，聚焦实战运维、架构优化、落地避坑，带来满满的技术干货与行业新知，欢迎各位技术爱好者报名参与！