“database branching” 这个词有一个品牌问题。
很多年来，它通常意味着以下三种东西之一：
一场 dump/restore 马拉松，结束时间大概介于下次站会之前和宇宙热寂之间。
每个分支一个 schema 的幻觉，大家客气地假装“它是隔离的”，而锁竞争和扩展冲突正在后台上演摔角比赛。
一个“clone”功能，本质上只是“我们复制了生产环境，至于账单请不要追问”。
所以没错：旧的 database branching 已经死了。至少，那种让开发者痛苦、让平台团队讨厌开发者的版本已经死了。
但这个想法本身比以往任何时候都更鲜活。它只是升级了。下一位操作你数据库的角色不会是人，而是一个会调查事故、验证迁移、提出 schema 变更、调整索引、做性能实验，然后礼貌地问你五分钟后能不能再来一遍的智能代理。
未来属于代理、CI、预览环境、QA 自动化、分析沙盒和快速迭代。数据库将持续、按需地被创建，而不是每次都去请求平台团队批准。
如果你的基础设施支撑不了这个循环，你就没有所谓的“agentic workflows”。你只有一个会提工单的高级聊天机器人。而工单并不是 control plane。
这个世界需要 branching，只是它需要的不是谎言式的 branching。
这正是 Vela 出现的地方，它的信息非常明确：还是同一个 Postgres，但体验完全不同。更重要的是，branching 也不同。
问题不在 PostgreSQL，本质上是围绕它的工作流出了问题。
PostgreSQL 本来就是这个故事里的主角。它经受过生产考验、可扩展性极强、稳定可靠，而且是那种“以最好的方式无聊”的技术。
真正不无聊的是，围绕 Postgres 做一些日常事情依然有多痛苦：
你想要一个干净的数据库来开发功能？提工单。
你想要一份真实一点的测试数据？先协调、审批，再做一套带着 dump 文件和尊严一起折腾的三步仪式。
你想安全验证一次迁移？那就去协商一个谁都不敢碰的共享 staging 环境吧。
数据库引擎本身没有问题。真正的 bug，是围绕它的人类体验，以及现在逐渐变成代理体验的那一层。
别误会，我当然知道 Docker，也经常在开发和单元测试里使用它。但每次都从零开始、导入一些 seed 数据、再祈祷这些数据大致覆盖真实生产边界情况，这绝不是一种好体验。
今天所谓的“branching”，大多只是“假装隔离”
大多数 database branching 方案都掉进了同一个陷阱：它们优化的是“看起来像个 branch”，而不是“真正像个 branch 一样工作”。
在我看来，最大的问题是 schema-as-branch 方案。它一开始很诱人，因为便宜，而且可以塞进一个 PostgreSQL 实例里。但它带来的副作用清单非常可怕：
分支之间会发生锁竞争，因为本质上还是同一台服务器。
扩展会相互冲突，因为你不可能让每个分支都安全地独立安装和配置一切。
还会有 noisy neighbor 问题，因为大家共享同样的 CPU、内存和 I/O 预算。建立在“请大家小心使用”基础上的隔离，不是安全模型，那只是祈祷。
最糟糕的是，它根本不是真正的克隆。它只是一个“相对安全”的方式，让你试一试 schema 变更，直到某次不小心跑到了错误的 schema 上。权限控制可以稍微缓解一点，但你只要搜一下 “how do I restrict a user to a specific Postgres schema”，就知道这有多尴尬。
这种 branching 就像在开放办公区里摆几块隔板，然后把它叫做“独立办公室”。听起来很熟悉吧？现实是，隔壁工位的人依然在吃金枪鱼三明治。
Vela 的不同之处：branch 就是真实数据库
下面这句话会改变一切：
在 Vela 里，branch 就是真实的 PostgreSQL 数据库。 不是 schema，不是模拟 namespace，不是“逻辑副本”，而是真正的 Postgres 实例。
每个 branch 都以完全隔离的 Postgres 实例形式运行在自己的 micro virtual machine 中，拥有独立的资源限制和租户边界，而不是依赖“大家自觉”。
这会立即消灭传统 branching 之所以脆弱的那一整类问题：
- 一个 branch 无法饿死其他 branch。
- 一个 branch 不会和其他 branch 的扩展冲突。
- 一个 branch 不会和邻居共享锁崩溃。
- 一个 branch 不会因为共享进程而“泄漏”行为。
- 一个 branch 也不会误删其他 branch 的数据。
从用户角度看，这就是“branching 只是个酷炫 demo”和“branching 是我们测试与交付软件的标准方式”之间的差别。
Vela 不是新数据库，而这恰恰是重点
说得更直白一点：Vela 并不是又一个新的数据库引擎。
它不会发明一种新的查询语言。
它不会在你和 SQL 之间塞一层专有抽象。
它也不是那种升级路线最终会把你逼哭的 Postgres fork。
Vela 使用的是上游 Postgres，也就是说你现有的工具都还能继续工作：ORM、迁移工具、驱动、BI 工具、脚本，甚至那个 2017 年写出来、现在谁都不敢碰的内部工具。
这一点非常关键，因为一旦你的“branching 平台”要求你把一切重新平台化，它就不再是 branching 了，而是职业转型。
无论对人还是对代理，语境都是王道
旧式数据库工作流默认人类会忍受摩擦。
- “先提工单。”
- “等着。”
- “去协调。”
- “小心点。”
- “以后再收拾。”
代理不会接受这种流程，CI 不会，快速的产品迭代也不会。
大多数团队都维护着一个由生产、staging、dev/QA 组成的环境动物园。只要刷新不频繁、所有人都能接受漂移，它看起来似乎还能运作。但在代理时代，这种模式会撞上一堵墙。
如果你的工作流不能快速创建安全、隔离、真实的数据库环境，它就会成为瓶颈。而其中最昂贵的部分不是计算资源，而是损失掉的迭代速度。
原因很简单：staging 默认会逐渐偏离生产。数据分布会变化，扩展会不同，性能特征也会漂移。人类还能靠经验和感觉补一下，代理没有“感觉”，它只有输入。
如果一个代理在陈旧或不真实的数据上验证迁移，它可能给出看上去很合理的结果，但在真实生产分布下却会失败。这不是 LLM 问题，也不是人的问题，而是上下文问题。而上下文问题，靠“更好的提示词”是解决不了的。
Vela 的模型围绕着自助、真实隔离、快速 branching 和轻松丢弃环境来构建。它把数据库工作流变成团队可以用现代节奏真正运转起来的东西。开发者可以在不影响共享 staging 的情况下测试迁移；QA 可以不用排期就验证功能；分析师可以跑重查询而不把生产环境送进 ICU；而你的代理则可以自动验证并推荐真正重要的变更。
与此同时，平台团队终于也能得到他们真正想要的东西：可预测性、明确的租户边界，以及在不承担所有人实验 on-call 代价的前提下说“可以”的能力。
真正的魔法在于存储：它让 branching 变得便宜
“每个 branch 一个真实数据库”听上去很贵，直到你意识到 Vela 并不会每次都天真地复制数 TB 数据。
在 “Building an Agent-Ready Postgres Data Platform” 这篇 agent-ready blueprint 中，Rob 提到了最适合这种负载的架构：shared-everything 加 copy-on-write（COW；这个视频里我解释了它的好处和工作原理）。
这个模型其实很直观：所有 branch 共享一个基础快照，branch 创建之所以快，是因为它只是元数据操作；而存储开销增长只和每个 branch 改了多少有关，而不是和生产环境有多大有关。
Vela 使用 simplyblock 作为它的 分布式存储引擎，从而在存储层实现 copy-on-write 语义。
也正是在这里，“database branching” 不再是一次特殊事件，而变成了你可以随手使用的基础设施。就像创建一个 Git 分支，只不过这次对象是数据库，所以出错的代价更高一些。
这也更符合代理时代的现实。最有价值的代理工作大多是 read-heavy 的：分析 schema、抽样数据分布、验证约束、跑 EXPLAIN 计划、测试迁移。这些工作需要生产级上下文，理想情况下就是一份生产副本。但它们并不需要一份完整的物理生产数据拷贝。COW 恰恰让这种不对称变得划算。
隔离是必要条件，但还不够
代理同样需要权限边界。
这份 agent-ready blueprint 说得很直接：你需要基于角色的访问控制、配额限制，以及环境级策略，用来限制代理可以在哪些地方行动、能够修改什么。
因为“每个任务一个 branch”虽然是安全边界，但平台仍然需要治理。branch 专用凭据、branch 范围权限，以及干净的 promote/discard 流程，都不是可选细节。它们决定了“代理加速工作”，还是“代理加速事故”。
由于 Vela 把隔离当作一等公民，它的 branching 原语就是围绕这样一个前提设计的：你应该能够毫无后果地把一个环境扔掉。Vela 用权限、资源限制和 VM 边界来落实这种隔离。
所以，database branching 到底死了吗？
是的。
旧版本已经死了：schema hack、dump/restore 仪式、实质上只是账单放大器的“clone”按钮，以及“相信我，它是隔离的”这类做法。
但作为真正、安全、快速默认工作流的 database branching，才刚刚开始。
最有意思的是，你甚至不需要完整的 MCP（Model Context Protocol） 接线，也不需要一个庞大的自治运行时，就已经能从中获益。无论你现在已经在使用代理，还是仍然亲手写代码，一个从海量数据集即时克隆出来的数据库 branch，就是我一直想要的变更测试、修复验证和迁移保障方式。我以前从来没有真正有机会在大规模上这样做。直到现在。
如果你今天开始养成 branch-first 的习惯，让每一次迁移检查、性能调查和高风险实验都在一个从可信基线克隆出来的新 branch 上完成，那么你其实已经在为未来的安全代理打基础了。你正在证明：真实上下文和严格隔离可以在没有摩擦的情况下共存。
Vela 的赌注很简单：Postgres 继续保持无聊，而体验不再痛苦。
如果你想亲自感受 branch-first 的 Postgres 是什么样子，可以试试 Vela Sandbox，像真的要用它一样去创建一个 branch。