一人公司后端技术栈：Cloudflare Workers、Supabase、Node.js 和数据库怎么选

工具站前端写完了，接下来要落地这些 API：/api/submit、/api/checkout-webhook、/api/report-cron，还要存 users、usage_events、files。你知道哪些该放 Workers，哪些该放 Supabase，哪些需要一个独立 Node 服务吗？

后端技术栈不是选一个平台就能搞定，而是要把请求入口、业务数据、文件存储、长任务、认证和 Webhook 拆到不同服务。Workers 适合边缘入口和轻逻辑，Supabase 承载 Auth 和 Postgres，Node.js 处理无法放进 edge runtime 的重任务和复杂依赖。下面这张职责分配表可以直接对照你的清单判断。

一、后端职责分配表：你的清单该放哪里

先看这张表，对照你的 API、Webhook、Cron、数据和文件清单：

职责	推荐归属	判断依据	风险提示
请求入口	Cloudflare Workers	边缘入口、全球分布、低延迟响应	超出 CPU、内存或依赖边界时需要拆分
轻 API	Workers / Supabase Edge Functions	请求转发、验证、I/O 密集的短任务	Workers 更靠近边缘，Edge Functions 与 Supabase 项目绑定
Webhook	Workers 或 Edge Functions	第三方回调、验签、幂等入库	重任务应快速确认后进入队列或后台 worker
认证/用户系统	Supabase Auth	Auth、RLS、权限模型、社交登录	service role 或 secret key 不得暴露到浏览器端
业务数据	Supabase Postgres	关系数据、事务、查询、触发器	选择 D1 等其他关系数据库时也要设计迁移、约束和权限
对象存储	Supabase Storage / R2	用户上传、图片、导出文件、备份	按访问控制、流量、CDN 和工具链选，不按单一文件大小机械划分
长任务/重依赖	Node.js worker / 专门任务平台	浏览器自动化、大文件处理、原生模块、长期消费者	不要让同步 HTTP 请求承担完整任务生命周期
传统 Node 服务	Node.js	成熟 npm 生态、长连接、完整 runtime	需要自行承担部署、监控、补丁和扩缩容

这张表不是把所有后端都塞进 Workers。Workers 有 CPU、内存和子请求限制，Supabase 有项目暂停和用量边界，Node.js 则会带来持续运维。一人公司初期可以推迟 Node 服务，但要知道什么时候需要它。

数据归属判断

• 业务数据 → Supabase Postgres 或其他关系数据库，用于关系、事务、查询、触发器和外键。
• 文件 → Supabase Storage 或 R2，按权限、流量、CDN、区域和现有工具链选择。
• 缓存 → KV；需要关系查询的轻量边缘数据可考虑 D1，但缓存不能代替业务事实源。

详细的 D1、Postgres、R2、S3、SQLite 对比留给数据库和存储选型文章，本篇只讲哪类数据归属哪里。

Webhook + 长任务判断

Stripe/GitHub Webhook 可以由 Workers（边缘入口）或 Edge Functions（项目内）接收。处理程序应先验签、写幂等记录并尽快返回；需要浏览器自动化、解析大文件或等待多次第三方回调时，再由队列、Workflow、Container 或 Node.js worker 接手。

Workers Paid 的普通 HTTP 请求 CPU 默认上限为 30 秒，可配置到 5 分钟；Cron Trigger 在执行间隔不少于 1 小时时可用到 15 分钟 CPU。HTTP 请求本身没有固定墙钟上限，只要客户端保持连接，但这不等于适合把长任务绑在请求上：断连、重试、资源限制和部署更新都会增加不确定性。

免费额度警戒线

截至 2026 年 7 月，Workers Free 包含每天 100,000 次请求、每次 10 ms CPU、128 MB 内存和每次 50 个子请求；Supabase Free 包含 50,000 MAU、每项目 500 MB 数据库、5 GB egress、1 GB 文件存储和最多 2 个活跃项目。

这些额度是启动预算，不是长期架构承诺。Supabase Free 项目闲置一周后会暂停，Workers 超出免费额度则需要升级 Paid 计划。只要产品出现稳定用户和付费流程，就应该建立用量告警、成本表和降级策略。

