来源：https://stormatics.tech/blogs/postgresqls-growing-role-in-ai-infrastructure
PostgreSQL 在 AI 基础设施中日益增长的作用
作者: Annie Ghazali
日期: 2026 年 5 月 19 日
PostgreSQL，通常通过像 Lovable 这样的平台，正日益成为许多 AI 应用程序默认技术栈的一部分。这种采纳程度说明了工程团队将信任放在何处的重要信息。
PostgreSQL 不必将自己重新定位为"AI 数据库"就能实现这一点。使其对传统应用程序可靠的那些特性，也使其自然适合 AI 工作负载。随着越来越多的 AI 产品投入生产，工程团队开始花费更多时间思考 PostgreSQL 在并发下的行为、向量工作负载如何扩展，以及随着使用量增长，运维责任如何变化。
PostgreSQL，AI 应用程序的强大默认选择
PostgreSQL 如何深度嵌入 AI 基础设施
PostgreSQL 自 1986 年加州大学伯克利分校的 POSTGRES 项目开始以来，一直在持续开发。几十年来，它已成熟为一个以事务可靠性、可扩展性、复制和运维稳定性而闻名的数据库。这种可扩展性对 AI 应用程序变得尤为重要。
pgvector 扩展允许将嵌入和相似性搜索与事务性应用程序数据一起存放在 PostgreSQL 内部。对于许多团队来说，这保持了架构的简单性。无需引入单独的向量数据库，嵌入就可以在他们已经了解和运维的基础设施中进行存储和查询。
Lovable 进一步加速了这种采用。因为 Lovable 构建在 Supabase 之上，每个 Lovable 项目实际上都在其下创建了一个 PostgreSQL 部署。随着 Lovable 在"氛围编码"和 AI 辅助应用程序开发兴起的过程中获得关注，PostgreSQL 自然地在规模上更深地嵌入到 AI 开发生态系统中。
周围的生态系统通过主要 AI 框架直接支持 PostgreSQL 集成、云提供商提供成熟的托管 PostgreSQL 服务，以及 ORM 优先支持 PostgreSQL 来加强了这一方向。对于许多工程团队来说，PostgreSQL 成为了最实用的运维路径。
当 AI 工作负载增长时会发生什么变化
大多数 AI 应用程序开始时工作负载相对较小。查询延迟可控，嵌入数量有限，基础设施利用率不高。随着产品增长，工作负载会发生显著变化。随着嵌入数据集规模增大，向量搜索性能会发生变化。在开发期间运行良好的索引策略在更大的数据集和更高的并发下会开始表现不同。由检索管道、异步推理调用和混合搜索模式生成的工作负载给数据库带来的压力与传统应用程序流量不同。
运维症状通常逐渐出现：
- 并发推理活动期间的连接峰值
- 向量索引增长速度快于预期
- 负载下的延迟变得不一致
- 写密集型流量期间副本上的复制延迟增加
- 随着嵌入工作负载扩展，内存压力增大
连接管理也变得更加重要。AI 应用程序通常为每个请求生成多个并发数据库交互，这增加了 PostgreSQL 连接和内存使用的压力。以前从未考虑过 PgBouncer 或 Supavisor 的团队，通常在并发性增加时开始评估池化策略。
监控模式也在发展。传统的专注于事务查询延迟的仪表板并不总能足够早地显示向量索引行为、嵌入搜索延迟或检索特定的瓶颈。
PostgreSQL 继续支持工作负载，但数据库开始需要比大多数团队在原型阶段预期的更高级别的运维责任。
运维差距
在成长中的工程组织中，一种模式频繁出现。应用程序成功了，AI 功能被采纳了，产品开发速度仍然很快。与此同时，组织内部很少有人对 PostgreSQL 在生产压力持续下的行为有深入的了解。
这在很长一段时间内是可控的，因为 PostgreSQL 具有弹性和容错性。最终，工作负载会达到数据库行为变得更加明显的程度。一个大客户的引入、并发性的增加、更重的检索模式，或快速的产品增长开始暴露出从未重新审视过的运维假设。
在那个阶段，工程团队常常意识到数据库需要比以前更刻意的管理。这个问题并非 AI 应用程序独有，而 AI 工作负载只是加速了这些运维问题浮出水面的速度。
PostgreSQL 在 AI 领域的未来
关于 LLM 和检索系统是否可能最终降低结构化数据库重要性的讨论正在进行中。在实践中，AI 应用程序仍然严重依赖事务一致性、并发写入、访问控制、可审计性以及 AI 层之下可靠的运维系统。
随着应用程序从简单的原型发展到具有多个用户的生产环境，事务保证和运维可靠性变得越来越重要。PostgreSQL 通过 pgvector 的采用、跨 AI 工具的集成以及更广泛的生态系统支持，继续扩展到这种环境中。
PostgreSQL 在 AI 应用程序中的使用日益增长，反映了工程团队今天选择围绕 AI 产品构建运维系统的方式。
工程团队应尽早考虑什么
PostgreSQL 的运维债务往往会悄悄累积，但在 AI 应用程序中，工作负载的变化速度比大多数团队预期的要快。这通常通过反复出现的运维压力变得可见，例如：
- 在规模下同样的性能问题反复出现
- 在流量高峰期间对故障转移行为的不确定性
- 工程师花费越来越多的时间调查查询行为
- 基础设施成本增长速度超过工作负载增长
- 对升级或架构更改的犹豫增加
挑战很少来自 PostgreSQL 本身，主要是运维成熟度的发展速度慢于工作负载。AI 应用程序加剧了这种压力，因为并发性、向量搜索和检索密集型流量引入了许多团队以前从未大规模操作过的工作负载特性。在某个时刻，PostgreSQL 不再是背景基础设施，而成为团队的一个活跃的运维责任。
随着 PostgreSQL 成为 AI 产品下运维基础的一部分，这种转变正变得越来越普遍。随着工作负载增长，能够继续成功运维它的团队，通常是在压力迫使这些对话发生之前，就重新审视架构、工作负载行为和运维责任的团队。PostgreSQL 本身仍然可以很好地扩展。不同之处在于系统如何与其所使用的产品一起有意识地演进。