壹贰线报 · 官方定价页核实 · 2026 年 10 月
Supabase 免费版默认完全不备份。这几乎是每个用 Supabase 做独立项目的开发者，迟早都会踩的坑：
一次"DELETE FROM users"忘写 WHERE，整个用户表清零；
一次 RLS 策略改坏，前端批量删除被放行；
项目连续 7 天没访问被自动暂停，恢复时出问题；
甚至最狠的——项目被自己或队友误删。
Supabase 官方的备份方案是付费档才有的日备份 + PITR 时点恢复（Pro 起步 $25/月，PITR 加 $100/月），而且官方备份不包含 Storage 文件、不包含 Edge Functions 代码、项目被删时也救不回来。
这就是 ReviveDB 想补的缺口：它是一款专门为 Supabase 做备份的第三方工具，免费版就能每周自动备份、保留最近 3 个恢复点，而且每次备份都先做一遍"恢复测试"，验证通过了才算成功。免费版不用绑信用卡，邮箱注册就能用。
你给的清单，和官方现行规则对一对
你列的"1 个项目、每周备份、3 个恢复点"这三条都准确，但有几项关键信息没写，还有一条是实操里最容易踩的"隐形账单"。
能力 | 你给的信息 | 现行 Free 实际规则 | 判定 |
|---|---|---|---|
项目数 | 1 个 | 1 个 Supabase 项目 | ✅ 准确 |
备份频率 | 每周备份 | Weekly（每周） | ✅ 准确 |
恢复点数量 | 3 个 | 保留最近 3 个备份（≈ 三周滚动覆盖） | ✅ 准确 |
数据库备份 | 数据库 + Auth | 数据库 + Auth 用户（所有表、RLS 策略、函数、用户账号） | ✅ 准确 |
Storage 文件 | 存储文件 | 每项目最多 1GB Storage（压缩后） | ⚠️ 有上限 |
Edge Functions | Edge Functions | 备份并做哈希校验（含部署配置、环境变量、Secrets 不含明文） | ✅ 准确 |
项目配置 | 项目配置 | 基础配置 + 部署信息 | ✅ 准确 |
数据库大小上限 | 未提 | 数据库 ≤ 1GB（压缩后逻辑备份） | ❗ 重要限制 |
备份处理流量 | 未提 | 5 GB / 月（压缩后数据库 dump + 新增 Storage 字节，未变更文件复用不重复算） | ❗ 重要限制 |
备份存储空间 | 未提 | 5 GB / 账号（所有项目共享） | ❗ 重要限制 |
自动恢复校验 | 提到"比对成功才算可用" | ✅ 每次备份都先恢复到临时环境跑一遍测试，Auth/DB/Storage/Functions 分别校验通过才算作数 | ✅ 准确且是核心卖点 |
备份存储位置 | 未提 | 欧盟数据中心（GDPR 合规） | ⚠️ 补充信息 |
数据库密码 | 未提 | 通过 Supabase OAuth 授权，大多数项目不需要交数据库密码 | ⚠️ 补充信息 |
数据导出 | 未提 | 随时可下载原始备份文件 | ⚠️ 补充信息 |
Supabase 侧费用 | 未提 | ❗ Supabase 可能把备份读取的数据计入 egress 出网流量，ReviveDB 不收钱，但 Supabase 那边可能收（Free 有 10GB/月 egress 额度） | ❗ 实操大坑 |
这是 ReviveDB 的真正价值：不是"多一份拷贝"，而是"真的能恢复"
很多人理解的备份工具就是"定时 pg_dump + 存 S3"，但真正的灾难恢复不是有一份 dump，而是你确定这份 dump 真能恢复。ReviveDB 最核心的卖点就写在首页：
Every backup of your data is restored as a test before it counts. 每一份备份在算作可用之前，都会先被恢复为测试环境跑一遍。
它把 Supabase 项目拆成四块分别备份，每块做不同粒度的校验：
模块 | 备份内容 | 校验方式 |
|---|---|---|
数据库 + Auth | 所有表、数据、RLS 策略、Postgres 扩展、触发器、函数、用户账号 | Restore-tested：恢复到临时 PG 实例，验证所有 118 张表、1280 个用户等能正常载入 |
Storage 文件 | 所有用户上传的文件（图片、文档等） | Hash-checked：对每个文件做哈希比对，确保字节级一致；未变更文件增量复用，不重复占用配额 |
Edge Functions | 所有函数代码 + 部署配置（函数名、路由、版本、环境变量名称） | Hash-checked：哈希校验部署包；Secrets 只存引用，不能备份明文值 |
项目配置 | 基础配置、域名设置、API keys 元数据等 | 元数据比对 |
Supabase 官方备份的三大盲区正好就是 ReviveDB 补的：
对比项 | Supabase 官方备份 / PITR | ReviveDB |
|---|---|---|
数据库 + 用户 | ✅ 包含 | ✅ 包含 |
Storage 上传文件 | ❌ 不包含 | ✅ 包含 |
Edge Functions 代码 | ❌ 不包含 | ✅ 包含 |
恢复校验 | ❌ 未做恢复测试 | ✅ 每次都测 |
项目被删后可救回 | ❌ 项目删了备份一起没 | ✅ 备份存在 ReviveDB 的欧盟存储，独立于 Supabase |
免费版可用 | ❌ Free 无备份 | ✅ Free 就能用 |
免费版能做什么、不能做什么
免费版 Free（€0，无需信用卡）
✅ 绑定 1 个 Supabase 项目；
✅ 数据库备份上限 1 GB（压缩后，足够绝大多数 MVP/早期 SaaS 用）；
✅ Storage 每项目 1 GB（用户上传文件）；
✅ 每周自动备份一次；
✅ 滚动保留最近 3 个备份（约 3 周历史，可回滚到 1、2、3 周前任一次）；
✅ 每月最多处理 5 GB 新备份数据（压缩后，未变更文件不重复计费）；
✅ 账号级备份存储 5 GB；
✅ 每次备份都自动做 restore test，Dashboard 显示"100% restore tests passed"；
✅ 通过 Supabase OAuth 授权，不用交数据库密码；
✅ 所有备份存储在欧盟数据中心（GDPR 合规）；
✅ 随时下载原始备份文件；
❌ 没有每日备份（只能 weekly）；
❌ 只能 1 个项目（多项目需付费）；
❌ 数据库超过 1GB 无法备份；
❌ 不支持 Edge Function Secrets 明文备份（安全设计，需在恢复时手动重新填入）；
❌ 不支持 Hourly 小时级备份（Scale 档按需开通）。
付费档速览（方便对比）
档位 | 价格 | 项目 | 数据库 | Storage | 频率 | 保留期 |
|---|---|---|---|---|---|---|
Free | €0 | 1 | 1GB | 1GB/项目 | 每周 | 3 个备份 |
Pro（推荐生产） | €9/月 | 3 | 10GB/项目 | 25GB/项目 | 每天 | 30 天 |
Scale | €29/月 | 10 | 10GB/项目 | 25GB/项目 | 每天 | 60 天（可申请 Hourly） |
€9/月 约合人民币 ¥70 左右——相比 Supabase 自己 Pro 档 $25/月才带的 7 天日备份 + PITR 加 $100/月，ReviveDB 的 Pro 档是在 Supabase Free 项目上花 €9/月获得完整备份能力，对"不想升 Supabase Pro、但项目有真实用户"的独立开发者来说相当划算。
最容易踩的一个坑：Supabase 侧的 egress 流量费
ReviveDB 官方定价页底部有一行小字，是很多人忽略的：
Possible Supabase charges. Supabase may count the data a backup reads as outgoing traffic. We add nothing on top. 可能产生 Supabase 侧费用。Supabase 可能把备份读取的数据计入出网流量，ReviveDB 不额外加价。
这意味着——即使 ReviveDB 不收费，Supabase 那边也可能按 egress 计费：
如果你用的是 Supabase Free 档，有 5GB 普通 + 5GB cached = 10GB/月 egress 免费额度，每周一次完整备份 + Storage 扫描在数据库 1GB 以内的情况下基本不会超；
如果你用的是 Supabase Pro 档，egress 按 $0.09/GB 计费，数据库 1GB 每周一次全量扫描一个月大约 4–5GB，对应 $0.4 左右，几乎可以忽略；
真正要注意的是大库 + 高频备份场景——但免费版本身就限制了数据库 1GB 且每周一次，这个风险被天然限住了。
适合什么人用 / 不适合什么人用
适合：
跑在 Supabase Free 档上、已经有真实用户但不想每月付 $25 升 Pro 的早期项目；
想给 Supabase Pro 档补 Storage/Edge Functions 备份的项目（官方备份不含这两块）；
做 Lovable / Cursor / v0 等 AI 生成应用，担心"一键生成上线后误操作删库"的人；
有 GDPR/数据出境合规需求，希望备份留在欧盟的团队；
想要"不是我自己信誓旦旦说备份好了"，而是每次都被自动验证过的恢复点的人。
不适合：
数据库已经超过 1GB（免费版 1GB 硬上限，得升 Pro）；
需要每天甚至每小时备份的项目（免费版只能每周，小时级需 Scale 档联系开通）；
需要 Supabase 项目级自动恢复（ReviveDB 是恢复到新的/现有 Supabase 项目，不是在原项目做 PITR 回滚）；
Edge Function Secrets 没做自己记录的——ReviveDB 出于安全不备份 Secrets 明文，恢复后要手动填回。
7 步接一个免费 ReviveDB 备份
打开 https://revivedb.dev，点「Create free account」，邮箱注册（无需信用卡）。
登录后点击「Connect Supabase」，通过 Supabase OAuth 授权 ReviveDB 访问你的项目（不用直接给数据库密码）。
在项目列表里选要备份的那 1 个 Supabase 项目（免费版只能绑定一个）。
确认数据库大小 ≤ 1GB、Storage ≤ 1GB——超限会在连接时提示。
授权后第一次备份立即开始（"The first backup starts right away and shows what can be recovered"）。
等首次备份跑完，Dashboard 会显示"Database · X tables / Auth users · X users / Storage files · X files / Edge Functions · X functions"，每一项标注 Restore-tested 或 Hash-checked，以及整体"restore tests passed"百分比。
之后每周自动跑一次，滚动保留最近 3 份；出问题时在 Dashboard 点对应恢复点 → 选择恢复到现有项目或新 Supabase 项目。
文末互动话题
🔍 本期互动
你现在的 Supabase 项目有做备份吗？是用 Supabase CLI 自己写 cron、Supabase 官方 Pro/PITR、还是用 ReviveDB/SupaBackup 这类第三方工具？
你有没有遇到过"以为做了备份，真要恢复时却发现 dump 是坏的"的坑？欢迎分享你的踩雷经历。
在"免费版只能周备份 + 3 个恢复点"和"€9/月 Pro 每天备份 + 30 天保留"之间，你觉得独立开发者最理想的备份频率是多少？