二、Cloudflare Workers：适合什么，不适合什么

Workers 不是万能后端，它的边界主要来自 CPU、内存、子请求和脚本体积，而不是“能否运行 JavaScript”。

Workers Free 额度（截至 2026-07）

Workers Free 每天允许 100,000 次请求，每次 invocation 的 CPU 上限为 10 ms。内存上限为 128 MB，每次 invocation 最多 50 个子请求，压缩后 Worker 大小不超过 3 MB。CPU 超限时会返回 1102；HTTP 请求在客户端保持连接时没有固定墙钟上限，响应结束或客户端断连后，ctx.waitUntil() 最多再延长 30 秒。

Workers Paid 额度（Standard 计划）

Workers Paid 最低费用为每账户每月 5 美元，包含每月 1,000 万次请求和 3,000 万 CPU ms。普通 HTTP invocation 的 CPU 默认上限为 30 秒，可配置到 5 分钟；额外请求每百万次 0.30 美元，额外 CPU 每百万 ms 0.02 美元。每次 invocation 最多 10,000 个子请求，压缩后 Worker 大小上限为 10 MB，内存仍为 128 MB。

适合场景

• 请求入口、边缘代理和轻 API。
• Webhook 接收、签名校验与幂等入队。
• Cron、Queue、Workflow 的触发和编排。
• KV/R2 访问、缓存头、重定向与 A/B 路由。

这些场景的共同点是以网络 I/O、验证和编排为主，不需要把大文件或大型对象完整放进内存，也不依赖浏览器进程和原生系统库。

不适合场景

• 持续 CPU 重计算 → 拆分算法、异步执行，或转向 Node.js / Container。
• 大文件全量缓冲 → 流式处理、客户端直传对象存储，或使用专门文件服务。
• 长浏览器任务 → Node.js + Playwright/Puppeteer 或托管浏览器服务。
• 依赖超出脚本体积或 runtime 兼容范围 → Node.js 服务或容器。

Workers 的 Node.js 兼容层已经覆盖许多 API，但“能打包”不等于“适合运行”。判断时仍要看资源消耗、失败重试、执行时间和运维可观察性。

成本警戒线

如果 Workers 函数平均消耗 5 ms CPU，一个月 1,000 万次动态请求会消耗约 5,000 万 CPU ms。扣除 Paid 计划包含的 3,000 万 CPU ms，额外 CPU 费用约 0.40 美元，此外还可能有 KV、Queues、R2 或其他产品的用量。

计算结果不贵，但真正的警戒线不是某一个账单数字，而是核心功能是否只有在免费额度内才能成立。只要超额会直接破坏毛利或可用性，就应该提前做限流、缓存和降级。

三、Supabase：Auth、Postgres、Storage 和 Edge Functions 边界

Supabase 不是只提供一个 Postgres 数据库，它把 Auth、Storage、Realtime 和 Edge Functions 放在一起。但你仍然需要知道每个模块的边界。

Supabase Free 额度（截至 2026-07）

Supabase Free 为每个项目提供 500 MB 数据库，最多 50,000 MAU、5 GB egress、5 GB cached egress 和 1 GB 文件存储，一个组织最多保留 2 个活跃 Free 项目。Free 项目闲置一周后会暂停，因此它适合验证和低流量项目，不应被当成生产可用性承诺。

Supabase Pro 额度

Supabase Pro 从每月 25 美元起，包含 100,000 MAU、每项目 8 GB 磁盘、250 GB egress、250 GB cached egress 和 100 GB 文件存储。付费计划还包含每月 10 美元 compute credits；额外项目、计算规格、流量、存储和附加功能可能继续计费。

适合场景

• Auth/用户系统：邮箱、OAuth、会话和 RLS 权限模型。
• 业务数据：Postgres 关系数据库、约束、事务和查询。
• 文件存储：带访问策略的用户上传、图片和导出文件。
• Postgres 触发器、函数和数据库迁移。
• 与项目 Auth、Postgres、Storage 紧密协作的 Edge Functions。

