⚡ Supabase 面试备考指南

先拿到全貌,再逐层加深——读完这一节,你已经能回答面试的第一个问题。

Supabase 是一个开源的后端即服务平台(BaaS,Backend as a Service)。「后端即服务」的意思是:你只写前端,后端那一整套——数据库、用户登录、文件存储、实时推送、服务端函数——它打包提供,不用你自己搭服务器。它最常被介绍为「开源的 Firebase 替代品」,但底座完全不同:Firebase 用私有 NoSQL,Supabase 给你一个完整的、不加抽象层的 PostgreSQL 数据库。

速览版的三个核心记忆点:

• 🐘
  一切围着 Postgres 转。认证的用户表、存储的文件元数据、实时推送的数据源,全部就是 Postgres 里的表。这个「数据库中心」设计是理解全部架构的钥匙。
• 🔓
  你拿到的是完整数据库权限。没有抽象层——SQL、索引、触发器、扩展随便用,也能随时 pg_dump 整库带走(官方产品原则里明确写了「可移植性」)。
• 📖
  整个平台开源(Apache 2.0),可自托管。每个组件都是独立开源项目,官方云只是「帮你托管好的那一套」。

面试里「为什么会有 Supabase」比「Supabase 是什么」更能体现理解深度。

先看它出现之前的世界。2010 年代,Google 的 Firebase 把「不用写后端」变成了现实:前端直接读写云端数据、内置登录、实时同步,创业团队爱不释手。但它有两个越用越疼的痛点:

• 🔒
  闭源 + 锁定。Firestore 是 Google 私有的 NoSQL 数据库,没有自托管路径,数据和查询逻辑都长在 Google 的地基上,想搬家非常难。
• 🧩
  NoSQL 的表达力天花板。文档型数据库做不了真正的 JOIN、复杂聚合、事务约束。业务一复杂,开发者就开始怀念 SQL。

Supabase 的回答很直接:用世界上最流行的开源关系型数据库做底座,把 Firebase 的开发体验搬到它上面。官方架构文档里有一句关键表述——他们认为没有其他数据库能在保持可扩展性的同时,提供与 Firebase 竞争所需的功能,所以选择了 Postgres。这句可以在面试里直接引用。

到 2026 年,它的增长又叠加了一层新动力:AI 编程。据投资方 Craft Ventures 的分析文章,AI 编程工具和「vibe coding」应用大量默认选择 Supabase 当后端(生成的代码就是标准 SQL + 标准 API,对 AI 友好),推动开发者数量在一年内从约 100 万涨到 450 万以上。官方也在 2026 年 6 月上线了 ChatGPT 集成,可以用对话方式管理数据库。这些属于「官方与投资方口径」,引用时注意措辞。

面试最高频考点之一:「讲讲 Supabase 的架构」。这一节的目标是让你能白纸画出这张图。

Supabase 不是一个大单体,而是一组围绕 Postgres 的独立开源服务。每个服务只做一件事,全部通过 API 网关对外。理解顺序:先记住「下面是唯一的数据库,上面是一排无状态服务,最前面是网关」,再逐个认识每个服务。

🧩 组件清单(面试背诵版)

「建一张表,立刻得到一套 API」是 Supabase 开发体验的核心魔法,魔法师是 PostgREST。

// 官方标准用法(supabase-js)
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(SUPABASE_URL, PUBLISHABLE_KEY)

// 查询:price >= 100 的商品,按创建时间倒序
const { data, error } = await supabase
  .from('products')
  .select('id, name, price')
  .gte('price', 100)
  .order('created_at', { ascending: false })

// 插入
await supabase.from('products').insert({ name: 'Widget', price: 42 })

补充一点:同一套机制还有 GraphQL 版本——pg_graphql 扩展把 schema 映射成 GraphQL 接口;2026 年 7 月还推出了 @supabase-labs/tanstack-db(alpha),把 TanStack DB 集合通过 PostgREST + Realtime 与数据表同步——如果面试聊到你的 TanStack Start 项目,这是个很新的谈资。

认证回答「你是谁」,API Key 回答「什么应用在访问」——两套体系,面试常让你分清。

🧑‍💻 Supabase Auth 能做什么

