双视角说明：本篇合并了同一议题的两份调研。默认 Opus 4.7 版覆盖全栈对比、价格与站长结论；切到 Composer 2.5 版看 Vibe Coding 场景选型与提示语模板（可用
?v=cursor直达）。
一、是什么
两者都是"做 Web 应用不想自己运维服务器"的全栈基础设施，但起点完全不同。
Cloudflare Workers + D1
- Workers：V8 isolate 在 Cloudflare 全球 ~330+ 城市的边缘节点跑你的 JS/TS 代码。冷启动 ~5ms。
- D1：基于 SQLite 的边缘分布式数据库。主副本在一个区域，自动同步只读副本到其它区域。目前已 GA（2024 年），但读副本（Read Replication）是 2025 年初转入 Beta → 2026 年初转入 GA。
- 配套服务（全部独立产品，各自计费）：KV、R2（S3 兼容对象存储）、Queues、Durable Objects、Workers AI、Vectorize（向量数据库）、Hyperdrive（外部 Postgres 加速）、AI Gateway、Browser Rendering、Email Routing、Pages、Stream（视频）、Images……
- 官方文档：developers.cloudflare.com
Supabase
- Postgres 数据库：完整的 Postgres（不是简化版），可装 pgvector / PostGIS / pg_cron 等扩展。单区域部署（创建项目时选区域），无自动多区域分发。
- PostgREST：把 Postgres 表自动暴露成 REST API；通过 RLS（行级安全）做权限控制。
- 配套服务（全部围绕 Postgres）：Auth（GoTrue）、Storage（S3 兼容）、Realtime（Postgres 逻辑复制）、Edge Functions（Deno Deploy）、Vector（pgvector）、Queues（pgmq）。
- 官方文档：supabase.com/docs
世界观差异
| 维度 | Cloudflare | Supabase |
|---|---|---|
| 起点 | 边缘 CDN + Workers 计算 | Postgres + BaaS |
| 数据库模型 | SQLite（D1）、KV、R2 | Postgres |
| 默认部署形态 | 全球边缘 | 单区域 |
| 服务粒度 | 多个独立服务，自己拼装 | 大礼包，开箱即用 |
| 开发者画像 | 偏 infra 工程师 / 想精细控制 | 偏前端 / 全栈 / 创业产品 |
| 价格模型 | 按调用 / 按存储分别计费 | 按项目套餐 + 超额 |
二、为什么重要
- 这是 2026 年「个人开发者 / 小团队做 SaaS / 内容站 / 工具站」最热的两条路线
- 价格对 Agent 工程师极友好（Cloudflare 几乎可以 0 元跑出 10 万 PV/月；Supabase 免费版能跑完整 Auth + 数据库的 MVP）
- 选错了不致命但迁移成本不低 — 尤其是 Auth 和数据库 schema 一旦绑定，搬家是大工程
三、关键玩家与生态
Cloudflare 生态
- 自家全栈：Workers / D1 / R2 / Pages / KV / Queues / Vectorize / Workers AI
- 框架适配：Hono、Next.js on Workers、Remix、SvelteKit、Astro、TanStack Start
- Auth 第三方：Better Auth、Clerk、WorkOS、自研（D1 + 邮件 OTP）
- 邮件：Resend（CF 没有自己的事务邮件产品）
Supabase 生态
- 自家全栈：Database / Auth / Storage / Realtime / Edge Functions / Vector / Queues / Branching / Cron
- 框架适配：Next.js、Nuxt、SvelteKit、Remix、SolidStart、Expo、Flutter；官方 SDK 覆盖 JS/Python/Dart/Swift/Kotlin
- 部署搭配：常和 Vercel / Netlify / Fly.io 搭配（不是替代关系）
- 客户案例：1Password、Mozilla、PwC、Replicate、Resend（注：Resend 自己用 Supabase）
横向竞品
- 完全 Postgres BaaS：Neon（serverless Postgres + Branching）、Xata、Nhost
- 边缘数据库：Turso（libSQL，SQLite 边缘分发，和 D1 最像）、PlanetScale（MySQL，2024 年取消免费版）
- 全栈 BaaS：Appwrite、Pocketbase（自托管）、Convex
四、技术 / 实施细节
4.1 数据库层
| 维度 | Cloudflare D1 | Supabase Postgres |
|---|---|---|
| 引擎 | SQLite | Postgres 15/16 |
| 部署 | 主副本在一区域，只读副本自动分发到全球 | 单区域（创建时选） |
| 单库容量 | 10 GB / 库（免费 + 付费同款上限） | 免费 500 MB，Pro 8 GB，可升到 1 TB+ |
| 写入吞吐 | 中等（SQLite 写锁，单写者） | 高（Postgres 标准） |
| 读延迟 | 全球边缘 < 50ms（命中 read replica） | 取决于客户端到区域距离 |
| 事务 | 完整 SQLite 事务；不支持跨库事务 | 完整 Postgres 事务 |
| 扩展能力 | 受 SQLite 限制（无 stored procedures、有限的 JSON 操作） | 强（pgvector、PostGIS、pg_cron、pgmq、pg_graphql 等几十种） |
| 备份 | Time Travel（30 天，付费 plan 30 天，免费 7 天） | PITR（Pro $25/mo 含 7 天；可加购到 28 天） |
| 迁移工具 | wrangler d1 migrations |
supabase migration + Branching |
| 锁机制 | 库级写锁 | 行级锁，MVCC |
关键观察：
- 如果应用是"读多写少 + 全球用户"（内容站、博客、个人工具）→ D1 优势巨大，边缘读延迟无敌
- 如果应用是"重事务 + 复杂查询 + 高并发写"（电商订单、协作工具、IM）→ Postgres 更合适，D1 的单写者限制会成为瓶颈
4.2 计算层
| 维度 | Workers | Supabase Edge Functions |
|---|---|---|
| 运行时 | V8 isolate（Node 兼容层 nodejs_compat） |
Deno（V8 + 原生 TypeScript） |
| 冷启动 | ~5 ms | ~50–100 ms |
| 单次执行时长 | 30s CPU（Free），无限挂壁时间到 30 分钟（Paid） | 默认 150s（可调） |
| 内存上限 | 128 MB | 256 MB |
| 部署形态 | 全球边缘 | 全球边缘（Deno Deploy 底层） |
| 调用模式 | HTTP / Cron / Queue / RPC / Email | HTTP / Cron / Webhook（DB Trigger） |
| 包大小 | 10 MB（压缩后） | 20 MB |
| 价格 | $5/mo 10M 请求；超出 $0.30/M | $25/mo 套餐内 2M 调用；超出 $2/M |
关键观察：
- Workers 冷启动远好于 Edge Functions（毫秒级 vs 几十毫秒）
- Edge Functions 单次执行时长更宽松，适合稍重的处理（PDF 生成、邮件批处理）
- 两者都不适合长任务（图像/视频处理 > 5 分钟 → 都要换方案）
4.3 周边服务对比
| 能力 | Cloudflare 方案 | Supabase 方案 |
|---|---|---|
| Auth | 自研（D1 + JWT）/ Better Auth / Clerk / WorkOS | Supabase Auth（GoTrue）：Email+Password、Magic Link、OAuth（Google/GitHub/Apple/40+）、Phone、Anonymous、SAML、MFA |
| 对象存储 | R2（S3 兼容、免出流量费） | Supabase Storage（S3 兼容、出流量计费） |
| Realtime | Durable Objects + WebSocket（自己写状态机） | Supabase Realtime（Postgres 表变更 / 广播 / Presence 一行代码订阅） |
| 向量 | Vectorize（独立产品，5M 索引免费） | pgvector（直接 SQL，与业务表 JOIN 自然） |
| 队列 | Queues（每月 1M 操作 $0.40） | pgmq / Queues（基于 Postgres，2025 GA） |
| 定时任务 | Cron Triggers（Workers 自带） | pg_cron / Edge Functions Cron |
| 全文搜索 | 无自研（用 D1 FTS5 / R2 + 第三方） | Postgres 全文搜索（tsvector） |
| 数据库分支 | 无原生 | Branching（每个 PR 一个隔离数据库） |
| 邮件 | Email Routing（只能收信和路由，不能发） | 无自研（Auth 邮件用 Resend / SendGrid） |
| CDN/边缘缓存 | 自家 CDN 是世界第一梯队 | 无（依赖 Vercel/Netlify） |
关键观察：
- Supabase 的 Auth + Realtime + Branching 是 Cloudflare 没有对位产品的"杀手锏"
- Cloudflare 的 R2（免出流量费）+ CDN + 边缘网络 是 Supabase 无法对位的"基础设施降维"
- 两者都是"用 80% 的能力换 20% 的灵活性" — 真实项目里常常两个一起用（Workers 跑边缘 + Supabase 当数据库）
4.4 价格（2026 年现行）
Cloudflare（按服务独立计费）
| 服务 | 免费额度 | 付费 |
|---|---|---|
| Workers | 100,000 请求/天 | $5/mo 含 10M 请求；超出 $0.30/M |
| D1 | 5 GB 存储；5M 行读/天；100k 行写/天 | $5/mo 含 25B 行读 + 50M 行写 + 5GB；超出 $0.001/M 读、$1/M 写、$0.75/GB |
| R2 | 10 GB 存储；100 万次 A 类请求/月；1000 万次 B 类/月；出流量永远免费 | $0.015/GB 存储，$4.5/M 写，$0.36/M 读 |
| Vectorize | 30M 向量维度查询 + 5M 存储维度（约 10k 1536 维向量） | $0.04/M 查询维度，$0.05/100M 存储维度 |
| Workers AI | 10k Neurons/天 | 按模型计 |
| Queues | 100 万操作/月 | $0.40/M |
| KV | 100k 读 + 1k 写/天 | $0.50/M 读，$5/M 写 |
| Pages | 500 builds/月，免费部署 | 同样免费部署，仅 build 时间收费 |
Supabase（按项目套餐）
| 套餐 | 月费 | 包含 |
|---|---|---|
| Free | $0 | 500 MB DB；1 GB Storage；5 GB egress；50k MAU；2M Edge Functions 调用；项目 7 天不活动会被暂停；最多 2 个 Free 项目 |
| Pro | $25 / 项目 | 8 GB DB；100 GB Storage；250 GB egress；100k MAU；2M Edge Functions；7 天 PITR；Branching |
| Team | $599 / 月（组织级） | SOC2、SSO、24h SLA |
| 超额 | — | DB $0.125/GB；Storage $0.021/GB；Egress $0.09/GB；Auth $0.00325/MAU |
典型对比场景：一个 10 万 PV/月、5 GB 数据、50k 用户的内容站
| 项目 | Cloudflare | Supabase |
|---|---|---|
| 请求 | Workers 10 万 × 30 = 300 万 → 免费内 | 包含 |
| 数据库 | D1 5 GB → 免费内 | 8 GB 套餐内 |
| 存储 | R2 几 GB → 免费内 | 1 GB 免费 / 超出付费 |
| 出流量 | R2 出流量 0 元 | $0.09/GB |
| Auth | Better Auth 自部署（D1 内） | Supabase Auth |
| 月费估算 | $0 | $25 |
Supabase 不是更贵，是把多个服务打包；Cloudflare 不是更便宜，是把成本分散到每个独立服务，只有当某些服务用量极小时才显得便宜。
4.5 真实开发体验
本地开发
| 维度 | Cloudflare | Supabase |
|---|---|---|
| CLI | wrangler |
supabase |
| 本地数据库 | Miniflare 内置 SQLite（与 D1 同样语法） | Docker 启动完整 Postgres + 所有服务 |
| 启动速度 | 秒级 | 1–3 分钟（Docker 下载/启动） |
| 离线开发 | ✅ 完全离线可用 | ✅ 完全离线可用 |
| 真实环境一致性 | 高（Workers runtime 在本地完全模拟） | 高（本地起的就是真实 Postgres） |
迁移与变更
- D1：
wrangler d1 migrations create / apply，文件化 SQL 迁移。不支持 schema diff，需要手写。 - Supabase：
supabase migration new，文件化 SQL；支持 db diff、db lint、db push。Branching 让 PR 级别 schema 变更很丝滑。
可观测性
- Cloudflare：Workers Logs（30 天免费）、Trace、Analytics Engine、Logpush（付费推到 R2/S3）；D1 有 Insights 看慢查询
- Supabase：Dashboard 自带 logs、metrics；可装 pg_stat_statements
"心智模型"差异（最重要）
- Cloudflare：你写代码 + 自己拼几个服务。每个服务都有自己的 binding/env，所有交互都是 RPC，灵活但繁琐。Auth 需要自己想清楚每一步。
- Supabase：你写代码 + 用 SDK 调 Supabase。Auth 是一行
supabase.auth.signInWithPassword(...)，Realtime 是一行.subscribe(...)，几乎零样板。
五、争议与风险
Cloudflare 侧
- D1 写吞吐天花板：SQLite 单写者特性使其在 > 1000 QPS 写入场景容易瓶颈；官方建议跨多个 D1 库做 sharding，但这是应用层负担。
- D1 多区域写：仍是"主副本单点"。Cloudflare 在推 Durable Objects + SQLite 的方向（每个 DO 一个 SQLite），但生态成熟度低。
- Workers 没有内建 Auth：必须依赖第三方（Better Auth 是当下最佳选择）或自研，对初学者门槛高。
- 生态分散：D1 + R2 + Vectorize + Durable Objects 每个都有自己的概念，学习曲线长。
- 某些定价隐性变化：D1 row reads 计费在 2024 年改过定义，每次 schema 操作可能计算多次 row read，真实账单可能比预期高。
- vendor lock：D1 SQLite 数据可以导出（标准 SQL），但 R2、Durable Objects、Workers KV 都没有真正的"标准"接口，迁出代价不低。
Supabase 侧
- 单区域风险：默认部署在一个区域，跨区域用户延迟高；多区域要 Read Replicas（Team 套餐及以上）或自己做。
- Free 套餐项目 7 天不活动暂停：对副业/小工具不友好，需要定期 ping。
- Auth 锁定：用了 Supabase Auth 后想迁出几乎要重做（迁移 GoTrue users 表理论可行，OAuth provider 配置全要重来）。
- PostgREST 性能：自动生成的 REST API 在复杂查询/聚合场景下不如手写 SQL/RPC，且 RLS 写得不好容易性能塌方。
- Edge Functions 不如 Workers 快：冷启动 ~50–100ms，对低延迟场景不够顶级。
- 大文件 / 大流量场景的出流量费贵：Pro 200 GB egress 后 $0.09/GB —— 一个图站很容易超。
- Supabase 自身命运：2024–2025 是融资和增长黄金期，但成本不低；如果未来调整 Free 套餐（学 PlanetScale 取消免费），对小项目是巨大冲击。
- 2026 年新动态：Supabase 在 2025 年增加了 Snaplet（数据 seeding）、Edge Functions deno 2 支持、Branching GA，整体方向是"更全栈"。
六、个人结论
一句话定性
Cloudflare 是"乐高 + 边缘第一"，Supabase 是"Postgres + 大礼包" —— 没有谁更好，只有谁更匹配你的画像。
站长视角：当前栈 = Cloudflare 全家桶 + Resend + D1，要不要碰 Supabase？
| 维度 | 判断 |
|---|---|
| 是否要迁移现有项目到 Supabase | 🔴 不要。当前栈已经稳定、成本极低、性能好；Supabase 的核心增量是 Auth，但 Resend OTP + D1 这条 Auth 路径已经在跑（参见 Resend Email OTP + Cloudflare D1 实践），没必要换。 |
| 是否要把 Supabase 加入"备选清单" | 🟢 要。两种场景值得：① 如果某天需要复杂 Postgres 能力（pgvector + 复杂 JOIN + GIS）；② 如果要做一个"重 Realtime"的应用（多人协作、Presence）—— Cloudflare 的 Durable Objects 写起来麻烦得多。 |
| 是否要试一下 Supabase Auth | 🟡 观望。如果 Better Auth + Resend OTP 哪天踩坑无法解决，再启用。不要为了试而试，Auth 一旦上线迁移成本极高。 |
| 是否值得花时间学 Supabase 体系 | 🟡 学一遍核心 API 就好（Auth + Realtime + Storage 的客户端调用方式），别深入到 RLS 和 Postgres 调优 —— 那是另一种心智模型，对当前栈帮助不大。 |
下一步行动
- 不动现有项目：CF + D1 + Resend 跑得好就别折腾
- 新建一个 Supabase Free 项目做 sandbox：30 分钟体验 Auth + Realtime + Storage 的开发流，建立"备胎认知"
- 保留 Cloudflare 的核心定位：边缘网络 + R2（出流量 0 元）+ Workers AI / Vectorize 是不可替代的护城河
- 真要做一个"重 Postgres / 重 Realtime"的应用（如多人协作工具、聊天工具），优先 Supabase 主体 + Cloudflare 做 CDN/Workers 边缘的混搭
- 价格预警：如果 Supabase 调整 Free 套餐（不再活跃暂停 / 取消免费），立即放弃备选清单
七、信息来源
Cloudflare 官方
- Cloudflare Developers
- Workers Documentation
- D1 Documentation
- D1 Read Replication
- R2 Pricing
- Vectorize
- Workers Pricing
- D1 Pricing
Supabase 官方
横向参考
- Turso（D1 的最近竞品）
- Neon（Supabase 的最近 DB-only 竞品）
- Better Auth（Workers 上自建 Auth 的事实标准）
- Hono（Workers/Edge Functions 上最流行的轻量框架）
Discussion
讨论
还没有讨论