Postgres因通用性和稳定性成AI数据库核心。AI高负载挑战传统托管，BYOC模式结合本地存储和瘦克隆，提供高性能、低成本Postgres，是AI应用基石。
译自：Why AI Workloads Are Fueling a Move Back to Postgres
作者：Rob Pankow
在过去几年里，我一直在关注数据库领域，它经历了从兴奋到失望的波浪式发展。向量、图、多模态和NoSQL系统都曾轮流成为焦点。每一波浪潮都承诺更简单的开发和新的可能性。有些实现了，有些没有。大多数在当时看来都是有意义的。
随后，AI到来了。AI不仅仅是扩展了现有系统，它打破了塑造上一代托管数据库服务的假设。它揭示了在工作负载较轻、变化较慢时容易被忽视的隐性权衡。
它还促使团队重新思考如何处理数据。如今，我看到市场出现了明显的转变。团队正在回归Postgres。越来越多的新应用开始在技术栈中使用Postgres。Postgres正在成为AI的数据库。如果工程师今天正在构建某个新应用，他们很可能会在技术栈中使用Postgres。截至目前，它将是2025年最流行的数据库系统。
我想解释为什么会发生这种转变（至少在我拙见看来）。我想描述为什么Postgres正在悄然成为现代AI开发的支柱。我还想解释为什么许多团队应该考虑放弃完全托管的数据库。
这并非是对旧时代自托管的怀旧。它关乎一种新模式，这种模式在保留托管服务优势的同时，为团队提供了未来十年所需的性能、成本控制和数据局部性。新模式是BYOC（带上你自己的云）。
AI工作负载如何打破托管数据库模式
整个托管数据库生态系统是在工作负载可预测的时期发展起来的。将工作负载“提升并转移”到云端是Amazon Relational Database Service (RDS)或Azure Managed SQL等服务增长的支柱。首先，你将工作负载“提升并转移”到普通的Elastic Compute Cloud2 (EC2)实例上，然后迁移到RDS。这是一个简单的操作手册，每个人都这样做，毫不费力。
大多数应用程序表现得像经典的软件即服务（SaaS）产品。它们具有适度的内存工作集。它们使用直接的在线事务处理（OLTP）模式。它们逐渐扩展。它们严重依赖网络附加存储、自动伸缩组和稳定的索引结构。性能通常足够好。延迟可接受。成本可控。然后，AI出现了。
AI工作负载表现截然不同。它们具有突发性。它们依赖于高度并行性。它们使用向量搜索和高维嵌入。它们持续摄取大量数据集。它们需要频繁的实验、快速克隆和许多隔离的环境。它们还需要计算节点和数据存储之间紧密的接近性。新旧模式之间的差距产生了托管数据库无法再隐藏的摩擦。
我每周都会与工程团队交流。他们都描述了类似的经历。他们在模型部署期间尝试扩展托管的Postgres实例。他们达到了IOPS限制。他们遇到了节流窗口。在他们最需要可预测性的时刻，他们看到了延迟峰值。他们还看到了成本爆炸，因为保持安全的唯一方法是过度配置每个环境。这些问题一开始是缓慢积累的，一旦AI工作负载达到生产规模，它们就变得无法管理。
这就是团队开始质疑托管模式本身的时刻。
现代开发中对Postgres的趋同
几乎所有主要的数据库供应商现在都在谈论PostgreSQL兼容性。有些将其视为简单的营销手段。他们感到FOMO（错失恐惧症），希望“搭上Postgres的船”。目前尚不清楚他们的产品如何为已经竞争激烈的Postgres市场增值，但他们首先跳上船，稍后再担心市场策略。其他人则围绕Postgres重建了整个引擎。
这些供应商这样做是因为他们预见了开发者的需求。开发者需要一个稳定且广为人知的SQL系统。他们需要强大的事务。他们需要可预测的连接。他们需要广泛的工具支持。他们需要一个不会将他们锁定在单一公司或架构中的数据库。他们需要开源。
Postgres拥有数十年的精炼，这是新系统无法比拟的。它经过生产验证，坚如磐石。
Postgres提供了所有这些功能，而无需将团队限制在专业模型中。它足够灵活，可以作为OLTP引擎。它能够处理分析。它能够存储向量。它能够运行时间序列工作负载。它能够作为缓存。它几乎拥有所有功能的扩展。它拥有数十年的精炼，这是新系统无法比拟的。而且它经过生产验证，坚如磐石。
AI强化了这种融合。AI团队希望更少的活动部件。他们希望更简单的管道。他们希望事务安全性与分析能力相结合，因为他们没有时间研究新的数据库架构。
他们希望在这个新兴市场中快速行动。他们希望进行向量搜索，而无需维护单独的向量存储。他们希望在真实数据上测试新功能，而无需复杂的Ddata同步作业。他们希望跨数据模型进行查询。Postgres为他们提供了在一个地方统一这些工作负载的机会。
我看到更多的团队正在移除其数据栈的整个层次，因为他们意识到，在正确的基础设施支持下，Postgres可以处理他们绝大部分的需求。
他们获得了更低的延迟。他们遇到了更少的运维意外。他们获得了更简单的开发工作流。最重要的是，他们获得了一个单一、易于理解的数据系统，既适用于应用程序，也适用于AI管道。
这种转变并非理论上的。它在整个行业的产品路线图中都可见一斑。
为什么托管Postgres无法处理AI规模
我们现在已经确定Postgres是新的重心。下一个问题是在哪里以及如何运行它。多年来，默认的答案很简单。使用RDS。使用Aurora。使用Cloud SQL。推销很简单：让别人来运行Postgres。
他们说：“DBA的时代已经过去。”大多数开发者喜欢这个主意。它将基础设施责任从关键路径中移除。它减少了运维开销。它将管理数据库的责任转移给了云供应商。
但这种模式有一个隐藏的限制。托管数据库意味着一刀切的解决方案。用户严重依赖网络存储。他们接受网络延迟。他们接受固定的IOPS限制。他们接受多秒的冷启动。他们接受这些设计带来的成本结构。这些权衡在10年前是合理的。但为什么你需要在2025年为IOPS付费呢？定价模型仍然将IOPS视为稀缺资源，尽管现代Non-Volatile Memory Express (NVMe)改变了这种局面。
AI工作负载需要极快的存储和可预测的性能。它们还需要大量且频繁的数据库克隆用于测试和实验。
托管数据库在这两个方面都表现不佳。托管系统的内部存储层会产生不可避免的瓶颈。克隆机制依赖于快照-恢复周期或完整的物理复制。这两种方法都缓慢且昂贵，尤其是在大规模部署时。
一旦团队达到这些限制，唯一的解决办法就是过度配置。你不断增加实例大小。你维护超大的副本。你每天24小时运行完整的预生产环境，即使它们处于空闲状态。你的成本增长速度快于你的产品。这与AI时代团队的需求背道而驰。
这就是团队开始寻找替代方案的时刻，这些方案能让他们充分发挥Postgres的全部力量，同时摆脱托管系统的限制。
BYOC Postgres的兴起
我看到在构建严肃AI功能的团队中，一种新模式正在出现。他们希望在自己的云账户中运行Postgres。他们想要控制计算和存储。他们希望将数据与GPU放在一起。他们想要无限的IOPS。但最重要的是，他们仍然希望获得自动化体验的优势，这种体验能提供备份、复制和监控。
这就是BYOC模式。它不是传统的自托管。它是一个在您自己的云环境中运行的托管平台。您可以完全控制基础设施。您保留您的云折扣。您保持您的安全态势。您还可以控制数据实际存储的位置，这对于数据驻留和法规要求至关重要。
这种模式自然符合SOC 2、HIPAA、GDPR和CCPA等合规框架。数据永不离开您的账户。加密由您自己的密钥处理。密钥管理与您现有的密钥管理服务设置集成。租户隔离遵循您在其余基础设施中已经信任的相同边界。
该平台负责处理备份、复制、升级和故障处理等运维复杂性。您仍然可以控制策略、访问和审计边界。对于许多团队来说，这是托管Postgres首次真正符合其安全和合规模型，而不是与之冲突。
数据局部性和本地存储如何提升性能
为了进一步增加BYOC的优势，通过正确的工具，这种模式通过消除网络存储瓶颈来解决性能问题。诸如 Vela 这样的解决方案允许您在与存储位于同一实例上部署Postgres，利用连接到实例的本地NVMe设备的超高速度和性能。在“幕后”使用分布式simplyblock存储，它提供了弹性、可扩展性以及写时复制功能，这些功能是本地存储通常不具备的。所有这些都部署并管理在您自己的云中。您所需要做的就是提供一个带有本地NVMe设备的云实例。
结果如何？存储延迟降至微秒级别。IOPS限制消失。并行摄取不仅变得可行，而且成为达到数据库极限所需的条件。庞大的向量索引在重建期间不再惩罚系统。即使在高负载下，查询也保持可预测。
BYOC还解决了成本问题，因为您直接向云提供商支付计算、内存和存储费用。没有加价。没有IOPS费用。没有强制过度配置许多全尺寸环境。您只运行实际需要的计算资源，并且可以在几秒钟内启动额外的环境，无论是否包含现有数据集。当与数据库克隆结合使用时，此模型尤其有效。
这把我带到了最关键的工作流转变。
克隆和分支成为AI开发的核心
AI开发依赖于快速实验。团队需要在真实数据上测试新模型。他们需要验证提示和嵌入。他们需要运行迁移。他们需要隔离功能分支。他们需要重放事件。他们需要安全地评估管道。这种工作流需要持续的干净环境流。
传统托管数据库通过复制整个数据集来创建克隆。这种方法缓慢、昂贵且浪费。它限制了您可以维护的环境数量。它迫使开发者走捷径。它还延迟了测试，因为每个克隆都需要实际时间来生成。
一旦团队体验了基于克隆的工作流，他们就很少会再回到过去。
现代Postgres平台通过依赖写时复制语义的“瘦克隆”改变了这一点。克隆可以立即启动，因为它与生产数据库共享底层数据。存储消耗仅随克隆数据的分歧而增长。性能保持稳定。您可以创建任意数量的克隆。您可以将它们连接到CI管道并实现自动化。您可以将它们直接与功能分支绑定。测试结束后即可销毁它们。
图1
这种模式完美契合AI开发。它让您无需等待数TB数据复制即可并行运行实验。它使您能够比较不同环境中的结果。它允许您在部署更改之前建立信心。它还减少了您需要付费的全尺寸数据库的数量。
一旦团队体验了基于克隆的工作流，他们就很少会再回到过去。
Postgres生态系统对AI的重要性
AI系统通常依赖于许多专用数据库。您有用于产品的事务性数据库。您有用于嵌入的向量存储。您有用于分析的数据仓库。您有用于指标的时间序列系统。您有用于检索的全文搜索引擎。您有在它们之间移动或同步数据的管道。这种架构增加了复杂性和成本，因为数据必须不断移动。
图2
Postgres的主要优势之一是其生态系统。得益于其社区，Postgres通过pgvector处理嵌入式搜索。它在中低规模下处理分析工作负载，因为NVMe支持的存储消除了许多历史读取瓶颈（并且PostgreSQL 18增加了异步读取支持）。它处理带或不带扩展的时间序列数据。它通过物化视图处理缓存模式。它通过逻辑复制处理事件摄取和流处理。它仍然以其强大的数据一致性处理OLTP。
在单一系统上运行所有这些工作负载的能力改变了AI后端的形态。您获得了更少的活动部件。您获得了更低的延迟，因为数据保持本地化。您获得了更简单的部署模式。您获得了可重现的管道。您获得了更少的运维开销。
Postgres生态系统提供了将数据库变成“不仅仅是数据库”的能力，这正是AI时代每个人真正想要的。SQL是一项有50年历史的技术，它的（重新）采用绝不是倒退。它旨在向前迈进。Postgres提供了一个稳定的基础，而其生态系统的其他层则提取了价值。
开发者效率：转变的隐藏驱动力
性能和成本很容易衡量。开发者效率更难以量化，但同样重要。AI开发涉及持续迭代。开发者需要快速反馈。AI代理需要更快的反馈。两者都需要安全的环境。开发者还需要一种可靠的方式，在不担心的情况下，在真实数据上测试模式更改和验证新想法。
我坚信，托管数据库从未被设计用于开发者在其上构建现代应用程序。它们不提供基于克隆或基于分支的工作流。它们被设计为提供一个稳定的端点。其他一切都发生在数据库之外。这增加了代码更改和数据库更改之间的差距，并增加了数据库和应用程序之间传输的数据量。它也减慢了反馈循环。
现代Postgres平台，例如Vela、Neon或Supabase，弥合了这一差距。它们为开发者提供了创建分支、运行测试和合并更改的简单界面。数据库就像开发过程的一部分，而不是一个遥远的服务。结果是更快的迭代和更少的生产环境意外。
一旦团队体验了这种工作流，他们就会开始质疑为什么他们曾经接受了较慢的模型。对发布周期的影响是可测量的。开发者等待的时间更少。他们花费更多时间构建。他们更早地发现问题。他们部署时更有信心。
效率成为一种战略优势。能够更快地测试和发布产品的团队每周都能取得更大的进展。支持分支和克隆的Postgres支持这种速度。它为您提供了您一直想要但无法通过手动流程实现的“安全网”。
那么，为什么一切都在回归Postgres？
在与数百个团队交流并观察他们的基础设施演变之后，我相信回归PostgreSQL并非短期趋势。这是由AI和现代应用程序开发需求所带来的长期路线修正。
Postgres拥有功能、成熟度和可扩展性的正确组合。它适用于OLTP。它适用于合理规模的OLAP。它适用于向量搜索。它适用于时间序列。它适用于实时分析。它适用于事件驱动系统。在大多数情况下，它适用于任何类型的工作负载。
问题从未出在Postgres本身。问题在于Postgres运行的环境。托管系统使用的设计已不再适合AI的需求。BYOC平台解决了这个问题。它们将自托管的控制力与托管服务的便利性相结合。它们让团队保留自己的云账户和安全态势，同时获得具有即时克隆和现代存储功能的高性能Postgres。
这种模式将Postgres重新带回架构的中心。它也将控制权交还给依赖它的团队。AI需要这种程度的控制。
新的技术栈围绕您自己的云中的Postgres构建，并由一个处理运维复杂性的平台提供支持。
这就是为什么每个人都在回归Postgres的原因。它是未来十年AI应用的正确基础。它为团队提供了所需的灵活性、性能和成本控制。它让开发者充满信心地进行构建。它以与现代开发速度相匹配的方式简化了整个数据格局。
我相信这种转变才刚刚开始。下一代AI平台将不会建立在一堆专用系统的拼凑之上。它们将建立在统一的数据基础之上。这个基础就是Postgres。它将靠近计算运行。它将处理所有工作负载。它将赋予团队对其最重要资产——数据——的完全控制权。
