核心要点
- PostgreSQL 的扩展上限远超预期： 通过系统性优化，单主节点架构配合近 50 个只读副本，可支撑每秒数百万次查询，服务 8 亿用户。
- 读多写少是关键前提： OpenAI 的核心工作负载以读为主，写密集型任务已迁移至 Azure Cosmos DB 等分片系统，从而避免了 PostgreSQL 的 MVCC 写放大瓶颈。
- 连接管理与缓存策略缺一不可： PgBouncer 连接池大幅降低连接开销，多层缓存（Redis + 应用层缓存）承担了大部分读流量。
- 监控和工具建设要趁早： 自动化查询分析、回归检测和部署工具是保障大规模系统稳定运行的基础。
- 理解极端负载下的行为模式： 缓存击穿、写风暴、重试雪崩等故障模式的预判与应对，决定了架构的韧性。
文章信息
- 来源： OpenAI Blog
- 发布日期： 2026-02-01
- 原文： English Original
多年来，PostgreSQL 一直是驱动 ChatGPT 和 OpenAI API 等核心产品的关键底层数据系统之一。随着用户规模的快速增长，数据库承受的压力也呈指数级上升。在过去一年中，我们的 PostgreSQL 负载增长了超过 10 倍，而且仍在持续攀升。
为了让生产基础设施跟上这一增长节奏，我们在实践中获得了一个新认知：PostgreSQL 在读密集型工作负载下的扩展能力，远超许多人此前的预期。这套系统（最初由加州大学伯克利分校的科学家团队创建）使我们能够通过单个 Azure PostgreSQL 灵活服务器主实例配合近 50 个分布在全球多个区域的只读副本，支撑大规模的全球流量。本文将讲述我们如何通过严谨的优化和扎实的工程实践，将 PostgreSQL 扩展到每秒支撑数百万次查询、服务 8 亿用户的历程，并分享我们在此过程中获得的关键经验。
ChatGPT 上线后，流量以前所未有的速度增长。为了应对这一局面，我们迅速在应用层和 PostgreSQL 数据库层实施了大量优化，通过增加实例规格进行纵向扩展，同时通过添加更多只读副本进行横向扩展。这套架构在很长一段时间内运行良好，随着持续改进，它仍然为未来增长提供了充足的空间。
单主节点架构能满足 OpenAI 这一规模的需求，听起来可能令人意外；但在实践中让它稳定运行并非易事。我们经历过多次由 PostgreSQL 过载引发的严重事故（SEV），它们往往遵循相同的模式：上游问题导致数据库负载突然飙升——比如缓存层故障引发的大面积缓存穿透、大量昂贵的多表连接查询耗尽 CPU、或新功能上线带来的写入风暴。随着资源利用率攀升，查询延迟上升，请求开始超时。重试请求进一步放大负载，触发恶性循环，可能导致整个 ChatGPT 和 API 服务的全面降级。
尽管 PostgreSQL 在我们的读密集型工作负载下扩展性良好，但在高写入流量期间仍然面临挑战。这主要是因为 PostgreSQL 的多版本并发控制（MVCC）实现在写密集型场景下效率较低。例如，当一个查询更新一个元组甚至仅更新单个字段时，整行都会被复制以创建新版本。在高写入负载下，这会导致严重的写放大问题。同时也增加了读放大——因为查询必须扫描多个元组版本（死元组）才能获取最新数据。MVCC 还带来了其他挑战，如表和索引膨胀、索引维护开销增加，以及复杂的 autovacuum 调优需求。
为了缓解这些局限并减轻写入压力，我们已将可分片的写密集型工作负载（即可以进行水平分区的工作负载）迁移到 Azure Cosmos DB 等分片系统，并持续推进这一迁移过程，同时优化应用逻辑以减少不必要的写入。我们也不再允许向当前的 PostgreSQL 部署中添加新表，新的工作负载默认使用分片系统。
即便基础设施在不断演进，PostgreSQL 依然保持未分片状态，由单个主实例承担所有写入。其首要原因在于，对现有应用工作负载进行分片将极其复杂且耗时，需要修改数百个应用端点，可能需要数月甚至数年。由于我们的工作负载以读为主，且已实施了大量优化，当前架构仍有充足的余量支撑持续的流量增长。虽然我们不排除未来对 PostgreSQL 进行分片，但鉴于当前和未来增长的充足空间，这并非近期优先事项。
我们最先遇到的瓶颈之一是连接管理。随着近 50 个只读副本和数千个应用实例的运行，数据库连接数迅速膨胀。我们在每个 PostgreSQL 实例前部署了 PgBouncer 作为连接池，大幅降低了数据库服务器的连接开销。
我们在查询优化上投入了大量精力，识别并重写了最昂贵的查询。具体措施包括添加缺失的索引、重写复杂的连接查询，以及为频繁访问的聚合数据实现物化视图。我们还构建了内部工具，能够自动检测查询性能退化并向值班工程师发出告警。
我们实施了多层缓存策略，结合 Redis 和应用内缓存来分担 PostgreSQL 的负载。缓存层处理了绝大部分读流量，PostgreSQL 作为缓存未命中和写入操作的数据源。
我们构建了智能副本路由机制，根据各副本的当前负载和复制延迟将读流量分配到不同副本。这确保了不会有单个副本成为瓶颈，同时用户始终能获取到最新数据。
PostgreSQL 的扩展能力超乎想象。 通过合理优化，单主节点 PostgreSQL 架构可以支撑大规模应用场景。
监控就是一切。 对查询模式、连接池和复制延迟的精细监控，是在问题演变为故障之前发现并解决它们的关键。
尽早投资工具建设。 自动化查询分析、回归检测和部署工具的回报远超投入。
为故障模式做好预案。 理解 PostgreSQL 在极端负载下的行为表现，帮助我们在架构中构建了更强的韧性。
PostgreSQL 依然是 OpenAI 基础设施的基石，我们期待在服务更多用户的过程中继续探索它的边界。