摘要： Cloudflare 在 2026 年 10 月 13 日發表 D1 控制面的架構解析，說明它如何支撐一年 15 倍、兩年 65 倍的資料庫數量成長。核心做法是把資料面（查詢）與控制面（建庫、刪除等管理操作）明確分開：查詢完全不經過任何中心單區元件，管理操作則允許依賴中心 Postgres。對正在做多租戶或 agent 平台的人來說，這是一份可以直接借用的架構藍圖。
為什麼資料庫的形狀變了
傳統架構假設一個應用配一兩個大型資料庫叢集，再加上連線池。Cloudflare 在這篇解析中觀察到，AI 輔助開發和 vibe coding 平台正把這個模型反轉：每位使用者、每個預覽環境、每個租戶各自一個小資料庫，總量達到數百萬個，其中數十萬個隨時活躍。D1 基於 SQLite 的 serverless 模式剛好適合這種形狀——每個資料庫背後就是一個 SQLite Durable Object，建立成本極低。
真正的難題不在資料庫本身，而在控制面：怎麼管理數百萬個資料庫，又不讓每次查詢都為此付出延遲代價。
一條鐵律：查詢路徑不碰中心
D1 把所有操作分成三類：資料面的查詢請求必須盡快、永遠在邊緣；控制面的 HTTP 管理操作可以依賴中心單區元件；背景的非同步分析與計費流程則允許最終一致。這個分類本身就是最有用的設計決策——先想清楚哪些請求不能慢，再決定哪些元件可以集中。
查詢的路徑是：使用者的 Worker 透過 D1 binding 直接打到 Eyeball Worker，再轉發到對應的 Durable Object。路由所需的 metadata 存在 Workers KV，也就是全域分散的邊緣快取，所以絕大多數查詢完全不需要回頭查中心的 Postgres。只有快取偶爾失效時才會碰到中心。
建資料庫的流程，處處想著失敗
建立一個 D1 資料庫看起來只是一條指令，實際上要做四件事：檢查帳戶額度、產生資料庫 UUID 和唯一的 Durable Object ID、把 metadata 寫進中心 Postgres、把 ID 對應寫進 Workers KV。整個流程包在重試迴圈裡，失敗就換一組 ID 重來。
兩個細節值得細看。第一，為了讓資料庫落在使用者附近，Edge API Worker 會把請求轉發到靠近原始請求位置的資料中心去初始化 Durable Object；但需要多次往返 Postgres 的部分，則反而先轉發到 Postgres 所在的資料中心——因為跨洋單趟可能是數百毫秒，靠近中心只要幾毫秒。放置策略不是一刀切，而是按每段操作的依賴對象分別決定。
第二，Postgres 寫入是「建立檢查點」：寫入成功後即使最終回應沒送達使用者，資料庫也算建立完成。最後那個通知 Durable Object 的確認呼叫則放在 waitUntil() 裡，允許失敗。Cloudflare 也解釋了為什麼不把整個流程包進一個 Postgres 交易——因為初始化遠端的 Durable Object 時會佔住連線，這在規模上是行不通的。
你可以直接搬走的原則
Cloudflare 列出的指導原則大多是通用的：所有流程都假設會失敗、設計成冪等並能自我修正；熱路徑避免任何中心單區元件；用全球分散的 KV 存關鍵路由 metadata；用 Hyperdrive 這類連線池工具高效存取中心資料庫，盡量打讀取副本；把彙總運算預先算好，避免在使用者請求中跑掃描式查詢；不需要強一致性的元件之間就用最終一致性和佇列。
還有一條最容易被忽略：他們在改造期間定期用遠高於預期成長的目標做負載測試，用測試結果決定優化順序，而不是憑直覺猜瓶頸。
對 builder 的實際意義
如果你正在做的是多租戶 SaaS、每人一庫的產品，或是會大量開預覽環境的 agent 開發平台，這篇解析等於是 Cloudflare 把自己的控制面拆開給你看。同一批原則我在寫 Cloudflare 日誌管線的這篇（把 SQL 過濾器塞進日誌匯出管線）時也提過類似思路：把昂貴的操作挪到離資料最近的地方，下游才不會一起變慢。
值得注意的是，這篇解析到心跳自我修正機制之前就截斷了，後半段的細節以原文為準。實務上的下一步很簡單：拿自己系統的操作清單，照 D1 的方式分成資料面、控制面、背景三類，先確認第一類有沒有任何中心元件擋在路徑上。