Cloudflare + PlanetScale：在边缘运行全栈应用，数据库也不例外

全栈开发者面对的一道老难题Cloudflare Workers 解决了计算层的全球分发问题——你的代码跑在 Cloudflare 遍布全球的 300 多个数据中心里离用户近启动快不需要管理任何服务器。但数据不一样。数据库天然是有状态的它需要持久化存储需要事务保障需要固定的连接。传统的关系型数据库通常部署在某一个区域的服务器上不可能像代码一样随意分散到全球各地。这就带来了一个结构性矛盾你的 Worker 在法兰克福响应了一个欧洲用户的请求但数据库在美东——每次查询都要跨越大西洋走一个来回所有的计算优势在网络延迟面前大打折扣。2025 年 9 月Cloudflare 宣布与 PlanetScale 正式建立合作关系目标是让 Workers 直接接入 Postgres 和 MySQL打通全栈应用的最后一公里。2026 年 4 月这个合作迈出了实质性的更深一步你现在可以直接在 Cloudflare Dashboard 里创建 PlanetScale 数据库账单也将统一并入 Cloudflare。这次更新带来了什么从 Cloudflare Dashboard 直接创建数据库在此之前如果你想在 Workers 里使用 PlanetScale流程是先去 PlanetScale 官网注册账号创建数据库拿到连接凭证然后回到 Cloudflare 配置。两套账号两套控制台来回切换。现在你只需要把 PlanetScale 账号与 Cloudflare 关联一次之后创建 Postgres 或 MySQL 数据库的入口就在 Cloudflare Dashboard 里——同一个页面同一个操作流。账单统一账单分散是多产品组合使用时最常见的运营痛点之一。合并之后新创建的 PlanetScale 数据库费用将直接计入你的 Cloudflare 账单无论你是自助用户还是企业客户。更值得关注的是Cloudflare 的平台积分和企业承诺消费额度可以直接用于抵扣 PlanetScale 数据库的费用。如果你参与了 Cloudflare 的创业加速计划Workers Launchpad或有企业合同这意味着你现有的权益可以直接覆盖到数据库这层成本不需要单独为 PlanetScale 建立预算。为什么是 Postgres 和 MySQLSQL 关系型数据库是现代应用的基础这一点在过去几十年里基本没有动摇过。而在所有关系型数据库中Postgres 这几年在开发者社区的受欢迎程度持续走高。原因是多方面的Postgres 拥有极其丰富的生态工具从 ORMPrisma、Drizzle、SQLAlchemy到 GUI 工具TablePlus、pgAdmin从迁移工具到监控工具基本上你能想到的需求都有成熟的解决方案。在 AI 应用爆发的背景下Postgres 还有一个特别重要的扩展pgvector。它让 Postgres 原生支持向量存储和相似度搜索成为构建 RAG检索增强生成系统、语义搜索、推荐系统的常用基础设施。Postgres pgvector 的组合已经成为很多 AI 应用的标准数据层选型。PlanetScale 同时支持两种主流引擎Postgres提供完整的兼容性包括 pgvector 等扩展支持。Vitess MySQLPlanetScale 原本就是基于 Vitess 构建的Vitess 是 YouTube 用于支撑其 MySQL 集群横向扩展的开源系统稳定性和扩展能力经过了大规模生产验证。两种选择各有适用场景开发者可以根据已有的技术栈和团队习惯自行决定。连接数据库的核心机制Hyperdrive在聊延迟优化之前需要先说清楚一件事Workers 和传统 Web 服务器在数据库连接这件事上面临的挑战是完全不同的。传统的 Node.js 应用服务器是长驻进程它可以在启动时建立一个数据库连接池后续的所有请求复用这些连接连接本身的建立成本只需要承担一次。Workers 是无状态、短生命周期的执行环境。每个请求的处理过程可能跑在不同的物理机器上Worker 实例本身不保存跨请求的持久状态。这意味着如果每个请求都直接去和数据库建立 TCP 连接成本极其高昂——Postgres 的连接握手本身就包含 TLS 协商、认证等多个往返单次建立连接的时间往往比实际查询的执行时间还要长。Hyperdrive就是专门解决这个问题的。它在 Cloudflare 的基础设施侧维护一个持久的数据库连接池Workers 发出的连接请求实际上是连接到 Hyperdrive 的本地端点由 Hyperdrive 代理到真实数据库。这样昂贵的 TCP/TLS 连接只需要建立一次后续请求直接复用。除了连接池Hyperdrive 还提供查询缓存对于结果不频繁变化的读取请求Hyperdrive 可以直接返回缓存结果完全跳过数据库查询响应时间降至个位数毫秒。接入 Hyperdrive 的配置非常简单。在你的wrangler.jsonc配置文件里添加一个绑定{ hyperdrive: [ { binding: DATABASE, id: 自动生成的ID } ] }然后在 Worker 代码里用你熟悉的 Postgres 客户端直接发起查询env.DATABASE.connectionString会自动解析为 Hyperdrive 的代理地址import{Client}frompg;exportdefault{asyncfetch(request,env,ctx){constclientnewClient({connectionString:env.DATABASE.connectionString});awaitclient.connect();constresultawaitclient.query(SELECT * FROM pg_tables);// ...}};整个过程对代码来说是透明的——你用的还是标准的pg客户端写法没有任何变化连接管理和缓存完全由 Hyperdrive 在后台处理。延迟的另一个维度Workers 放置策略Hyperdrive 解决的是连接建立这个成本问题。但还有另一个延迟来源需要单独处理Worker 执行位置与数据库物理位置之间的距离。Workers 的默认行为是就近执行——请求从哪里来Worker 就在最近的数据中心执行。这对纯计算任务来说是最优的但对于需要频繁查询一个集中式数据库的应用情况就不同了。举个具体例子你的 PlanetScale 数据库部署在 AWS 美东us-east-1一个来自新加坡的用户发起了请求Worker 在新加坡就近执行但每次数据库查询都要跑到美东再回来单次往返延迟大约 200ms。如果一个页面请求触发 5 次串行查询光是数据库往返就积累了超过 1 秒的延迟。**Explicit Placement Hint显式放置提示**就是解决这个问题的配置项。你在wrangler.jsonc里声明 Worker 应该执行的区域{ placement: { region: aws:us-east-1 } }这样无论请求从哪里来Worker 都会在美东就近数据库的数据中心执行数据库往返延迟可以压到个位数毫秒。代价是请求本身从用户到 Worker 的传输距离变长了但对于数据库密集型应用来说这通常是更合算的权衡。Cloudflare 还透露了一个规划中的功能未来平台可以根据你的 PlanetScale 数据库的实际部署位置自动推导并设置最优的放置区域不需要手动配置。这对于不熟悉这个参数的开发者来说意味着延迟优化可以做到开箱即得。PlanetScale 的开发者体验除了性能层面的设计PlanetScale 在开发者日常工作流上也有几个值得单独说的功能。Query Insights查询洞察PlanetScale 会自动分析你的 SQL 查询标记出执行时间异常的慢查询并提供索引建议。你不需要自己去分析执行计划平台直接告诉你哪些查询在拖慢你的应用。Branching数据库分支这是 PlanetScale 的一个比较独特的功能——你可以像管理 Git 分支一样管理数据库 schema 变更。在一个feature branch上做表结构修改测试通过之后合并到主分支整个过程不需要停机也不会影响生产环境的数据。对于需要频繁迭代数据模型的团队这个功能大幅降低了 schema 变更的操作风险。AI 驱动的工作流优化PlanetScale 近期也引入了 AI 辅助的 SQL 优化工具可以对接 AI 工具链通过自然语言描述来分析和改进查询性能。Cloudflare 用户使用的是完全相同的 PlanetScale 功能集没有任何裁剪。定价与当前状态PlanetScale Postgres 的单节点起步价是 5 美元/月这个价格包含了全部功能——Query Insights、Branching、详细的用量统计等没有功能分级。目前的状态是你现在就可以通过 Cloudflare Dashboard 连接已有的 PlanetScale 账户或者直接创建新的 Postgres 数据库数据库会通过 Hyperdrive 自动与你的 Workers 集成。这个流程今天就可以用费用目前还是走 PlanetScale 账单。账单统一到 Cloudflare 这个功能按照博客的表述将在下个月上线原文发布于 2026 年 4 月。这件事的更大意义从表面上看这是一次数据库产品的集成发布。往深处看它代表的是 Serverless 计算和托管数据库两个方向的深度融合。Workers 诞生的最初几年它的定位更像是一个边缘中间件——处理请求路由、缓存逻辑、安全策略真正需要业务数据的时候还是要回调后端服务。随着 D1Cloudflare 自研的 SQLite 数据库、R2对象存储、KV键值存储、Queues消息队列等产品的陆续成熟再加上这次 PlanetScale 的深度集成Workers 正在从边缘中间件变成一个真正意义上的全栈应用运行平台。PlanetScale 在这个组合里填补的是需要严肃对待的关系型数据库这个位置——事务、外键、复杂联表查询、数据一致性这些是轻量级存储方案无法替代的能力。对于正在选型的开发团队来说这个组合的吸引力在于一套账单、一套控制台、一套权限体系计算层、网络层、数据库层都由同一个供应商负责出了问题不用在三家客服之间互相推诿。这种平台内聚的趋势在云计算行业会越来越明显。原文来源Cloudflare Blog《Deploy Postgres and MySQL databases with PlanetScale Workers》2026 年 4 月 16 日。