Supabase Auth 免费版全拆解：50,000 MAU 是真的，但别把短信 OTP 当成免费

大家好，我是壹贰。今天继续「云平台免费额度」系列，聊一款被独立开发者和小团队捧成「Firebase 开源平替」的 BaaS 产品——Supabase Auth。

后台收到多份资料，都在推「Supabase 免费版带完整身份认证，可跑生产」。我专门对着 Supabase 官方定价页（最后更新 2026 年 1 月的版本）、官方 Auth 文档和几个独立开发者踩坑记录核了一遍，结论是：

免费额度确实慷慨，但有几处描述和实际规则不一致，最大的三个坑和 Auth 直接相关。

先把你最关心的结论放前面：

一、先更正三处关键数字

你在网上能搜到的「Supabase 免费版」资料，大部分是 2024 年之前的老口径。2026 年现行 Free 计划（以 supabase.com/pricing 为准），核心额度是这样的：

第一处更正：「每月 1GB 出站流量」是很早以前的老规则了，现在是 5GB 普通 egress + 5GB 缓存 egress，合起来 10GB，对只做接口调用的小项目够宽裕；但如果你直接用 Supabase Storage 给前端吐图片/视频，5GB 很快就没了——超额部分 $0.09/GB，Pro 档才真正宽裕（250 GB）。

第二处更正：免费版根本就不是为长期生产准备的。连续一周（7 天）没有任何访问，项目会被 Supabase 自动暂停，直到你进后台点「Resume」才能恢复。Demo、预发布环境、演示项目踩过这个坑的人无数——发给客户的链接点进去是「Project Paused」页面，相当尴尬。官方文档把这个机制写得很清楚：Free 项目的设计目标就是「passion projects & simple websites」，生产环境请上 Pro（$25/月）。

第三处更正（也是本篇最重要的）：短信/WhatsApp OTP 不包含任何免费短信额度。

二、逐条拆：Auth 免费版到底有哪些

Supabase Auth 的免费权益，官方文档写得比较细，我把它和你给的信息对照一遍：

✅ 真实免费、无隐藏限制的部分

1. 邮箱 + 密码登录：全量免费，含注册、登录、找回密码、邮箱验证。免费版可以自定义 SMTP（用自己的发件邮箱，不会被 Supabase 的公共发件域名限制），这一点比某些竞品厚道。

2. Magic Link（魔法链接）+ 邮箱 OTP：无密码登录完全免费——用户输入邮箱，点邮件里的链接或填 6 位码直接登录，不占任何外部资源额度。

3. 社交 OAuth 登录：官方原生支持的社交提供商一共 20+ 家，包括 Apple、Google、GitHub、Discord、Facebook、Figma、GitLab、Bitbucket、Kakao、Keycloak、LinkedIn、Notion、Slack、Spotify、Twitter/X、Twitch、WorkOS、Zoom、Azure（Microsoft）等，免费版没有数量上限，想开几个开几个。

⚠️ 重要的坑：官方原生列表里没有微信、没有钉钉、没有支付宝、没有企业微信。国内 ToC 想做微信一键登录，要么用「Custom OAuth/OIDC Provider」自己对接（需要你自己写中间层走微信开放平台，不是一键勾选），要么用国内厂商（Authing、阿里云 IDaaS、腾讯云 CIAM）。BytePlus（火山引擎国际版）的 Supabase 托管版能配微信授权，但那是 BytePlus 二次封装的，不是 supabase.com 官方。

4. 基础 MFA（TOTP 认证器 App）：免费版开放 TOTP 多因素认证（Google Authenticator、Authy、1Password 等），可以用 RLS 策略绑定 JWT 的 aal2 断言，实现「未过二次验证看不到敏感数据」的权限控制。

5. 行级安全（RLS）+ 完整 Postgres 角色体系：这一点是免费的，而且是 Supabase 的看家能力。

• auth.uid() 直接取当前登录用户 ID，可以在策略里和业务表的 user_id 绑定；

• 支持 anon（匿名）、authenticated（已登录）、service_role（服务端跳过 RLS）三个内置角色；

• 可以自己建 Postgres 角色、配 Policy，实现「免费用户 / Pro 用户 / 管理员」分层访问；

• Policy 写在数据库侧，前端 SDK 即使被逆向也绕不过——这一点比 Firebase Rules 更接近企业级权限模型。

6. 匿名登录（Anonymous Sign-in）：免费版支持，适合「先让用户玩，再引导注册」的产品形态，匿名用户后续升级为正式账号时数据可无缝迁移。

7. OAuth 2.1 服务端、JWT 会话管理、自定义邮件模板：都在免费档。

❌ 需要自备/付费、不算在免费里的部分

1. 短信 / WhatsApp OTP：Supabase 只提供调用接口，短信通道要你自己配 Twilio / MessageBird / Vonage / Textlocal，短信费直接付给这些运营商，Supabase 不送任何免费短信额度。做手机号登录的同学，这一块成本要自己算。

2. 高级 MFA（短信 MFA）：$75/月/项目 的 Add-on，Free/Pro 都要另买。

3. 企业 SSO（SAML 2.0）：在 Team 档（$599/月起），Pro 档最多 50 个 SAML 连接，Free 档不开放。

4. 自定义域名：Pro 档 Add-on（一次性 $10 配置费），Free 档只能用 xxx.supabase.co 二级域名。

5. 泄露密码检测（Leaked Password Protection）、Session Controls、SIEM 日志流、PITR 时间点恢复、SOC2/ISO 27001 合规报告、HIPAA：Pro / Team 档才开放。

