【PGCCC】OpenAI： 如何将 PostgreSQL 扩展到新的水平

在PGConf.dev 2025全球开发者大会上， OpenAI 的Bohan Zhang分享了 OpenAI 使用 PostgreSQL 的最佳实践，让人们得以一窥这家最著名的独角兽公司之一的数据库使用情况。

在 OpenAI，我们采用了一个包含一个写入器和多个读取器的未分片架构，这证明了 PostgreSQL
可以在海量读取负载下优雅地扩展。——PGConf.dev 2025，来自 OpenAI 的 Bohan Zhang

张博涵是OpenAI基础设施团队成员，师从卡内基梅隆大学Andy Pavlo教授，并与其共同创立了OtterTune 。

背景

PostgreSQL 是 OpenAI 核心数据库，支撑着其大部分关键系统。如果 PostgreSQL 发生故障，OpenAI 的许多关键服务将直接受到影响。过去曾发生过数起 PostgreSQL 相关问题导致 ChatGPT 中断的案例。

OpenAI 使用 Azure 上的托管数据库（Azure Database for PostgreSQL），采用经典的 PostgreSQL 主-副本复制架构，无需分片。此设置包含一个主数据库和数十个副本。对于像 OpenAI 这样拥有数百万活跃用户的服务来说，可扩展性是一个重要的考量因素。

挑战

在 OpenAI 的主-副本 PostgreSQL 架构中，读取可扩展性非常出色。然而，“写入请求”已成为主要瓶颈。OpenAI 在这方面实施了多项优化，例如尽可能地卸载写入负载，并避免在主数据库中添加新服务。

PostgreSQL 的多版本并发控制 (MVCC) 设计存在一些已知问题，包括表和索引膨胀。调整自动垃圾收集（清理）可能很复杂，因为每次写入操作都会生成一个全新的版本，并且索引访问可能需要额外的可见性检查。这些设计方面在扩展只读副本时带来了挑战：例如，增加预写日志 (WAL) 可能会导致更大的复制延迟，并且随着副本数量的显著增长，网络带宽可能成为新的瓶颈。

措施

针对这些问题，我们从多方面做出了努力：

控制主数据库负载

第一个优化是平滑主数据库上的写入峰值，以最小化其负载。例如：

• 卸载所有可能的写入操作。
• 避免在应用程序级别进行不必要的写入。
• 使用惰性写入来平滑写入突发。
• 控制数据回填期间的频率。

此外，OpenAI 致力于将尽可能多的读取请求卸载到副本数据库。对于那些由于属于读写事务而无法从主数据库中移除的读取请求，需要更高的效率。

查询优化

第二项优化侧重于查询层。由于长事务会阻碍垃圾回收并消耗资源，因此配置了超时机制以避免出现长时间的“事务空闲”会话，超时设置分别在会话、语句和客户端级别进行。此外，我们还优化了复杂的多连接