认证服务由 GoTrue(Go)承担。官方文档列出的登录方式:邮箱密码、magic link(邮件里点链接免密登录)、一次性密码 OTP、社交登录(Apple、Google、GitHub、Discord、Facebook、LinkedIn、Microsoft Azure 等 18+ 家)、手机短信(Twilio、MessageBird、Vonage)、企业单点登录 SSO,以及任何 OAuth2/OIDC 兼容的身份源。2026 年 6 月起还支持 WebAuthn:Face ID、Touch ID、Windows Hello、硬件安全钥匙,走「无密码、防钓鱼」路线。

用户数据存在 Postgres 的专用 auth schema 里(核心是 auth.users 表),官方文档明确说可以用触发器和外键把它关联到你自己的表——最经典的模式就是「auth.users 插入新行时,触发器自动在 public.profiles 建一条资料」。

🎫 JWT:整个安全模型的通行证

🗝️ API Key:新旧两套体系

API Key 与用户身份无关,它标识「哪个应用在访问这个项目」。目前两套并存(官方文档口径):

如果 Supabase 面试只考一个主题,一定是 RLS。这一节讲透:是什么、四种策略怎么写、性能怎么调、有哪些坑。

✍️ 四种策略写法(官方示例)

-- 第一步:开启 RLS(暴露在 API 里的表必须开!)
alter table profiles enable row level security;

-- SELECT:能"看"哪些行 → USING 子句
create policy "只能看自己的资料" on profiles
for select using ( (select auth.uid()) = user_id );

-- INSERT:能"写入"什么样的新行 → WITH CHECK 子句
create policy "只能以自己的身份建资料" on profiles
for insert to authenticated
with check ( (select auth.uid()) = user_id );

-- UPDATE:改之前要能"看到"旧行(USING),改出来的新行要合规(WITH CHECK)
create policy "只能改自己的资料" on profiles
for update to authenticated
using  ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

-- DELETE:能"删"哪些行 → USING 子句
create policy "只能删自己的资料" on profiles
for delete to authenticated
using ( (select auth.uid()) = user_id );

⚡ 性能优化六招(官方基准数据)

RLS 策略会在每一行上求值,写得不好就是性能杀手。官方 RLS 文档给出了六个优化手段和实测提升幅度:

🕳️ 还要知道的三件事

• 👁️
  视图默认不走基表的 RLS。Postgres 15+ 可在建视图时加 with (security_invoker = true),让视图遵守底层表的策略(官方文档给出的方案)。
• 🔓
  绕过 RLS 的正规途径:后端用 service_role/secret key,或给角色加 bypassrls 属性——仅限可信服务端环境。
• 🧪
  RLS Tester:2026 年 6 月 Dashboard 新增的测试器,可以「扮演某个用户」跑查询、看命中了哪条策略——复习时实测一遍,面试可以当经验讲。

「Realtime 怎么工作、能扛多大规模」是系统设计向面试题的常客,官方数字要背两个。

Realtime 是一台 Elixir/Phoenix 写的 WebSocket 服务器,提供三种能力,按「谁产生消息」区分最清楚:

🔍 Postgres Changes 的工作原理(深挖点)

订阅端写法(官方参数):可按 schema / 表 / 行三级过滤,filter 支持 eq、neq、lt、gt、in、like 等 PostgREST 风格操作符,还能用 select 参数只接收部分列以减小载荷:

supabase.channel('room1')
  .on('postgres_changes',
      { event: 'UPDATE', schema: 'public', table: 'orders',
        filter: 'status=eq.paid' },
      (payload) => console.log(payload))
  .subscribe()

配额方面(官方定价页):免费档 200 个并发连接、200 万条消息/月;Pro 500 个并发(超额 $10/千连接)、500 万条消息/月。

Storage 本身不难,考点在「权限怎么做」——答案还是 RLS。

Storage 是 S3 兼容的对象存储:文件本体存在对象存储里,元数据(路径、大小、所有者)存在 Postgres 的 storage.objects 表里。这个设计的直接后果是:文件权限就是往 storage.objects 上写 RLS 策略——和管表数据完全同一套思路,不用再学一门「安全规则语言」(这正是它与 Firebase Security Rules 的对照点)。

• 📤
  断点续传:基于 TUS 协议的 resumable uploads,大文件断网可续。
• 🌍
  CDN:官方称全球 285 个城市节点加速分发;支持图片即时缩放/压缩/转换(on-the-fly transformation)。
