选择 BaaS：Firebase 对比 Supabase

五项服务封装在一个 SDK 里

Firebase 和 Supabase 都将相同的五项能力封装在一个 SDK 和一套凭据之后：

• 认证（Authentication）——邮箱/密码、Google / Apple / GitHub OAuth、魔法链接、手机 OTP。SDK 让你一行代码就能判断用户是否已登录。
• 数据库（Database）——应用数据的存储位置。Firebase = Firestore（NoSQL 文档）；Supabase = Postgres（关系型行）。
• 存储（Storage）——文件上传。头像、附件、用户生成的图片。两者都提供桶状 API；Firebase 底层是 Google Cloud Storage，Supabase 底层是 S3。
• 实时（Realtime）——数据变更时向客户端推送更新。就是那个"计数器在所有地方同步更新"的演示效果。Firestore 默认对所有读取开启；Supabase 可按表选择开启。
• 函数（Functions）——由事件或 HTTP 触发的服务端代码。Firebase Cloud Functions（Node）和 Supabase Edge Functions（Deno）。

你在托管费之外真正为之付费的，是所有五项都绑定到同一套用户身份这件事。已登录用户的照片上传（存储）之所以被允许，是因为数据库里有一条行级别的规则，引用了他们的认证令牌（认证）。自己搭建意味着要手动编写这套连接逻辑；用 BaaS，SDK 直接把接好线的版本交给你。

Firestore 为固定形态优化；Postgres 为变化优化

Firebase 和 Supabase 之间最重要的区别就是数据库。选错了，之后每新增一个功能都是在跟 schema 较劲。

Firestore（Firebase）——NoSQL 文档。数据存储在由文档组成的集合中，文档就是 JSON。没有 JOIN，没有外键，没有迁移——schema 只存在于你的代码里。查询很简单（"这个集合中字段 X 等于 Y 的文档"），在大规模场景下非常快，但任何涉及多表的操作（类似 SQL JOIN）要么需要把数据反范式化写进文档，要么在客户端拉取多个集合后自行处理。实时同步默认对所有读取开启，这是 Firebase 的招牌特性。

Postgres（Supabase）——关系型行。数据存储在带有类型列和预定义 schema 的表中。JOIN 存在，外键存在，SQL 是查询语言；Supabase SDK 在上面封装了一个查询构建器，但你也可以在需要时直接写原生 SQL。schema 变更通过迁移文件管理——存放在仓库中的文本文件，负责将数据库从一个形态演变到另一个形态。实时功能需按表选择开启。

有一条经验法则出奇地管用：如果你的应用感觉像"一个有评论和点赞的帖子流"，Firestore 就够了。如果感觉像"用户、项目、任务、分配，加上跨所有数据的报表"，你会跟 Firestore 不断较劲，Postgres 才是赢家。大多数真实的消费者应用，即便最初看起来像前者，经过一年的迭代都会演变成后者的形态。这种倾向是 2026 年团队将 Supabase 作为默认选择的主要原因。

两份 SDK 入门教程没有告诉你的事

迁出成本这一行比大多数人预想的更重要。成功的应用会产生当初选择 BaaS 时没有预料到的新需求。用 Supabase，"我需要迁出"意味着"pg_dump，然后让应用连接另一个 Postgres"。用 Firebase，则是一个以月为单位计算的项目。

两者都是免费到某个临界点；理解那个悬崖在哪里

两者都有慷慨的免费层，足以支撑个人项目和小型 SaaS。两者都会在超出配额时切换到付费计划，然后在基础计划之上按用量计费。

Firebase（Spark → Blaze）。Spark 计划免费，包含 1 GiB Firestore、1 GB 存储、10 GB 传输、每日 5 万次 Firestore 读取、2 万次写入。超出后切换到 Blaze（按量付费）：每 10 万次 Firestore 读取 $0.06，每 10 万次写入 $0.18，存储 $0.026/GB 每月。那些臭名昭著的"Firebase 账单爆炸"故事，通常是在 Blaze 计划下配置有问题的客户端陷入无限读取循环——计费器不会停。在上线前务必在 GCP 项目中设置每日预算告警。

Supabase 免费层 → Pro。免费层包含 500 MB Postgres 数据库、1 GB 存储、每月 5 万活跃用户、5 GB 出口流量。Pro 是固定 $25/月加用量——8 GB 数据库、100 GB 存储、10 万 MAU、250 GB 出口流量。Pro 以上是企业定价。定价更偏向"订阅制"而非 Firebase 的纯按量计费；账单不会意外暴涨，但计划升级需要主动操作。

对于约 1 万月活用户、数据量适中的真实应用：两者在入门付费计划下都在 $25–60/月左右。曲线在此之上开始分叉——Firebase 随流量平滑扩展；Supabase 在计划边界有阶梯式变化（Pro → Team → Enterprise）。

用 Google 登录，读取一个文档

