直播回顾｜PG 到底能扛多大？亿级流量、PB级数据的底层真相
2026年7月15日，由中国PG分会、IvorySQL社区与TechTalk技术交流社区联合主办的「三十而立・全球时刻——PG 30周年系列直播」第四期圆满举行。本期主题为 "PG到底能扛多大？——亿级用户、PB级数据的架构真相"。
原定主持人尚雷因身体不适未能出席，由尹海文代班主持。原定嘉宾林春因临时有紧急会议未能上线，实际参与讨论的为唐成与刘智龙两位老师。三位老师围绕大规模PG生产环境的架构真相、性能边界与运维实践，展开了坦诚而深入的对话。
活动信息
嘉宾阵容
直播内容回顾
单机能扛多大？——从OpenAI的8亿用户说起
本期直播以OpenAI用"1主+50从"架构支撑8亿用户的行业热点为切入点。在真实生产环境中，单机PG可以承载80TB级别的数据量，配合高性能NVMe存储，高峰期每秒写入WAL日志可达GB级别。但从事务ID消耗角度看，单机PG的写入TPS上限大约在3000左右，按21亿事务ID计算，一周多就会消耗殆尽，必须面对事务ID回卷的风险。
关于OpenAI的案例：他们的成功建立在读多写少的业务模型之上；使用了微软云896 vCPU、32TB内存的顶配虚拟机，单台月租金高达17.5万美元；最关键的是对业务SQL做了深度优化。大多数行业（金融、互联网）的读写比通常只有2:8，盲目复制OpenAI架构风险极大。
什么时候必须分布式？——PG扩展方案的真实边界
围绕单机PG的极限与分布式方案的选型边界，嘉宾们展开了深入讨论。从Citus、TimescaleDB到各种中间件方案，每种架构都有其适用场景和代价。关键是理解业务模型后选择合适的方案，而非盲目追求"分布式"。
大规模PG最怕什么？——MVCC、膨胀与autovacuum
MVCC、表膨胀、autovacuum是大规模PG运维中的核心挑战。嘉宾分享了多年积累的生产环境实践经验，包括autovacuum参数调优、膨胀检测与处理、以及如何避免大表VACUUM对业务的影响。
真实案例复盘——那些差点让业务挂掉的事
分享了多个真实生产案例：从事务ID回卷的惊险处理，到大表膨胀导致的性能雪崩，再到主从延迟引发的数据不一致问题。每一个案例背后都是凌晨三点的紧急电话和多年经验的沉淀。
总结
本期直播三位老师用真实的案例和坦诚的分享，深入剖析了大规模PG生产环境的底层真相。PG的极限不在代码里，而在业务模型、硬件配置和运维能力的结合点上。