• 🪣
  三种 bucket 类型(官方文档):Files(通用文件)、Analytics(Apache Iceberg 表格式,做数据湖/日志)、Vectors(向量嵌入,配合 AI 场景)。后两种是较新的能力,面试提到会显得信息很新。

「自动 API 覆盖不了的服务端逻辑放哪?」——放这里。限制数字要背准,网上旧资料错得很多。

Edge Functions 是跑在 Deno 运行时(TypeScript 优先)上的服务端函数,部署后在离用户最近的边缘节点执行。官方列举的典型场景:Webhook 接收器(Stripe、GitHub)、AI 推理 / LLM 编排、按需生成 OG 图、发事务邮件、聊天机器人。本地用 CLI 开发(supabase functions serve),再部署到全球。

设计约束(官方指引):存在冷启动,函数应短生命周期、幂等;长任务转后台 worker;在函数里连数据库要用连接池或 serverless 驱动(呼应第 10 节);密钥放项目 secrets,以环境变量读取。

这是被公开面经点名的考点(session vs transaction mode)。先懂「为什么需要池」,数字就好记了。

面 AI 相关岗位时,这一节能把 Supabase 和你的主战场接上。

官方 AI 文档的口号概括了一切:「最好的向量数据库,是你已经在用的数据库」。做法:启用 pgvector 扩展,表里加一个向量列存 embedding,相似度搜索就是一条 SQL——业务数据和向量放在同一个库里,不用再为 RAG 单独引一个 Pinecone/Weaviate,也不用跨库同步。

• 🔎
  三种搜索(官方文档):语义搜索(按含义)、关键词搜索(全文检索)、混合搜索(两者结合)。
• 🧩
  生态集成:OpenAI、Hugging Face、LangChain、LlamaIndex、Amazon Bedrock;Edge Functions 里还能跑开源模型生成 embedding。
• 📦
  官方列举的迁移案例:Firecrawl 从 Pinecone 迁到 pgvector,Berri AI 从自托管 RDS 迁入——面试聊「为什么不用专用向量库」时可引用(注意标注是官方案例页口径)。

「你为什么选 Supabase 而不是 X」是判断你有没有工程判断力的题——答案要讲权衡,不是站队。

对比依据:Bytebase 2026-04 对比文(每年更新)+ 官方文档;「离线成熟度」「定价可预测性」为多家评测的共同结论,属社区共识而非官方口径。

面试聊「你踩过/知道哪些坑」时,分清「官方明示的限制」和「社区反馈的痛点」会显得非常专业。

📕 官方文档明示的

• 1️⃣
  忘开 RLS = 数据裸奔。暴露 schema 里的表不开 RLS,任何人拿 publishable key 就能读写。官方文档甚至给了「事件触发器自动为新表开 RLS」的方案。上线前必查。
• 2️⃣
  用 user_metadata 做授权。它是用户可改的——把「是否管理员」放这里等于让用户自己发管理员证。授权数据只能放 app_metadata。
• 3️⃣
  RLS 策略不优化。不加索引、不用 (select auth.uid()) 包裹,大表查询可以慢出两个数量级(官方基准见第 6 节)。
• 4️⃣
  Transaction 模式下用 prepared statements 报错。ORM/驱动默认常开,连 6543 端口要显式关闭。
• 5️⃣
  Postgres Changes 当广播用。数千订阅者共享一个变更流时吞吐骤降(单线程 + 逐订阅者鉴权),官方建议超 ~3,000 并发订阅改 Broadcast 架构。
• 6️⃣
  Edge Functions 干重活。CPU 时间只有 2 秒、内存 256MB——它是胶水层,不是计算平台。
• 7️⃣
  secret key 进了前端或仓库。绕过 RLS 的钥匙,官方要求当密码级机密管理,泄露立即轮换。

💬 社区反馈的(标注来源性质)

• 💰
  规模大了成本上升:出口带宽、存储、连接数超额费用叠加(多家评测与社区讨论共同提及;不过同类评测也认为其定价可预测性优于按操作计费的 Firebase)。
• 🌏
  中国大陆无节点:访问延迟高、稳定性受网络环境影响,面向大陆用户的产品需慎重(中文社区普遍反馈,如 CSDN、SegmentFault 技术文)。
