秒级克隆、零拷贝沙箱！不止 Lakebase，PostgreSQL 18 迎来瞬时分支能力
秒级克隆、零拷贝沙箱！不止 Lakebase，PostgreSQL 18 迎来瞬时分支能力
1、为什么 AI 时代，大家疯狂需要瞬时分支？
随着 RAG、AI Agent、自动 SQL 生成、模型特征迭代普及，研发模式发生巨大变化：
- AI 经常自动执行数据变更、批量更新、DDL 迁移，一旦出错极易污染基准数据集；
- 算法团队需要并行做多组 Prompt A/B 测试、特征版本实验，每组都想要一份独立、和生产一致的数据环境；
- CI/CD、PR 自动化测试，希望每次启动都拥有干净基线数据；
- 传统方案：pg_dump、全量物理克隆，TB 级数据库动辄数十分钟，同时占用双倍存储空间，成本和时延无法承受。
2、PostgreSQL 18 原生具备瞬时克隆能力
不少开发者存在误区：瞬时分支 = 湖仓专属特性。
伴随 PostgreSQL 18 正式发布，新增配置file_copy_method = clone，原生支持文件系统层零拷贝瞬时数据库克隆，实现类似 Lakebase 的使用体验。
底层依托现代文件系统能力（ZFS、XFS reflink、APFS）：执行CREATE DATABASE ... TEMPLATE时，不再逐块复制文件，通过文件系统重链接机制共享原始数据块；只有当克隆库内部产生数据修改，才触发块复制（写时复制）。数十 GB、上百 GB 数据库，同样实现秒级创建，初始几乎不占用额外磁盘空间。
2.1使用方法
目前主要是 CREATE DATABASE ... STRATEGY=FILE_COPY 和 ALTER DATABASE ... SET TABLESPACE = ...使用。
早期版本CREATE DATABASEnewdbTEMPLATEtemplate1;创建新databse时：
- 启动模板库快照
- 逐个扫描所有表、索引、序列
- 生成创建对象 + 复制数据的 WAL 日志
- 通过 WAL 重建到新数据库
缺点：大库克隆极慢，大量 WAL 生成、CPU 开销高。
PgSQL18中语法：
CREATE DATABASE newdb TEMPLATE template_src STRATEGY = { LOGICAL | FILE_COPY };
其中：
- STRATEGY=LOGICAL：默认行为，兼容旧版本（WAL 逻辑复制方式）
- STRATEGY=FILE_COPY：物理文件拷贝模式（新增）
FILE_COPY 核心原理：
在文件系统层面，直接复制模板数据库对应的 base/OID 整个目录文件，跳过 SQL 层、跳过 WAL 生成。
前提约束（非常重要）：
- 模板数据库必须处于静止状态：创建期间不允许写入；
- PG 会自动对模板库加 AccessExclusiveLock，阻塞所有 DML/DDL。
- 仅支持同一表空间内复制：重点：FILE_COPY 不能跨表空间！
如果模板库在 tablespace A，你想新建库放到 tablespace B，FILE_COPY 会直接失效，强制回退到 LOGICAL 模式。
- 不支持带有 UNLOGGED 对象的模板库（未提交，PG18 正式版限制）
- 复制完成后更新 pg_database、更新文件内部元数据（relfilenode、数据库 OID 等内部标记）。
2.2原理
主要是copydir函数的调用，当配置项为file_copy_method = clone时，就会调用clone_file函数实现克隆。clone_file函数也分为macOs和Linux操作系统（Btrfs、XFS Linux 5.3+、ZFS等）。
macOs中：COPYFILE_CLONE_FORCE标志要求内核必须通过 APFS 的写时复制(reflink)机制完成,如果文件系统不支持克隆则直接失败,而不会静默退化为普通拷贝。
Linux系统：需要手动打开源/目标文件描述符,再循环调用copy_file_range()
- 打开源文件:只读方式打开 fromfile 。
- 创建目标文件:以 O_WRONLY | O_CREAT | O_EXCL 打开 tofile,O_EXCL 保证目标文件不能预先存在,避免覆盖已有文件 。
- 循环拷贝:每次最多拷贝 1MB(1024 * 1024),而不是一次性拷贝整个文件。这样做的原因是保证 CHECK_FOR_INTERRUPTS() 能及时响应取消信号——尤其是当底层文件系统不支持真正的 reflink、copy_file_range()退化为内核态逐字节拷贝时,大文件可能耗时较长。
- 与分支一不同,copy_file_range() 本身不保证一定做reflink（该函数只修改元数据，不进行拷贝）——如果底层文件系统不支持共享块,内核会自动退化为普通的内核态数据拷贝。这也是为什么后端选用 copy_file_range() 而非 Linux 的 FICLONE ioctl(后者若不支持会直接失败,语义等价于"强制克隆"),因为 copydir() 只是希望"尽量利用克隆优化",即使退化也应正常工作。
craetedb函数在进行创建database时，不允许模板库上有连接，以免拷贝到不一致数据
3、总结
1）COW层级
文件系统块级（OS 层 reflink），做到了零拷贝和不占用空间。但是需要遍历所有文件，以1MB为单位进行reflink，如果database很大，这个花费的时间就可能不是秒级能完成的了。它的分支能力相当于完全由文件系统来掌控，数据库这边控制不了
2）分支粒度
单个database级别的，并且仅限同一个 Postgres 实例内部创建数据库，克隆库和模板库共享 PG 实例资源，资源争抢。
3）对生产库的影响
必须踢掉源库上所有连接。这个对现实创建分支场景中限制很大。当然他还会对模板库加上排他锁，这个进一步确保阻塞读写
4）时间旅行
仅支持克隆发起瞬间的一致性快照；不能回溯历史任意时间点。
尽管有这些限制，但PgSQL也算在紧跟AI时代，可能后面他的分支功能会更加完善也说不定。