一个人 SaaS 把 API 放到 Cloudflare Workers，数据库放在 Neon、Supabase、RDS 或自建 PostgreSQL 时，最先遇到的通常不是 SQL 写错，而是每个请求都在重新握手、认证、建连接。流量从多个地区进来，传统数据库连接数上限也会变成真实约束。
Hyperdrive 不是新数据库，也不是把 Postgres 变成边缘数据库。它更像 Workers 和现有数据库之间的一层连接入口：处理连接建立、连接池和部分读查询缓存。2026-05-25 比对 Cloudflare 文档时，Hyperdrive 支持 PostgreSQL、MySQL 及一批兼容数据库。
Hyperdrive 解决的不是哪一种慢？
| 慢点 | 直接连接时发生什么 | Hyperdrive 介入后做什么 | 仍要自己管什么 |
|---|---|---|---|
| 连接建立 | TCP、TLS、数据库认证跨地区往返 | 减少查询前连接建立成本 | 驱动版本、Node.js compatibility |
| 连接数 | 分布式流量打满连接上限 | 维护到 origin database 的连接池 | origin connection limit |
| 读查询重复 | 热门页面每次都回源 | 可缓存部分 read query | 哪些查询不能缓存 |
| 私有库接入 | 不想直接开放公网 | Workers VPC 通过 VPC Service 接入 | Tunnel、TLS、凭据和数据库角色 |
公有 Postgres 怎么接入？
公有数据库最短路径是创建 Hyperdrive configuration，再绑定到 Worker。
npx wrangler hyperdrive create prod-postgres \
--connection-string="postgres://user:password@HOSTNAME_OR_IP_ADDRESS:5432/app"然后在 wrangler.jsonc 里绑定：
{
"compatibility_flags": ["nodejs_compat"],
"hyperdrive": [
{ "binding": "HYPERDRIVE", "id": "<YOUR_DATABASE_ID>" }
]
}本地开发可以用 localConnectionString。生产、preview、本地不要共用凭据，也不要把生产连接串放进 PR 日志。
连接池参数该怎么管？
Hyperdrive 的连接池放在靠近 origin database 的区域，用 warm connection 路由查询；没有可复用连接时才建立新连接。连接数不是越大越好，太高会把压力还给 PostgreSQL，太低会让 Worker 请求排队。
| 场景 | 默认动作 | 放弃条件 |
|---|---|---|
| Neon / Supabase 小规格库 | 从低连接数开始看 usage | 数据库已有 pooler 且请求很少 |
| RDS / Aurora 有明确 max connections | 给 Hyperdrive 留固定预算 | 后台 job、BI、迁移也在用同库 |
| 多租户热点接口 | 给读接口和写接口分开看峰值 | 单次请求有长事务 |
缓存能放哪些查询？
适合缓存的是公开文章列表、模板市场目录、公开 pricing table、短时间允许滞后的统计卡片。不要缓存当前用户权限、团队席位、账单状态、webhook 入账后的订单查询、后台异常订单和依赖 NOW()、RANDOM() 的查询。
如果同一个 Worker 既有公开目录又有账号后台，可以配置两个 Hyperdrive binding：一个启用缓存，一个禁用缓存。
私有数据库限制怎么划？
如果 PostgreSQL 在 VPC、内网或办公室网络里，Cloudflare 推荐 Workers VPC 方案。流程是运行 Cloudflare Tunnel，创建 tcp 类型 VPC Service，设置 --app-protocol postgresql，再用 --service-id 创建 Hyperdrive configuration。
Workers VPC 推荐方案不需要配置 Cloudflare Access applications 或 service tokens。使用 --service-id 时也不能同时传 --connection-string、Access client id 或 secret。
上线前检查哪 8 项？
| 检查项 | 合格信号 | 先停下来的信号 |
|---|---|---|
| 驱动 | pg 版本符合文档，开 nodejs_compat | 旧驱动报 Node API 错 |
| binding | 只出现在服务端 Worker | 前端 bundle 出现连接信息 |
| 连接数 | 低于数据库预算 | 后台任务也在抢连接 |
| 缓存 | 公开读接口允许 stale | 权限、订单、余额被缓存 |
| 私有库 | Workers VPC 走 VPC Service | 为省事开放生产库公网 |
| 凭据 | 生产、preview、本地分开 | PR 环境复用生产密码 |
| 迁移 | schema change 有 rollback | Worker 和 DB migration 盲发 |
| 监控 | 同看 Hyperdrive metrics 和 Postgres 指标 | 只看 Worker status code |
跨地区维护 Cloudflare Dashboard、GitHub Actions 和数据库后台时，可以把海外服务跑 GitHub Actions / Cloudflare 的稳定线路作为后台操作环境的一部分，但它不能替代数据库权限和变更审查。
什么时候先别上 Hyperdrive？
数据库和计算都在同一区域、流量也集中时，用现有 pooler 可能更简单。业务严重依赖长事务和 session state 时，也要重新设计。缓存限制说不清时，先禁用缓存，只用连接池和连接建立优化。
Cloudflare Hyperdrive Postgres 不覆盖什么
这里没有假设我拿你的生产库跑过压测，也不承诺接入 Hyperdrive 后一定降低延迟或提高可用性。私有数据库部分也没有覆盖所有云厂商网络细节；AWS、GCP、Azure、自建机房的路由、证书和防火墙规则要按自己的基础设施再比对。
如果问题不在 Hyperdrive 本身，而在数据库或团队后台链路，可以分别回到三个相邻排查：Postgres 连接耗尽看 Neon Postgres 连接池耗尽，边缘数据库选型看 Cloudflare D1 vs Turso vs Supabase Edge，远程团队权限入口看 远程团队 Zero Trust。