⚠️ 最容易被忽略的隐性限制

• 免费项目 7 天无访问自动暂停（前面说过，这是头号坑）；

• 数据库只 500 MB，是 Postgres 数据 + 索引 + 日志总空间，做带图片 URL 的内容站够用，做多媒体/向量检索很容易爆；

• 文件存储只有 1 GB，单文件上传上限 50 MB；

• Realtime 并发连接 200 个，消息吞吐 100 条/秒——做小聊天室够用，做直播弹幕肯定顶不住；

• Edge Functions 每月 50 万次调用，单次执行有 CPU 时间上限；

• 日志只保留 7 天（免费和 Pro 都是，Team 档 28 天），出事后翻历史日志翻不到；

• 自动备份：Free 档不支持自动备份，Pro 才给 7 天每日备份；

• API 请求本身不限量，但只要碰到数据库/存储/流量/MAU 任一上限，或者项目被暂停，服务就不可用。

三、免费版 vs 付费版一张表看懂

四、Supabase Auth 适合做什么？不适合做什么？

✅ 适合

• 独立开发者、开源项目、MVP 验证阶段：50,000 MAU 足够跑一个中小规模 ToC 产品；

• 海外市场（英文、东南亚、欧美）ToC 应用：社交登录全开就是勾几个复选框的事；

• 需要精细数据权限的 SaaS：RLS + Postgres 角色是它的核心壁垒，可以少写大量后端权限代码；

• 小团队内部工具：Magic Link + TOTP MFA 就能撑起基本安全要求，不用再单独搭身份服务；

• 想要「数据库 + 认证 + 存储 + 边缘函数 + 实时订阅」一体化的全栈原型。

❌ 不适合

• 国内 ToC 必须要微信登录的产品：官方不原生支持，自己接 Custom OAuth 工作量不小，不如直接上 Authing / 阿里云 IDaaS；

• 手机号短信验证码做主力登录方式的产品：短信费完全自付，没有任何送额，短信到达率取决于你选的运营商；

• 对可用性有要求的正式生产环境：免费档 7 天闲置会停，$25/月 Pro 才真正不暂停；

• B2B 企业 SaaS 需要接客户 SSO：SAML 2.0 要 Team 档，$599/月起；

• 有合规要求（等保、SOC2、HIPAA）的项目：Team 档起步。

五、7 步上手（活动直达用）

1. 注册 Supabase 账号（GitHub 一键登录即可，不需要绑信用卡）；

2. 新建 Organization → 新建 Project，选离目标用户最近的 Region（海外选美东/美西/新加坡，国内访问一般选新加坡或东京），设一个强数据库密码；

3. 等 1～2 分钟初始化完成，进左侧菜单 Authentication → Providers，开启需要的登录方式（Email 默认开，Google/GitHub/Apple 等按需勾）；

4. 在 URL Configuration 里填 Site URL（你应用的前端地址）和 Additional Redirect URLs（本地开发、子应用回调都加进去）；

5. 前端项目装 SDK（@supabase/supabase-js 或框架版 @supabase/auth-helpers-nextjs / @supabase/auth-helpers-react 等），复制 Project URL 和 anon public key 到环境变量；

6. 登录页用 supabase.auth.signInWithPassword() / signInWithOAuth() / signInWithOtp()（Magic Link）调用，回调页处理 session；

7. 数据库表建好后第一时间启用 RLS（ALTER TABLE xxx ENABLE ROW LEVEL SECURITY），再写 Policy 限制 auth.uid() = user_id——不开 RLS 的表默认所有匿名请求都能读写，这是新手最大的安全事故来源。

六、几个必须知道的实战坑

• 闲置暂停问题怎么解决：可以用 cron-job.org、UptimeRobot、GitHub Actions 定时任务之类，每天 ping 一次你的 Supabase 项目 REST 端点，保持活跃。但官方明确不鼓励这种做法，本质还是建议上 Pro。

• anon key 可以公开，service_role key 绝对不能出现在前端：service_role 会绕过所有 RLS，泄露等于直接把数据库交出去。

• 默认新建表不开 RLS 是最大安全雷：Supabase 近期版本已经在控制台里强制提醒，但 SQL 编辑器里直接 CREATE TABLE 还是会默认不开，务必第一时间 ENABLE ROW LEVEL SECURITY 并写至少一条 Policy。

• 短信 OTP 想上生产，记得配置 CAPTCHA：否则很容易被刷爆短信费——这是 Supabase 文档专门强调的。

• RLS 策略只对通过 PostgREST API 发起的请求生效：直接用数据库连接（DATABASE_URL）走 Postgres 端口的请求不走 RLS，服务端脚本用 service_role 时要自己做权限校验。

参考来源：Supabase 官方定价页 supabase.com/pricing（最后更新 2026 年 1 月）、Supabase Auth 官方文档（Phone Auth / MFA / SSO / RLS 章节）、Realtime Limits 官方文档、第三方独立开发者实测（2026 年 5–10 月）。文中价格与规则以官方页面为准，核实时点：2026 年 10 月。

🔍 本期互动

1. 你用 Supabase 做过什么项目？踩过「7 天自动暂停」或「没开 RLS 数据泄露」的坑吗？

2. 选身份认证方案，你更看重「RLS 深度绑定数据库」还是「纯粹的身份服务（Auth0/Clerk/Authing）」？

3. 做国内产品微信登录是刚需，你是自己写 Custom OAuth 还是直接选国内 IDaaS？