当ChatGPT从零增长到8亿用户，支撑它的不是什么花哨的分布式数据库，而是一个你可能每天都在用的开源关系型数据库——PostgreSQL。OpenAI在2026年初发布了一篇工程博客《Scaling PostgreSQL to power 800 million ChatGPT users》，引发了整个后端工程圈的热烈讨论。Milan Jovanović——微软MVP、拥有100K+订阅的软件架构频道主——随后在YouTube上发布了一期Step-by-Step深度拆解视频，逐层剖析了OpenAI是如何在"单主多从"这种看似保守的架构下，承载每秒数百万查询的。这期视频对任何从事后端架构、数据库工程或系统设计的开发者来说，都是一堂价值极高的实战课。
| 项目 | 内容 |
|---|---|
| 视频标题 | How OpenAI Scaled Postgres to 800 Million Users (Step-by-Step) |
| 频道 | Milan Jovanović |
| 频道定位 | 软件架构 / .NET / 系统设计 |
| 时长 | 约20分钟 |
| 核心主题 | OpenAI的PostgreSQL规模化架构拆解 |
| 基于素材 | OpenAI官方博客 + ByteByteGo分析 |
| URL | https://www.youtube.com/watch?v=0uV-2latI-4 |
OpenAI的数据库架构乍一看甚至有些"朴素"：一个主库（Primary）负责所有写操作，大约50个只读副本（Read Replicas）处理读请求。没有分片（Sharding），没有NewSQL黑科技，没有从第一天就搞什么微服务数据库拆分。
这种"单主架构"（Single-Primary Architecture）在教科书上被认为是不可扩展的——因为写操作无法分布式处理。但OpenAI选择它有一个关键前提：ChatGPT的 workload 本质上是读密集型的（read-heavy）。用户发送一条消息，后端需要读取大量上下文、历史对话、模型配置等信息，而真正的写操作（保存一条对话记录）相对有限。
视频核心观点：架构选择不是追求"理论上最优"，而是追求"对当前workload最匹配"。OpenAI的工程师没有盲目追求分片，而是精准识别了读多写少的特征，选择了最务实的路径。
延伸分析：这个决策背后其实有一个被很多人忽略的考量——分片的迁移成本。OpenAI的博客原文明确提到，修改数百个应用端点来支持分片需要"数月甚至数年"的时间。在ChatGPT用户量每周都在暴涨的情况下，选择一条可以快速落地的路径，远比追求"完美架构"更理性。这是一个典型的工程权衡（engineering trade-off）案例。
OpenAI面临的第一个工程瓶颈是数据库连接耗尽。PostgreSQL的每个连接都会fork一个独立进程，消耗约10MB内存。当ChatGPT的并发连接数飙升到数万级别时，数据库服务器直接被连接风暴（connection storm）压垮。
解决方案是部署 PgBouncer 作为连接池代理层。其原理类似"拼车"——不是每个人都自己开车上路，而是共享有限的车辆资源。PgBouncer在事务（transaction）或语句（statement）级别复用连接，将平均连接建立时间从50毫秒压缩到5毫秒。
视频核心数据：连接建立延迟从 50ms → 5ms，降低了整整10倍。这听起来是个小数字，但当你的系统每秒需要处理数百万次数据库访问时，50ms的节省意味着每天减少数百小时的累计等待时间。
延伸分析：PgBouncer的部署模式有一个细节值得注意。视频提到OpenAI使用的是"statement或transaction pooling模式"，而非session pooling。这意味着中间件会在每个SQL语句或事务结束后立即回收连接，最大化连接利用率。但这也有代价——某些依赖session state的PostgreSQL特性（如临时表、prepared statements、SET命令）在这种模式下无法使用。这是一个典型的"牺牲灵活性换性能"的决策。
OpenAI部署了约50个只读副本来分担读压力。这些副本持续从主库同步数据（通过PostgreSQL的流复制streaming replication机制），应用层通过路由逻辑将读请求分发到最近的副本。
视频核心观点：读副本的扩展几乎是线性的——50个副本意味着读能力提升约50倍。但这里有一个微妙的同步延迟问题：主库写入的数据需要在毫秒级传播到所有副本。对于ChatGPT来说，用户发完消息后立刻读取响应，这个场景下副本的"新鲜度"至关重要。
延伸分析：OpenAI能跑50个副本还有一个常被忽略的基础设施前提——微软Azure的全力支持。视频提到，OpenAI的数据库运行在Azure能提供的最强大的虚拟机上，并且Azure团队专门为OpenAI处理了大量底层的复制和故障转移复杂性。这不是一个普通公司能复制的配置。但架构思路本身——通过读副本线性扩展读能力——是所有开发者都可以借鉴的。
为了进一步减轻PostgreSQL的读压力，OpenAI在数据库前部署了缓存层（推测为Redis或类似方案）。大部分读请求命中缓存，不会打到数据库。
但这里有一个灾难性场景：当缓存命中率意外下降时——比如缓存大面积失效（cache miss storm）——原本由缓存吸收的海量读请求会瞬间涌入PostgreSQL，导致数据库过载。更糟糕的是，主库过载后请求变慢或超时，用户开始重试，形成正反馈恶性循环：原始流量高峰 → 缓存雪崩 → 数据库过载 → 请求超时 → 用户重试 → 流量进一步飙升 → 完全宕机。
视频核心观点：缓存不是万能药，它引入了一种新的故障模式。OpenAI的事件复盘显示，多次高严重级事故都与缓存命中率骤降有关。
延伸分析：这个教训对所有后端工程师都有价值——你的系统可靠性取决于最薄弱的环节，而缓存雪崩往往是最容易被忽视的那个。防御策略包括：缓存预热、限流（rate limiting）、缓存多级降级、以及最关键的——为缓存失效场景设计专门的"断路器"机制。
视频提到了一个技术深水区：PostgreSQL的 MVCC（多版本并发控制） 设计在写密集场景下的天然局限。
MVCC的核心思想是"读写不互斥"——读操作看到的是数据的历史版本（snapshot），写操作创建新版本而不阻塞读操作。听起来完美，但代价是：每次UPDATE实际上是在创建一行新数据，旧版本需要由VACUUM进程异步清理。当写吞吐量极高时，VACUUM跟不上更新速度，表膨胀（table bloat）加剧，性能急剧下降。
OpenAI联合卡内基梅隆大学教授Andy Pavlo（数据库领域顶级学者）专门研究了这个问题。结论是：PostgreSQL的MVCC设计在高写吞吐场景下存在结构性瓶颈，这不是调优能解决的，而是架构层面的限制。
延伸分析：这个洞察对选择数据库的工程师非常重要。如果你的应用是读多写少（如大多数Web应用），PostgreSQL的MVCC设计简直是为你量身定制的。但如果你的写比例超过某个阈值，就需要认真考虑其他方案。
OpenAI做出了一个可能让很多人意外的决定：不对PostgreSQL进行分片。
理由很务实： 1. 分片需要修改数百个应用端点，工程量巨大 2. 当前workload主要是读密集型，读副本已经提供了足够的扩展能力 3. 分片引入的复杂性（跨分片查询、分布式事务、数据一致性）会大幅增加运维成本
但OpenAI并没有"硬扛"写瓶颈。他们的策略是： - 将可以水平分区的写密集型workload迁移到分片系统（如Azure Cosmos DB） - 优化应用层写入逻辑（如合并写入、批量操作、减少不必要的写操作） - 保留PostgreSQL作为核心数据存储，但逐步将不适合的workload迁出
视频核心观点：OpenAI的策略本质上是"能不分片就不分片，但为分片留好退路"。这是一种非常成熟的架构思维——不做过度工程，但随时准备应对下一个数量级的挑战。
视频还讨论了OpenAI的高可用架构：主库配备了一个热备（Hot Standby），与主库完全同步。一旦主库故障，热备可以在秒级接管。
但这个过程远非"切个开关"那么简单： - 所有50个只读副本需要断开与旧主库的连接，重新连接到提升后的热备 - 连接重建过程中的任何失败都可能导致数据不一致或服务中断 - 应用层的连接字符串需要动态更新
OpenAI在博客中特别感谢了微软Azure团队的执行能力——这一系列复杂操作在Azure的支撑下执行得"近乎完美"。但代价也不菲：热备需要一台与主库规格完全相同的虚拟机，OpenAI使用的是Azure能提供的最强配置。
视频中一个令人印象深刻的工程教训：OpenAI发现某条查询同时JOIN了12张表，这条查询的CPU消耗与大量高严重级事故直接相关。
教训很直接：在超大规模系统中，一条设计不当的查询可以拖垮整个数据库。OpenAI的团队学会了： - 避免复杂的多表JOIN - 对高频查询建立精确的索引策略 - 在应用层预计算或缓存复杂查询的结果 - 为查询性能建立持续监控和告警机制
mindmap
root((OpenAI Postgres<br/>规模化架构))
核心架构
单主多从
1个Primary Writer
~50个Read Replicas
PgBouncer连接池
连接复用
50ms → 5ms
Hot Standby热备
故障自动转移
Azure底座支撑
性能优化
缓存层
Redis/类似方案
缓存雪崩防御
查询优化
避免12表JOIN
精确索引策略
应用层优化
批量写入
合并请求
扩展策略
读扩展
线性扩展读副本
读路由分发
写扩展
迁移至Cosmos DB
应用层写入优化
暂不分片PostgreSQL
风险管理
缓存雪崩
正反馈恶性循环
限流与断路器
MVCC写瓶颈
Table Bloat
VACUUM性能限制
连接风暴
连接数上限
资源耗尽
1. 先理解workload，再选架构。 OpenAI能撑住8亿用户的核心不是技术有多花哨，而是对ChatGPT"读多写少"特征的精准判断。很多团队在日活还不到10万时就开始规划分片方案，这往往是过早优化（premature optimization）。先用单主架构+读副本扛住读压力，把工程精力放在业务逻辑上，等到写瓶颈真正出现时再迁移——这才是OpenAI给我们的最佳实践。
2. 连接池化是性价比最高的第一道防线。 PgBouncer的部署成本极低，效果立竿见影（10倍延迟降低）。如果你的应用还没有使用连接池中间件，这应该是你今天就要加的配置。
3. 缓存是双刃剑，必须设计降级方案。 OpenAI用惨痛教训告诉我们：缓存失效的瞬间可能是系统最脆弱的时刻。每个引入缓存层的系统都应该回答一个问题——"如果缓存全部失效，我的数据库能不能扛住？"如果不能，你需要限流、断路器和多级缓存。
4. 查询审查应该成为上线流程的一部分。 一个12表JOIN毁掉整个系统——这不是段子，而是OpenAI的真实事故。在你的CI/CD流水线中加入SQL审查（比如检测超过3个JOIN的查询），可能比加更多服务器更有效。
PostgreSQL仍然是大多数场景的最佳默认选择，但你需要知道它的天花板在哪里。如果你的写入量达到每秒数十万级别，而且增长率很快，就该提前研究替代方案了。OpenAI选择了"Azure Cosmos DB承接写密集型workload"的混合策略，这提供了一个很好的参考模式——不要追求一个数据库解决所有问题，而是让每个数据库做它最擅长的事。
OpenAI用8亿用户的实战案例证明：架构选型的最高境界不是追求技术先进性，而是在正确的时间选择务实的方案，并为下一个数量级留好退路。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。