• 🔧
  自托管运维不轻:十余个服务组成的栈,默认 docker-compose 单节点无高可用,严肃生产需要额外架构(中文社区 PIGSTY 等自托管实践文章反馈)。
• 📱
  移动离线短板:相比 Firebase 成熟的离线同步,Supabase 还在补课(2026 年多家对比评测共同结论)。

题目综合自 Adaface 题库(2024-09)、techinterview.org 考点清单与官方文档;先自己答,再点开对要点。答案均可回溯到前文章节。

🧱 A · 基础与架构

🛡️ B · RLS(必考区)

🔐 C · Auth 与 Key

📡 D · Realtime

🔀 E · 连接与性能

🧰 F · 其他服务与场景判断

你不是零基础——自己的网站就跑在 Supabase 上(建过表、写过 RLS、用过 REST PATCH)。所以这份计划的重心不是「学会用」,而是「讲得出原理」:每天 2–3 小时,动手 + 口述并重。

1. Day 1 · 全景与架构读本文 §1–3 + 官方 Architecture 文档。动手:白纸默画架构图(网关→五服务→Postgres,标语言),对照本文检查。口述练习:3 分钟讲「Supabase 是什么、架构长什么样」,录音回听。
2. Day 2 · PostgREST 与 SQL 补强读官方 REST API 文档。动手:用 curl 直接调你自己网站项目的 REST 端点(带 apikey header),观察响应;对 resources 表跑一次 EXPLAIN ANALYZE,看懂执行计划。自问:「schema 即接口」的安全前提是什么?
3. Day 3 · RLS 专项(重心日)精读本文 §6 + 官方 RLS 文档。动手:在自己项目找一张表(比如你做过的 reading_status)把四种 policy 写全;用 Dashboard 的 RLS Tester 扮演另一个用户验证;给策略列加索引前后各测一次耗时。口述:USING vs WITH CHECK、六个优化招。
4. Day 4 · Auth 与 JWT读本文 §5 + 官方 JWT 文档。动手:把自己项目的 access token 粘进 jwt.io,逐个 claim 对照含义;找到项目里 anon/service key 的使用处,想清楚每处为什么用那把 key。自问:app_metadata 为什么能进授权而 user_metadata 不能?
5. Day 5 · Realtime + Storage + Edge Functions读本文 §7–9。动手:本地写 20 行代码订阅一张表的 postgres_changes 并触发一次 UPDATE 看 payload;部署一个 hello-world Edge Function。背数字:单线程/3000 订阅线/2 秒 CPU/256MB。
6. Day 6 · 连接池 + pgvector + 系统设计读本文 §10–11。动手:找到自己项目连接串用的端口,判断走的哪种模式。口述:完整答一遍第 20 题(万人订阅设计)和第 28 题(何时不用 Supabase),计时 5 分钟。
7. Day 7 · 全量自测 + 项目故事(重心日)§14 的 28 题全部盲答,答不出的回读对应章节。压轴任务:把你自己的网站整理成 2 分钟项目故事——「TanStack Start + Supabase 全栈站:RLS 保护的私有阅读状态表、REST PATCH 做内容运维、静态资源同步管线」——真实项目经验是面试里最硬的通货。

按学习顺序排列,全部为调研中实际核对过的来源。

• 🏛️
  官方架构文档(必读第一篇):supabase.com/docs/guides/getting-started/architecture
• 🛡️
  RLS 官方指南(必读,含性能优化基准):…/database/postgres/row-level-security
• 🎫
  JWT 与 Auth:…/auth/jwts · …/auth · …/api/api-keys
• 📡
  Postgres Changes(含扩展性限制):…/realtime/postgres-changes
• 🔀
  数据库连接方式:…/database/connecting-to-postgres
• ⚙️
  Edge Functions 限制数字:…/functions/limits
• 🤖
  AI 与向量:…/guides/ai
• 📰
  Changelog(跟进新特性,面试谈资):supabase.com/changelog
• ⚖️
  对比文:Bytebase《Supabase vs Firebase》(每年更新):bytebase.com/blog/supabase-vs-firebase
• 🎯
  题库补充:Adaface 80 题:adaface.com/blog/supabase-interview-questions · techinterview.org 考点:techinterview.org/companies/supabase