本篇文章更新時間：2025/12/24
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
PostgreSQL 18 的瞬間資料庫克隆：用 Copy-on-Write 實現真正的零成本複製
編輯前言：這篇文章來自 boringSQL 的 Instant database clones with PostgreSQL 18，它拆解了 PostgreSQL 18 如何透過檔案系統層級的 clone 技術，讓資料庫複製速度從「數十秒」變成「兩百毫秒」。如果你做過大型資料庫 migration 或測試環境建立，這篇值得一讀。
核心觀點 (Key Takeaways)
- PostgreSQL 18 讓 CREATE DATABASE 可透過 FILE_COPY + clone 實現「零拷貝」複製，大幅加快速度。
- clone 的秘密來自現代檔案系統（XFS、ZFS、APFS）提供的 Copy-on-Write（CoW）能力。
- 零拷貝並非零成本，只要你開始寫入資料，檔案系統會逐頁拆離，兩份資料庫就會逐漸分叉。
深入解析
這篇文章從 PostgreSQL 的模板機制講起。一般我們執行：
CREATE DATABASE mydb;
其實 PostgreSQL 會悄悄從 template1 複製一份資料庫出來。作者提醒，這套模板系統本身就具備「複製能力」，只是大家平常用到的都是預設的 template1。
1. STRATEGY 參數與 PostgreSQL 15 的轉變
PostgreSQL 15 開始新增 CREATE DATABASE ... STRATEGY，預設值改成 WALLOG。WAL 方式的好處是避免過去 FILECOPY 需要 CHECKPOINT 所造成的 I/O 峰值（俗稱 checkpoint storm）。代價是速度變慢——尤其是當模板資料庫很大時。
文章內的例子很直接：複製 6GB 的資料庫，用 WAL_LOG 需要 67 秒。
2. PostgreSQL 18 的新武器 filecopymethod = clone
PostgreSQL 18 允許改變 FILE_COPY 底層真正用哪種方法來複製檔案：
filecopymethod = clone
如果底層檔案系統支援 Copy-on-Write（像 XFS、ZFS、APFS），那麼檔案會透過 metadata 指向同一批 block，等你真正寫入資料時才觸發分離。
作者示範把 file_copy_method 設為 clone，再執行 FILE_COPY，結果速度從剛剛的 67 秒降到僅僅 212 毫秒。
CREATE DATABASE fastclone TEMPLATE sourcedb STRATEGY=FILE_COPY;
Time: 212 ms
這基本上就是 LVM snapshot、ZFS clone 的 PostgreSQL 版。
3. clone 後到底怎麼運作？
clone 並不是把資料複製了一份，而是兩個資料庫實際上共享同樣的實體 blocks。
作者引用 XFS 的 filefrag 輸出，兩份資料庫檔案的 extents 對應到同一段 physical offset，且標記為 shared。
然而只要一做 UPDATE，就會造成 Copy-on-Write：
- 舊 tuple 所在的 page
- 新 tuple 被寫入的 page
- 可能需要更新的 index page
- 相關的 FSM / visibility map
都會生成新的 block，讓兩份資料庫逐漸不再共享儲存空間。
這就是 CoW 的核心邏輯：只有寫入動作才會造成成本。
筆者心得與啟發
這篇文章最讓我有感的，不只是技術上的提速，而是「讓資料庫複製變成一個幾乎零成本的操作」所代表的可能性。
我在閱讀時一直想到兩個情境：
- 開發環境需要不斷 reset 資料庫狀態
- 寫 E2E 測試時想要為每條測試建立乾淨 DB snapshot
過去這種需求往往靠 pg_dump + restore 解決，但當資料庫大到百 MB / GB，成本就爆炸。現在，看起來 PostgreSQL 18 讓這件事重新變得可行，而且快得不可思議。
當然，文章也提醒我們不能忽略限制：
- clone 時來源資料庫不能有任何 active connection
- 多 tablespace 跨多個 mount point 無法使用 clone
- 雲端託管服務通常不給你底層檔案系統權限
實務上，我覺得最能落地的場景，是在自主管理的 VM 或裸機環境中建立「template DB」，一旦需要專屬的 ephemeral DB，瞬間複製即可。
總結來說，PostgreSQL 18 給開發者與 DBA 帶來的，不只是複製技術的加速，而是整個資料庫工作流程的革新。我會很期待接下來社群圍繞這項能力做出的工具與最佳實踐。