Cloudflare Hyperdrive：從邊緣存取 Postgres

Cloudflare Hyperdrive 之所以存在，是為了處理一個非常具體、也一點都不炫目的問題：一個在 200 座城市裡執行的 Worker，去跟某一座城市裡的那一個 Postgres 資料庫對話，會比同一道查詢從緊鄰這台資料庫的伺服器發出來得慢。不是慢一點點，而往往是慢上好幾倍，而且原因跟查詢本身怎麼寫完全無關。

當一個無伺服器應用顯得遲鈍時，多數人的第一直覺是怪查詢規劃器，或是再加一個索引。但在跟某個區域資料庫溝通的 Workers 上，查詢本身通常沒有毛病。真正出問題的是連線。

Hyperdrive 真正修好的東西： 建立一次資料庫連線的代價，而且這筆代價要在每一個請求上重新付一遍。一條 Postgres 連線在第一列資料移動之前，得先完成 TCP 交握、TLS 協商，以及一次身分驗證交換，而這三步的每一步，都是從 Worker 被喚醒的地方到資料庫所在地的一趟來回。Hyperdrive 會在你的資料庫附近維持一批熱連線並放進連線池，於是 Worker 只要借用一條已經開好的連線，不必從頭再建一條。

為什麼直連 Postgres 的 Worker 會慢

傳統的應用伺服器在啟動時一次打開一個連線池，並在整個行程的生命週期裡反覆重用。交握的成本在啟動那一刻付清，之後就攤到數以百萬計的請求上，直到有人重啟這個服務為止。

Workers 不是這樣運作的。每一次呼叫都很短命，而且可能落在 Cloudflare 的任何一個據點上。沒有任何長壽命的行程替你握著連線池，所以在沒有額外協助的情況下，每個請求都得付出完整的建立連線成本，而且是在從邊緣到你來源資料庫的這段距離上付出。

在第一個資料位元組抵達之前就要走三趟來回，這不是靠調校能解決的問題。一位雪梨的使用者去存取一個與倫敦 Postgres 溝通的 Worker，他要把這段延遲付四遍：先是 TCP，接著 TLS，然後是身分驗證，最後才輪到查詢。而查詢本身可能只花兩毫秒。換句話說，真正吃掉時間的並不是資料庫在算什麼，而是網路在兩地之間來回打招呼，而這段路程的長短由地理決定，跟索引與執行計畫都無關。

還有第二種比較安靜的故障方式。Postgres 為每一條連線配置一個後端行程，而它的上限是有限的，通常只有幾百個。一個能擴展到數千個並行呼叫的 Worker 會把這個池子耗乾，然後開始收到連線被拒絕的錯誤，而這恰恰發生在你當初為它建置邊緣架構的那個流量尖峰裡。

Hyperdrive 為此做了什麼

Hyperdrive 以連線池的身分坐在 Worker 與資料庫之間，由 Cloudflare 代你維運。它會持續維持通往你來源端的熱連線，因此一次呼叫只需要借走其中一條，不必從零開始協商一條新的。

它同時也會快取查詢結果。重複出現的讀取查詢可以在完全不碰來源端的情況下回應，這就把相當一部分流量的延遲問題，變成了快取命中率的問題。寫入以及任何不具確定性的語句會直接穿透過去，因為它們的結果本來就不能重複使用，快取對它們沒有意義，也不該有意義。

設定說穿了就是一條連線字串。你把資料庫註冊到 Cloudflare，拿到一個 Hyperdrive 繫結，然後把現有的 Postgres 驅動程式指向這個繫結，而不是指向資料庫本身。驅動程式、SQL 與資料表結構都不必更動。這一點比聽起來更重要，因為它意味著這次改動是可以回退的，你可以在不重寫任何程式碼的前提下，把它跟直連放在一起量測。

決定它適不適合的那幾個數字

以下數值在 2026 年 8 月對照 Cloudflare 官方文件核對過，而且這些數字會變動，所以在正式投入之前值得再確認一次。

Hyperdrive 在兩種方案上都不額外收費 ，也沒有輸出流量費。什麼算一次查詢，定義相當寬：select、insert、update、delete 或一次資料表結構變更都算，而且命中快取的查詢與未命中快取的查詢計算方式完全一樣。免費方案的每日額度會在世界協調時間的午夜重置。

限制文件 列出了 15 秒的初始連線逾時與 10 分鐘的閒置逾時。單一查詢 60 秒的上限，正是想把報表類工作負載搬過來的團隊最容易踩到的坑：一道在排程工作裡跑兩分鐘的分析查詢，在這裡只會直接失敗。

哪些資料庫真的能用

Hyperdrive 支援 PostgreSQL 9.0 到 17.x 以及 MySQL 5.7 到 8.x ，自架或託管都可以。MariaDB 歸在 MySQL 相容範圍之內。