一次性配置：打开 Firebase 控制台 → 添加项目。进入项目后：构建 → Authentication → 启用 Google。构建 → Firestore Database → 在测试模式下创建。从项目设置中复制 Web 配置对象（包含一个 apiKey 和若干 ID）。

在你的项目中：

npm i firebase

创建 src/firebase.js：

import { initializeApp } from "firebase/app";
import { getAuth, GoogleAuthProvider, signInWithPopup } from "firebase/auth";
import { getFirestore, doc, getDoc } from "firebase/firestore";

const app = initializeApp({
  apiKey: "AIza...",
  authDomain: "your-project.firebaseapp.com",
  projectId: "your-project",
  // ...rest of config
});

export const auth = getAuth(app);
export const db = getFirestore(app);
export const signInWithGoogle = () =>
  signInWithPopup(auth, new GoogleAuthProvider());

export async function getProfile(uid) {
  const snap = await getDoc(doc(db, "profiles", uid));
  return snap.exists() ? snap.data() : null;
}

在你的组件中：

import { useEffect, useState } from "react";
import { auth, signInWithGoogle, getProfile } from "./firebase";
import { onAuthStateChanged } from "firebase/auth";

export default function App() {
  const [user, setUser] = useState(null);
  const [profile, setProfile] = useState(null);

  useEffect(() => onAuthStateChanged(auth, async (u) => {
    setUser(u);
    if (u) setProfile(await getProfile(u.uid));
  }), []);

  if (!user) return <button onClick={signInWithGoogle}>Sign in</button>;
  return <div>Hi {user.displayName} — profile: {JSON.stringify(profile)}</div>;
}

运行它。点击登录按钮，弹出 Google OAuth 授权窗口；授权后，页面会用你的名字向你打招呼。在 Firestore 控制台中向 profiles/<your-uid> 写入一个文档；刷新页面，数据就出现了。这就是 30 行代码里的整个捆绑包。

同样的事，换成 Postgres 的方式

一次性配置：打开 Supabase 控制台 → 新建项目。等待约 90 秒让 Postgres 实例启动。在 Authentication → Providers 中启用 Google（粘贴来自 GCP 的 Google OAuth 客户端 ID 和密钥）。在 SQL Editor 中创建一个 profiles 表：

create table profiles (
  id uuid primary key references auth.users on delete cascade,
  display_name text,
  created_at timestamptz default now()
);
alter table profiles enable row level security;
create policy "own profile" on profiles for select using (auth.uid() = id);

从项目设置中复制 SUPABASE_URL 和 SUPABASE_ANON_KEY。

在你的项目中：

npm i @supabase/supabase-js

创建 src/supabase.js：

import { createClient } from "@supabase/supabase-js";

export const supabase = createClient(
  "https://<PROJECT>.supabase.co",
  "eyJ...ANON_KEY"
);

export const signInWithGoogle = () =>
  supabase.auth.signInWithOAuth({ provider: "google" });

export async function getProfile(userId) {
  const { data, error } = await supabase
    .from("profiles")
    .select("*")
    .eq("id", userId)
    .single();
  return error ? null : data;
}

在你的组件中：

import { useEffect, useState } from "react";
import { supabase, signInWithGoogle, getProfile } from "./supabase";

export default function App() {
  const [user, setUser] = useState(null);
  const [profile, setProfile] = useState(null);

  useEffect(() => {
    supabase.auth.getSession().then(({ data }) => setUser(data.session?.user ?? null));
    const { data: sub } = supabase.auth.onAuthStateChange(async (_e, session) => {
      const u = session?.user ?? null;
      setUser(u);
      if (u) setProfile(await getProfile(u.id));
    });
    return () => sub.subscription.unsubscribe();
  }, []);

  if (!user) return <button onClick={signInWithGoogle}>Sign in</button>;
  return <div>Hi {user.email} — profile: {JSON.stringify(profile)}</div>;
}

运行它。流程完全相同：点击登录，Google OAuth 弹窗，页面向你打招呼。将你的 auth.users.id 作为主键插入一行到 profiles 表中；刷新，数据出现。结构与 Firebase 几乎相同，底层数据库换成了 Postgres。

覆盖大多数情况的三个简短答案

• 现在就要选，还不知道应用会变成什么样：选 Supabase。迁出成本更低，数据模型能处理更多形态，SQL 技能也是通用的。
• 你的应用本质上是一个实时同步产品（聊天、协作编辑器、实时游戏状态、多设备在线状态）：选 Firebase。Firestore 的实时无处不在模型在这个场景下确实优于 Supabase 的按需实时。
• 你的应用需要对数据做 JOIN、报表或分析：选 Supabase。跟 Firestore 较劲解决这个问题是好几个月的工程量；Postgres 用一行 SQL 就能搞定。

"两者都用"是罕见但合理的选择——用 Firebase Auth + Firestore 处理应用的实时侧，用 Supabase Postgres 处理关系型数据侧。大多数团队发现这样的复杂度得不偿失，最终还是选择一个。