由 John Doe 一月 23, 2026
Postgres 是未来十年人工智能应用的坚实基础。它为团队提供了所需的灵活性、性能和成本控制力。
作者：罗布·潘科
目录
前言
过去几年里，我见证了数据库领域历经一波又一波的热潮与失望。向量数据库、图数据库、多模态数据库和 NoSQL 系统轮番成为焦点。每一波技术浪潮都承诺简化开发流程、解锁全新可能。有些兑现了承诺，有些则未能如愿，但大多数在当时的场景下都具备其合理性。
随后，人工智能时代来临。人工智能并非简单拓展现有系统的边界，而是打破了塑造上一代托管数据库服务的核心假设，暴露了在工作负载较轻、变化速度较慢时容易被忽视的潜在取舍问题。
它还促使团队重新思考数据处理方式。如今，市场已出现明显转向：企业正纷纷回归到 Postgres，越来越多的新应用在技术栈中首选 Postgres。Postgres 正成为人工智能领域的主流数据库，如今工程师开发新应用时，极有可能在技术栈中纳入 Postgres。它无疑是 2025 年最受欢迎的数据库系统。
我想解释这一转变背后的原因（至少是我的浅见），阐述为何 Postgres 正悄然成为现代 AI 应用开发的核心支柱，同时说明为何许多团队应考虑脱离完全托管式数据库。
这并非出于怀旧情结或传统意义上的自建部署，而是一种新模式，既保留托管服务的优势，又能为团队提供未来十年所需的性能、成本控制力和数据本地化能力。这种新模式便是 BYOC（自带云环境，Bring Your Own Cloud）。
AI 业务负载如何打破托管数据库模式
整个托管数据库生态系统是在业务负载可预测的时代发展起来的。将本地系统迁移至云端是亚马逊关系型数据库服务（RDS）、Azure 托管 SQL 等服务增长的核心动力。迁移流程简单直接：先将系统迁移至基础弹性计算云（EC2）实例，再转移至 RDS。这是一套标准化操作手册，几乎所有企业都照此执行，堪称理所当然的选择。
当时的大多数应用都属于典型的软件即服务（SaaS）产品：工作数据集规模适中，采用简单的在线事务处理（OLTP）模式，呈渐进式扩展，严重依赖网络附加存储、自动扩展组和稳定的索引结构。那时的性能通常足够用，延迟在可接受范围内，成本也易于管控。然而，AI 的出现彻底改变了这一切。
AI 业务负载的特性截然不同：具有突发性、依赖大规模并行计算、采用向量搜索和高维嵌入技术、持续摄入海量数据集，还需要频繁开展实验、快速克隆数据库以及创建多个隔离环境。更重要的是，它要求计算节点与数据存储之间在物理上保持紧密耦合。这种新旧模式的差异所产生的矛盾，是托管数据库再也无法掩盖的。
我每周都会与工程团队交流，他们的经历高度相似：在模型部署阶段尝试扩展托管 Postgres 实例时，总会遭遇 IOPS（每秒输入 / 输出操作数）限制、限流窗口，在最需要性能可预测性的关键时刻出现延迟峰值；同时，由于确保安全的唯一方式是过度配置每个环境，导致成本飙升。这些问题起初逐渐累积，一旦人工智能工作负载达到生产规模，便会变得难以管控。
正是在这个节点，团队开始质疑托管模式本身的合理性。
现代开发向 Postgres 的集中化趋势
如今，几乎所有主流数据库厂商都在谈论 PostgreSQL 兼容性。部分厂商仅将其视为营销手段，出于 “错失恐惧”（FOMO）而急于 “搭上 Postgres 的顺风车”。目前尚不清楚它们的产品能为竞争激烈的 Postgres 市场带来何种独特价值，但这些厂商先入局再说，后续再考虑市场推广策略；另一些厂商则围绕 Postgres 重构了整个数据库引擎。
这些厂商之所以这么做，是因为它们预判到了开发者的核心需求：开发者需要稳定且易于理解的 SQL 系统、强大的事务支持、可预测的连接操作、广泛的工具链支持，希望数据库不会将自己锁定在单一厂商或架构中，并且青睐开源方案。
Postgres 经过数十年的优化完善，这是新兴系统无法比拟的，它经过了生产环境的充分验证，稳定性极强。
Postgres 在提供上述所有优势的同时，并未强制团队采用专业化模式。它具备足够的灵活性：既可作为 OLTP 引擎，也能处理分析型工作负载；既能存储向量数据，也能运行时间序列任务，还可作为缓存使用。其扩展插件几乎覆盖所有场景，再加上数十年的技术沉淀和生产环境验证，稳定性无可挑剔。
AI 进一步强化了这种集中化趋势。AI 团队希望减少系统组件数量、简化数据管道，同时需要事务安全性与分析能力兼备，他们没有时间去钻研全新的数据库架构。
在这个快速发展的新兴市场中，团队需要快速迭代：无需维护独立的向量存储即可实现向量搜索；无需复杂的数据同步任务，就能在真实数据上测试新功能；能够跨数据模型执行查询。Postgres 让团队有机会将这些工作负载统一到单一系统中。
我发现越来越多的团队开始精简数据栈的层级，因为他们意识到，只要配备合适的基础设施，Postgres 就能满足其绝大多数需求。这不仅能降低延迟、减少运维意外、简化开发流程，更重要的是，能获得一个同时适配应用程序和人工智能管道的、易于理解的统一数据系统。
这种转变并非理论层面的探讨，而是体现在整个行业的产品路线图中。
为何托管 Postgres 无法应对 AI 规模
我们已经明确 Postgres 成为新的技术重心，接下来的问题是：在哪里、以何种方式运行它？多年来，标准答案很简单：使用 RDS、Aurora 或 Cloud SQL。这些服务的核心卖点是：让别人来管理 Postgres。
“数据库管理员（DBA）的时代已经过去”， 他们如是说。大多数开发者对此表示认同，因为这将基础设施管理从关键路径中移除，降低了运维开销，并将数据库管理责任转移给了云厂商。
但这种模式存在隐藏的约束：托管数据库本质上是 “一刀切” 的解决方案。用户严重依赖网络存储，不得不接受网络延迟、固定 IOPS 限制、数秒级冷启动，以及这些设计带来的成本结构。十年前，这些取舍或许是合理的，但在 2025 年的今天，为何还要为 IOPS 付费？尽管现代非易失性内存主机控制器接口规范（NVMe）已经改变了存储格局，但定价模型仍将 IOPS 视为稀缺资源。
AI 业务负载需要极快的存储速度和可预测的性能，还需要频繁创建大型数据库克隆以支持测试和实验，而托管数据库在这两方面都举步维艰。托管系统的内部存储层造成了无法避免的瓶颈，其克隆机制依赖快照恢复周期或完整的物理副本，这两种方式都既缓慢又昂贵，在大规模场景下尤为突出。
一旦团队遭遇这些限制，唯一的解决办法就是过度配置：不断扩大实例规模、维持超大规格的副本、24 小时运行完整的预发环境（即便大部分时间处于闲置状态）。最终，成本增长速度远超产品发展速度，这与 AI 时代团队的核心诉求背道而驰。
也正是在这个时候，团队开始寻找替代方案：既能发挥 Postgres 的全部能力，又不受托管系统的限制。
BYOC 模式 Postgres 的崛起
我发现，所有构建核心人工智能功能的团队都在采用一种新模式：他们希望在自己的云账户中运行 Postgres，掌控计算和存储资源，实现数据与 GPU 的同节点部署，获得无限制的 IOPS。但最重要的是，他们仍希望享受自动化服务带来的优势，比如备份、复制和监控功能。
这就是 BYOC 模式。它并非传统的自建部署，而是在企业自有云环境中运行的托管平台：企业可完全掌控基础设施，保留云厂商提供的折扣，维持现有的安全态势，同时控制数据的物理存储位置，这对于数据驻留要求和监管合规至关重要。
这种模式天然契合 SOC 2、HIPAA、GDPR、CCPA 等合规框架：数据始终不会离开企业账户，加密由企业自有密钥管控，密钥管理与现有密钥管理服务无缝集成，租户隔离遵循企业在整个基础设施中信任的边界规则。
平台会处理备份、复制、升级、故障处理等复杂运维工作，而企业则保留对策略、访问权限和审计边界的控制权。对于许多团队而言，这是托管 Postgres 首次真正适配其安全合规模型，而非与之冲突。
数据本地化与本地存储如何提升性能
BYOC 模式还具备另一大优势：借助合适的工具，该模式可消除网络存储瓶颈，彻底解决性能问题。以 Vela 为例，这类解决方案允许将 Postgres 部署在存储所在的同一实例上，充分利用实例附带的本地 NVMe 设备的速度和性能。其底层采用分布式块存储，不仅提供了本地存储所不具备的弹性、可扩展性和写时复制（copy-on-write）功能，还能在企业自有云中完成部署和管理。企业只需配置带有本地 NVMe 设备的云实例即可。
最终效果显著：存储延迟降至微秒级，IOPS 限制不复存在，并行摄入不仅可行，更成为发挥数据库极限性能的必要条件；大规模向量索引重建时不再对系统造成负担，即便在高负载下，查询性能依然保持稳定。
BYOC 模式还解决了成本问题：企业直接向云厂商支付计算、内存和存储费用，无需支付任何溢价、IOPS 费用，也无需强制过度配置多个全规格环境。企业只需运行实际所需的计算资源，额外环境可在几秒内启动（无论是否包含现有数据集）。这种模式与数据库克隆功能结合使用时，效果尤为突出。
这就引出了一个最关键的工作流程转变。
克隆与分支成为 AI 应用开发的核心
AI 应用开发依赖快速实验：团队需要在真实数据上测试新模型、验证提示词和嵌入向量、执行数据迁移、隔离功能分支、重放事件、安全评估数据管道。这类工作流程需要源源不断的干净环境支持。
传统托管数据库通过复制整个数据集来创建克隆，这种方式缓慢、昂贵且浪费资源，限制了可维护的环境数量，迫使开发者走捷径，且每次克隆都需要耗费大量时间，导致测试延迟。
一旦团队体验过基于克隆的工作流程，就很难再回到过去的模式。
现代 Postgres 平台通过基于写时复制（copy-on-write）语义的瘦克隆（thin clones）改变了这一现状：克隆可即时启动（因为它与生产数据库共享底层数据），仅当克隆数据发生偏离时才会增加存储消耗，性能始终保持稳定。团队可创建任意数量的克隆，将其附加到 CI 管道并实现自动化，直接与功能分支关联，测试结束后即可销毁。
这种模式完美适配人工智能开发：无需等待 TB 级数据复制即可开展并行实验，能够跨环境对比结果，在部署变更前建立足够信心，同时减少所需支付的全规格数据库数量。
一旦团队体验过基于克隆的工作流程，就很难再回到过去的模式。
Postgres 生态系统对 AI 的重要性
人工智能系统通常依赖多种专业数据库：用于产品的事务型数据库、用于嵌入向量的向量存储、用于分析的数仓、用于指标的时间序列系统、用于检索的全文搜索引擎，以及在这些系统之间传输或同步数据的管道。这种架构导致数据需不断移动，进而增加了系统复杂性和成本。
Postgres 的核心优势之一在于其生态系统。得益于社区支持，Postgres 通过 pgvector 插件支持嵌入向量搜索；借助 NVMe 存储消除了许多历史读取瓶颈（PostgreSQL 18 还新增了异步读取支持），能够处理中低规模的分析型工作负载；无论是否使用扩展插件，都能支持时间序列数据；通过物化视图实现缓存模式；通过逻辑复制支持事件摄入和流处理；同时仍以其标志性的强一致性支持 OLTP 工作负载。
能够在单一系统中运行所有这些工作负载，彻底改变了人工智能后端的架构形态：组件数量减少、数据本地化降低延迟、部署模式简化、管道可重现、运维开销减少。
Postgres 生态系统赋予了数据库 “超越单纯存储工具” 的能力，而这正是 AI 时代所有人真正需要的。SQL 是一项拥有 50 年历史的技术，其（重新）被广泛采用绝非倒退，而是一次进步。Postgres 提供了稳定的基础，其价值则通过生态系统的其他层级得以释放。
开发者效率：转变背后的隐藏驱动力
性能和成本易于量化，但开发者效率虽难以衡量，却同样重要。人工智能开发涉及持续迭代，开发者需要快速反馈，人工智能智能体需要更快的反馈，两者都需要安全的环境。开发者还需要可靠的方式来测试模式变更，并在真实数据上验证新想法，而无需担心风险。
我坚信，托管数据库从设计之初就并非为开发者构建现代应用而准备。它们不支持基于克隆或分支的工作流程，仅能提供稳定的端点，所有其他操作都需在数据库外部完成。这扩大了代码变更与数据库变更之间的差距，增加了数据库与应用程序之间的数据传输量，进而减缓了反馈循环。
现代 Postgres 平台（如 Vela、Neon、Supabase）填补了这一空白。它们为开发者提供了创建分支、运行测试、合并变更的简洁界面，使数据库成为开发流程的一部分，而非遥远的服务。最终结果是：迭代速度加快，生产环境中的意外情况减少。
一旦团队体验过这种工作流程，就会开始质疑为何曾经要接受速度更慢的模式。这种转变对发布周期的影响是可量化的：开发者等待时间减少，编码时间增加，更早发现问题，部署时更有信心。
效率已成为一项战略优势，能够更快测试和交付的团队每周都在扩大领先优势。支持分支和克隆功能的 Postgres 恰好适配这种快节奏，提供了手动流程永远无法实现的安全保障。
为何一切都在回归 Postgres？
在与数百个团队交流并观察其基础设施演变后，我坚信，回归 Postgres 绝非临时趋势，而是人工智能和现代应用开发需求推动下的长期修正。
Postgres 兼具完善的功能、成熟的技术和强大的可扩展性：适用于 OLTP、中低规模 OLAP、向量搜索、时间序列、实时分析、事件驱动系统。在大多数情况下，它能适配任何类型的业务负载。
问题从来不在于 Postgres 本身，而在于其运行环境。托管系统的设计已不再满足人工智能的需求，而 BYOC 平台解决了这一问题：它结合了自建部署的控制权与托管服务的便利性，让团队在保留云账户和安全态势的同时，获得具备即时克隆功能和现代存储的高性能 Postgres。
这种模式使 Postgres 重新成为架构核心，也将控制权交还给了依赖它的团队，而 AI 恰好需要这种级别的控制权。
新一代技术栈围绕 “自有云中的 Postgres” 构建，并由一个处理复杂运维工作的平台提供支持。
这就是所有人都在重返 Postgres 的原因：它是未来十年 AI 应用的坚实基础，为团队提供所需的灵活性、性能和成本控制力，让开发者能够自信地构建产品，并以契合现代开发速度的方式简化整个数据生态。
我相信，这一转变才刚刚开始。下一代 AI 平台不会建立在零散的专业系统之上，而是将基于统一的数据基础，这个基础就是 Postgres。它将靠近计算资源运行，处理所有工作负载，并让团队完全掌控其最重要的资产：数据。
参考
Rob Pankow：Why AI Workloads Are Fueling a Move Back to Postgres