如果后端逻辑和 Supabase Auth、Postgres、Storage 强绑定，比如用户登录后写入自己的数据、触发器更新关联表、上传后写文件元数据，Supabase 能减少需要自行维护的组件数量。

Edge Functions 边界

Supabase Edge Functions 使用 TypeScript/Deno 兼容 runtime，适合 Webhook、第三方集成和贴近项目数据的 API。当前托管平台限制包括 256 MB 内存、每次请求最多 2 秒 CPU、150 秒请求 idle timeout；worker 的最大墙钟时间在 Free 计划为 150 秒、Paid 计划为 400 秒。

墙钟时间包含等待 I/O，不等于可以持续占用 CPU。浏览器自动化、原生多线程库、视频处理和大型文件转换仍应移到后台 worker 或专门服务。即使使用 background task，也要受同一 CPU、内存和墙钟上限约束。

Edge Functions vs Workers 判断

• 项目内胶水、与 Supabase Auth/Postgres/Storage 强绑定 → Edge Functions。
• 边缘入口、边缘代理、与 Supabase 没有强依赖 → Workers。

例如 Stripe Webhook 在验签后要更新订阅表并调用 Supabase Auth，这类逻辑放在 Edge Functions 会更直接；如果只做签名检查、限流和转发，Workers 更适合作为独立入口。无论在哪一边，耗时任务都应入队。

项目暂停规则

Free 项目闲置一周后会自动暂停。对于偶尔才被访问的内部工具，这意味着下次请求可能要先等待项目恢复；对于稳定付费产品，则应评估 Pro、备份与迁移方案。不要把 Free 计划当成长期架构承诺。

四、Node.js：什么时候仍需要传统服务

Serverless 和 edge runtime 减少了服务器维护，但没有消除完整 runtime、系统依赖和长期进程的需求。

何时仍需要 Node.js

• 浏览器自动化（Playwright/Puppeteer）。
• 大文件处理、复杂解析和需要临时磁盘的任务。
• native module 或无法放进 edge runtime 的成熟 npm 依赖。
• 长期队列消费者、WebSocket、后台管理 API。
• 需要统一进程模型、可观察性和资源规格的共享后端。

网页截图、PDF 生成、数据抓取、视频转码和大型文件解析通常需要更多 CPU、内存、进程或文件系统能力。它们更适合 Node.js 服务、容器或专门任务平台。

判断清单：需要 Node.js 的信号

当任务经常碰到 Workers 或 Edge Functions 的 CPU、内存、执行时长、脚本体积或 runtime 兼容限制，或者需要浏览器进程、原生模块、长期连接、稳定队列消费时，就该评估 Node.js 服务。

不要只用“是否超过 30 秒”作为判断。Workers Paid、Cron、Queues、Workflows、Containers 和 Supabase Functions 的限制不同；真正的问题是任务是否能在目标平台的资源、重试、幂等和可观察性模型里可靠运行。

何时不需要 Node.js

• 纯 API 转发或边缘路由。
• 以 I/O 为主的轻量验证和数据写入。
• 没有重文件处理、原生依赖和长期连接。
• 产品还没有足够需求抵消服务器运维成本。

这些场景可以先用 Workers 或 Supabase Edge Functions，不需要维护独立 Node 服务。

Node.js 不是“过时”

Edge runtime 的约束换来低运维和全球分发，Node.js 的完整 runtime 则换来依赖兼容、资源控制和长期进程。两者不是新旧替代关系，而是职责不同。一人公司可以先用 Workers + Supabase 闭合轻 API、Webhook、认证和业务数据，再在浏览器自动化、文件处理或复杂依赖成为真实需求时引入 Node.js worker。

五、Workers + Supabase 组合：API client 还是 Hyperdrive

Workers 和 Supabase 通常不是竞品，而是“边缘请求入口 + 身份与业务数据”的组合。

Workers + Supabase 组合

Workers 处理请求转发、校验、限流与缓存；Supabase Auth 和 Postgres 承载用户身份、业务数据和权限策略。这种组合适合轻查询、验证后写入和不想维护服务器的第一版产品。

