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。它们解决的是两个不同的问题：一个是加快通往现有数据库的路径，另一个是把数据搬过来从而消除距离。