pgEdge：AI 编程助手造的数据库分支无法合并，这才是设计原意

AI 编码智能体（Agent）能快速跑起一个应用，但把原型带到生产环境是另一回事——开发阶段跑通的数据库配置，可能无法满足组织的安全、合规或部署要求。

本周一，pgEdge 推出了 Starfleet，这是一个基于标准社区版 Postgres 构建的云数据库平台，旨在弥合上述 Gap——将数据库分支能力和 Agent 工具链结合，部署方式从 pgEdge 托管服务到气隙（air-gapped）本地环境均可。

每个 Agent 对应一个数据库分支

并行运行多个编码 Agent，可以让每个 Agent 尝试解决同一问题的不同方案。但这在它们都操作同一个数据库时会变得非常棘手。因此 Starfleet 为每次实验提供了一个写时复制（copy-on-write）分支，且 pgEdge 表示没有用专有或半专有方案替换 Postgres 的存储层。

Databricks 则采用了不同方案，其 Lakebase 运行在 Neon 上，存储与计算分离使分支成为廉价的写时复制元数据操作，Postgres 页面存储在对象存储中。

pgEdge 未透露其分支系统的具体实现原理。从开发者视角看，一个新数据库以源数据库的副本开始，随后成为一个独立的隔离环境。两个环境之间的变更不会互通，各自拥有独立的连接信息。

这种隔离也延伸到了 Agent 工具链，每个环境有独立的 MCP server 地址和 bearer token。因此配置了源数据库凭证的客户端将无法连接到分支数据库。新分支在创建时会继承源数据库的 IP 白名单，且创建后无法修改。

如果 Agent 后续需要从新地址访问，开发者必须在源数据库的白名单中添加该地址，然后创建一个新的数据库分支——新分支从源数据库的数据开始，不包含旧分支的任何变更。

将分支与 Git 工作流关联

通过 CLI 关联项目文件夹时，数据库 ID（即分支 ID）会保存在 .pgedge/link.yaml 中，而 pgedge env pull 则将 DATABASE_URL 添加到文件夹的 .env 中。在功能分支上工作的 Agent 可以直接连接到对应的数据库环境，无需人工传递凭证。大多数读命令会自动使用关联的数据库，但通过分支链接时，只有连接命令指向分支，写操作需要 Agent 指定数据库 ID，这增加了一层检查以避免误操作错误的数据库。

最终没有数据库合并这一步。开发者按照已有的方式处理 schema 变更，使用 Alembic 或 Flyway 这类工具，而非 Starfleet 内置的方案。如果工作被合并，迁移文件随代码一起走，在源数据库上执行测试数据则留在原处，随 Agent 的数据库一起被删除。

实际运行中实验结束后清理这些环境是有实际原因的——每个数据库都有分支数量限制，且一旦分支准备好接受连接就开始计费，直到被删除为止。并行运行多个 Agent 的团队可能需要自动化这个清理流程。Yugabyte 正从集群层面解决类似问题，其平台通过 MCP 向 Agent 暴露了配置、分支、扩缩容、迁移和销毁能力。

带护栏的 MCP 访问

Starfleet 随 pgEdge 的 Agentic AI Toolkit for Postgres 一起发布，pgEdge CEO Phillip Merrick 将其描述为完全开源且对所有 Postgres 用户免费。该工具包包含一个 MCP server，允许编码 Agent 直接连接数据库。还包含一个 RAG API，利用 pgvector 检索存储在 Postgres 中的内容，以及一个 PostgREST API，为浏览器客户端提供直接的数据库访问——这也是 Lovable 及类似应用构建工具所采用的方式。

MCP server 内置了 pgEdge SafeSession，该公司称该功能可防止拥有只读权限的 Agent 修改数据库。它与每个数据库环境独立的凭证和 IP 白名单配合工作。

从原型到气隙生产环境

pgEdge 引用了 IDC 和联想的研究数据：仅有 46% 的通用 AI 和 Agentic AI 原型最终进入生产环境，82% 的组织需要混合或本地环境来部署 AI 工作负载。

Starfleet 旨在让开发者从 pgEdge 的托管基础设施起步，后续能在自己的云或本地运行相同的数据库，包括通过 pgEdge Enterprise Postgres 实现气隙部署，并可扩展到高可用的多区域集群。

不过有一个限制：pgEdge 当前的文档仅覆盖托管层的分支功能，该公司尚未说明当数据库迁移到客户自己的云或数据中心时，这些 Agent 工作流能否延续。

Starfleet 起价 $25/月，提供 14 天免费试用。