秒级克隆、零拷贝沙箱！不止 Lakebase，PostgreSQL 18 迎来瞬时分支能力

1、为什么 AI 时代，大家疯狂需要瞬时分支？

随着 RAG、AI Agent、自动 SQL 生成、模型特征迭代普及，研发模式发生巨大变化：

1. AI 经常自动执行数据变更、批量更新、DDL 迁移，一旦出错极易污染基准数据集；
2. 算法团队需要并行做多组 Prompt A/B 测试、特征版本实验，每组都想要一份独立、和生产一致的数据环境；
3. CI/CD、PR 自动化测试，希望每次启动都拥有干净基线数据；
4. 传统方案：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时：

1. 启动模板库快照
2. 逐个扫描所有表、索引、序列
3. 生成创建对象 + 复制数据的 WAL 日志
4. 通过 WAL 重建到新数据库

缺点：大库克隆极慢，大量 WAL 生成、CPU 开销高。

PgSQL18中语法：

CREATE DATABASE newdb TEMPLATE template_src STRATEGY = { LOGICAL | FILE_COPY };

其中：

1. STRATEGY=LOGICAL：默认行为，兼容旧版本（WAL 逻辑复制方式）
2. STRATEGY=FILE_COPY：物理文件拷贝模式（新增）

FILE_COPY 核心原理：

在文件系统层面，直接复制模板数据库对应的 base/OID 整个目录文件，跳过 SQL 层、跳过 WAL 生成。

前提约束（非常重要）：

1. 模板数据库必须处于静止状态：创建期间不允许写入；
2. PG 会自动对模板库加 AccessExclusiveLock，阻塞所有 DML/DDL。
3. 仅支持同一表空间内复制：重点：FILE_COPY 不能跨表空间！

如果模板库在 tablespace A，你想新建库放到 tablespace B，FILE_COPY 会直接失效，强制回退到 LOGICAL 模式。

1. 不支持带有 UNLOGGED 对象的模板库（未提交，PG18 正式版限制）
2. 复制完成后更新 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时代，可能后面他的分支功能会更加完善也说不定。