被點名列出的託管服務商包括 Postgres 相容與 MySQL 相容兩種形態的 AWS Aurora，以及 Neon、Supabase、Timescale、Materialize、CockroachDB 與 PlanetScale。Azure 與 Google Cloud 上的託管執行個體同樣可用。

真正的現實限制不是資料庫引擎，而是可達性。你的資料庫必須能從 Cloudflare 的網路定址得到。一個被封在私有 VPC 裡、沒有公開端點的 Postgres 執行個體，得先有通道或對等互連的安排，Hyperdrive 才有可能看得到它，而那是一個網路工程專案，不是改一行設定就能了事。

什麼時候 Cloudflare Hyperdrive 是錯誤答案

當資料本來就該待在邊緣時。 如果你的存取模式是鍵值查找，Workers KV 更快也更單純。如果你要的是一個住在 Worker 附近、而不是待在某一個區域裡的小型關聯式資料庫，那麼為此設計的產品是 D1。Hyperdrive 面向的是你已經有 Postgres 或 MySQL、而且打算繼續用下去的情況。

當工作負載偏分析型時。 60 秒的上限與按查詢計數的方式適合交易型流量。耗時很長的彙總運算應該交給一個直接連資料庫的工作執行器。

當你還沒有量測過時。 我們最常看到的失敗，是團隊把 Hyperdrive 加到一個從來就不受連線數限制的應用上。如果一個 Worker 之所以慢，是因為它送出六道原本可以合成一道的循序查詢，那麼把這六條連線放進池子裡，只會讓它稍微不那麼慢，真正的問題原封不動。

這個量測值得在動手之前認真做一遍。我們對 Cloudflare Workers 與 AWS Lambda 的比較講清楚了邊緣執行真正佔優的場景，而 Cloudflare D1 那篇則討論了把資料庫整個搬過來比加速通往它的路徑更划算的情況。

把決定做對

從一個遠離你資料庫的地方，先用直連替一個請求做端到端計時，再走一遍 Hyperdrive 計時。兩次都要在相同時段、相同網路條件下量測，而且多跑幾輪取中位數，否則你比較的只是運氣。如果差距很小，代表你的延遲住在別的地方，你也替自己省下了一項相依性。如果差距很大，那你就找到了真金白銀。

Mecanik 透過我們的軟體開發 團隊建置並審視邊緣架構，其中也包括那個一點都不炫目的環節：在動手重構之前，先有人把到底什麼慢量清楚。如果你的無伺服器應用比它取代掉的那台伺服器還慢，連線路徑就是第一個該去看的地方。

延伸閱讀： 打造 Cloudflare Workers API：無伺服器指南 2026 、Cloudflare Queues：邊緣的背景工作 、如何降低 LLM 延遲：快取與邊緣策略 以及 2026年如何建構Web應用 。

常見問題

Cloudflare Hyperdrive 解決的是什麼問題？ 每個請求都要重新打開一次資料庫連線的代價。Worker 生命週期很短，也不持有連線池，所以沒有 Hyperdrive 的話，每一次呼叫都得在從邊緣到你資料庫的這段距離上，先付出一次 TCP 交握、一次 TLS 協商與一次身分驗證交換，然後資料才開始流動。Hyperdrive 會在來源端附近維持一批已經入池的熱連線，讓 Worker 直接借走其中一條。

Cloudflare Hyperdrive 要收費嗎？ 除了你的 Workers 方案之外不再另外收費。免費方案與付費方案都包含它，沒有單獨費用，也沒有輸出流量費。免費方案每天允許 100,000 次資料庫查詢，在世界協調時間的午夜重置，付費方案則不限次數。select、insert、update、delete 以及資料表結構變更都算作查詢，命中快取的查詢與未命中快取的查詢計算方式完全一樣。

Hyperdrive 支援哪些資料庫？ PostgreSQL 9.0 到 17.x 以及 MySQL 5.7 到 8.x，自架或託管都可以，MariaDB 歸在 MySQL 相容範圍內。被點名的服務商包括 AWS Aurora、Neon、Supabase、Timescale、Materialize、CockroachDB 與 PlanetScale，還有 Azure 與 Google Cloud 上的託管執行個體。資料庫必須能從 Cloudflare 的網路存取得到。

Hyperdrive 的主要限制有哪些？ 免費方案每個帳戶十個已設定資料庫，付費方案 25 個；每份設定的來源端連線數在免費方案上約 20 條，在付費方案上約 100 條；單一查詢最長 60 秒；快取回應大小 50 MB；初始連線逾時 15 秒；閒置逾時 10 分鐘。單一查詢 60 秒的上限，正是擋住分析型工作負載的那一條。

該用 Hyperdrive 還是 D1？ 如果你已經有一個打算繼續用下去的 Postgres 或 MySQL 資料庫，而問題出在存取它的延遲上，那就用 Hyperdrive。如果你要的是一個一開始就住在 Cloudflare 網路上的關聯式資料庫，那就用 D1。它們解決的是兩個不同的問題：一個是加快通往現有資料庫的路徑，另一個是把資料搬過來，直接消除距離。