如果 Worker 只需要调用 Supabase Auth、Data API 或 Storage，supabase-js 已经够用。如果需要使用 SQL、事务或 ORM 频繁访问 Postgres，则应考虑数据库驱动和连接池，而不是让每个边缘 invocation 建立新的直连。

连接方式判断表

连接方式	适用场景	说明
Supabase JS Client	Auth、Storage、轻查询、简单操作	通过 Supabase API 访问，能沿用 JWT 与 RLS
Hyperdrive + 数据库驱动	频繁 SQL、ORM、Postgres 直连	Cloudflare 在网络内维护连接池，并可缓存适合的只读查询
service role / secret key	可信后端的管理操作	可绕过 RLS，只能在隔离的后端客户端中使用

Hyperdrive 支持连接 Supabase Postgres，能减少分布式 Worker 反复建立数据库连接带来的延迟和连接压力。但它不是权限系统：直连使用哪个数据库角色、能访问哪些表、是否执行 RLS，仍由 Postgres 凭证与策略决定。

Service Role Key 风险提醒

Supabase 的 service role key 或服务端 secret key 拥有高权限，可绕过 RLS。它们不得暴露到浏览器、移动客户端、公开仓库或日志，只能放在可信后端的 secret 环境中。

还要为管理操作单独创建服务端 Supabase client，避免用户会话覆盖 Authorization 头后改变 RLS 行为。Webhook 验签、后台批处理和管理员操作应使用最小权限与独立审计，而不是把高权限 key 当成通用捷径。

Edge Functions vs Workers 职责边界

• 与 Supabase Auth、Postgres、Storage 强绑定 → Edge Functions。
• 独立边缘入口、代理、限流和路由 → Workers。

这个边界不是绝对的。选择时看数据与权限是否以 Supabase 为中心、是否需要 Cloudflare 边缘能力，以及团队想在哪一边统一日志和部署。只要涉及高权限 key，两边都必须遵守后端 secret 边界。

六、数据归属：业务数据、文件、缓存分别放哪里

D1、Postgres、KV、R2 都能存数据，但它们解决的问题不同。

数据归属判断表

数据类型	推荐归属	判断依据
业务事实	Supabase Postgres / D1 / 其他关系数据库	关系、事务、约束、查询、迁移和权限
文件对象	Supabase Storage / R2 / S3	访问控制、流量、CDN、生命周期和工具链
缓存与配置	KV / Cache	低延迟读取、可重建、容忍一致性边界

用户、订单、订阅、项目和权益这类会影响收费或访问权的数据，应进入有约束、迁移和备份策略的业务数据库。Postgres 提供复杂查询、外键、触发器、事务完整性和 MVCC；D1 也可以承载轻量关系数据，但需要独立评估一致性、扩展和平台边界。

文件存储不应按“是否超过 1 GB”一刀切。Supabase Storage 适合与 Auth/RLS 紧密结合的用户文件，R2 适合与 Cloudflare 流量和 CDN 体系结合的对象；应按访问控制、出站流量、上传方式、转换需求和现有 SDK 选择。

缓存放边缘，但缓存不是主业务库。KV 适合配置与可重建的读多写少数据；如果订单或权益只存在缓存里，一次过期、延迟同步或误删就会影响真实业务状态。

详细的 D1、Postgres、R2、S3、SQLite 对比留给数据库和存储选型文章，本篇只讲哪类数据归属哪里。

七、下一步：系列后续和延伸阅读

本篇回答了后端职责怎么分配，后续内容会覆盖后端部署、数据库和存储选型、支付集成，以及认证、授权和权限模型。

站内已有内容

如果还需要核对平台边界，可以继续阅读 Cloudflare Pages 部署指南、Cloudflare Free Plan Limits 2026、Workers API 代理实战、Supabase 入门 和 Supabase Edge Functions 实战。

先完成一张自己的职责表

列出本周必须上线的 5 个后端动作，为每项标记“立即响应 / 身份权限 / 业务事实 / 文件 / 异步任务 / 敏感密钥”，再决定放到 Workers、Supabase、Node.js 还是暂缓。平台只是实现手段，职责和失败路径才是第一版后端能否稳定运行的边界。