1. 项目概述为什么一个“Firebase平替”能狂揽10万StarSupabase不是个新名字但“Google Firebase开源平替”这个标签确实精准戳中了全球开发者最敏感的神经。我从2021年Supabase刚破万Star时就开始跟进到今天它在GitHub上稳定维持在104,000 Star注意标题里写的99,000已是旧数据背后不是营销噱头而是一场静默却彻底的基础设施信任迁移。它解决的从来不是“能不能用”的问题而是“敢不敢把核心数据和用户身份交出去”的根本焦虑。核心关键词就三个Postgres、开源、Firebase体验。这三者组合起来意味着什么意味着你不再需要把用户邮箱密码、实时聊天记录、AI向量库这些高价值资产托管在某个商业云服务的黑盒数据库里意味着你随时可以导出全量数据、审计每一行SQL、甚至把整个后端连同数据库一起打包迁移到自己的私有云或混合云环境更意味着——当某天你突然收到一封“您的项目已超出免费额度请在72小时内升级为付费计划否则API将限频”的邮件时你不用连夜改架构只需登录服务器敲几行命令把连接字符串指向自己刚部署好的Supabase实例即可。这不是理论上的自由是实打实的工程自由。我亲眼见过三个真实场景一家做教育SaaS的创业公司在Firebase账单单月突破$8,000后用3天时间完成Supabase迁移月成本降至$230仅含云厂商基础资源费一个独立开发者用SupabaseNext.js搭起的AI写作助手上线半年用户破5万全程没碰过一行后端代码所有权限、存储、实时协作都由Supabase自动管理还有一家医疗IoT设备厂商因合规要求必须数据不出境直接在本地机房部署Supabase集群用Postgres原生加密Row Level SecurityRLS策略比自研RBAC系统快了整整两个月交付。所以当你看到“开源平替”这个词别只想到省钱。它真正值钱的地方在于把“后端基建”从一项需要持续投入人力维护的成本中心变成了一个开箱即用、可审计、可迁移、可预测的能力模块。而Supabase之所以能成为这个模块的代名词恰恰因为它没走“重写Firebase”的捷径而是选择了一条更笨、也更扎实的路把Postgres这个服役超30年的工业级数据库变成现代应用开发的“操作系统内核”再用一套精心编排的开源组件给它装上实时通信、身份认证、文件存储、函数计算这些“驱动程序”。这条路不性感但足够稳——就像你不会质疑Linux内核的可靠性Supabase的稳定性本质上就是Postgres的稳定性。1.1 核心需求解析开发者到底在逃离什么要理解Supabase为何爆发得先看清Firebase的“舒适区”里藏着哪些隐性代价。我带过十几支用Firebase的团队踩过的坑总结下来无非三大类第一类是数据主权模糊。Firebase Realtime Database和Firestore的底层存储结构对开发者是黑盒。你调用collection(users).add({...})数据存哪了索引怎么建的查询慢是因为数据量大还是因为没建对复合索引这些问题的答案官方文档往往语焉不详你只能靠试错。更关键的是当业务增长到千万级用户想做复杂分析比如用户行为漏斗、多维留存你得把数据导出到BigQuery再清洗中间多一层ETL延迟和成本都不可控。而Supabase直接给你一个标准Postgres实例——你可以用pg_dump一键备份用psql执行任意SQL分析甚至用Metabase连上去做BI看板数据完全在你掌控中。第二类是技术栈绑架。Firebase SDK深度绑定JavaScript生态虽然现在有Dart、Swift、Kotlin支持但功能完整度和更新速度远不如JS版。我曾帮一个Unity游戏团队接入Firebase AnalyticsiOS端打点数据始终不进后台排查三天才发现是Unity iOS插件里一个未公开的线程安全bug官方Issue里上百人排队等修复。而Supabase的客户端库是严格按协议分层的supabase-js只是PostgREST REST API GoTrue Auth API Realtime WebSocket的封装你完全可以用curl、Postman甚至Excel的WEBSERVICE函数直接调用它的API。去年我们给一个老系统做数据同步对方只有VB6我就手写了一个VB6的HTTP客户端直连Supabase的PostgREST端点两周搞定零依赖。第三类是扩展性幻觉。Firebase宣传“自动扩缩容”但实际扩容逻辑是黑盒。我遇到过最典型的案例一个直播弹幕系统用Firestore高峰期每秒写入2万条消息结果发现90%的请求超时。查监控发现是单个集合的写入吞吐达到瓶颈而Firebase不支持手动分片sharding唯一解法是拆成多个集合再加路由逻辑——这已经不是“BaaS”而是“半PaaS”了。Supabase则完全不同Postgres的扩展性是经过银行、交易所验证的。你要扛更高并发加读副本要更快写入调优WAL日志、调整shared_buffers要横向扩展用Citus插件做分布式表。所有参数、所有路径都在你的掌控之中。所以“平替”二字本质是开发者对确定性的渴求。Firebase像一辆豪华自动驾驶汽车你坐进去很爽但一旦它偏离路线你既不知道原因也无法接管方向盘。Supabase则像一辆性能车方向盘、油门、刹车全在你手里仪表盘上每个转速、水温、胎压都实时可见。选哪个取决于你当前阶段最怕什么怕麻烦就选Firebase怕失控就选Supabase。1.2 技术定位再澄清它真能1:1替代Firebase吗这里必须划清一条关键界限Supabase不是Firebase的克隆版它是用开源积木重新搭建的“同功能域解决方案”。很多新手一上来就问“Supabase有没有Firestore的嵌套文档查询”“Realtime能不能监听子集合变化”——这种问题本身就暴露了思维惯性。Supabase的设计哲学是“用成熟工具解决成熟问题不重复造轮子”。举个最典型的对比Firebase Authentication vs Supabase Auth。Firebase Auth提供邮箱/密码、Google、Apple等十多种登录方式背后是Google的IDP身份提供商服务。Supabase AuthGoTrue同样支持这些方式但它不是调用Google的API而是自己实现了OAuth2.0流程并把用户信息存进Postgres的auth.users表。这意味着什么意味着你可以直接在数据库里写SQL批量禁用某批用户、修改用户角色、甚至关联用户与业务表比如profiles表。而Firebase Auth的用户数据你只能通过Admin SDK读取无法直接JOIN业务表做复杂查询。再看实时能力Firebase Realtime Database的“监听路径”机制本质是基于内存树的事件广播。Supabase Realtime则是监听Postgres的WALWrite-Ahead Log日志把INSERT/UPDATE/DELETE操作解析成JSON通过WebSocket推送给客户端。这带来两个根本差异一是Supabase的实时数据永远与数据库状态强一致不存在缓存不一致问题二是它天然支持复杂条件过滤——比如你只想监听“status active AND created_at NOW() - INTERVAL 1 day”的订单变更这在Firestore里要靠Security Rules硬编码而在Supabase里前端一句channel.on(postgres_changes, { event: INSERT, schema: public, table: orders, filter: statuseq.active }, ...)就能搞定。最后是存储Firebase Storage是对象存储类似S3。Supabase Storage也是基于S3兼容接口但它把所有文件元数据如上传者ID、访问权限都存在Postgres里并通过RLS策略控制访问。这就让“用户只能删自己上传的文件”这种需求从一段易出错的客户端逻辑变成一条数据库策略CREATE POLICY Users can delete their own files ON storage.objects FOR DELETE USING (auth.uid() owner_id);。策略生效后哪怕黑客绕过前端直接调用API数据库也会拒绝非法删除。所以Supabase的“替代”不是像素级复刻而是用更底层、更可控、更符合数据库范式的方案实现同等业务目标。它不要求你放弃Firebase思维但会温柔地推着你走向更健壮的工程实践。2. 架构拆解Supabase不是单个产品而是一套精密协作的开源组件链Supabase的GitHub仓库supabase/supabase看起来像个庞然大物36,000次提交69%的TypeScript代码。但如果你把它当成一个整体去学一定会陷入迷雾。真相是Supabase本身是个“胶水平台”它把多个独立、成熟、各自治理的开源项目用一套统一的Dashboard和Client SDK粘合起来。理解这一点是掌握Supabase的第一把钥匙。下面我按数据流向逐层拆解这套组件链如何协同工作。2.1 底座Postgres——一切的源头与权威Supabase的根基是那个你可能在大学数据库课上就接触过的PostgreSQL。但别被“老古董”印象骗了——Postgres 15版本早已不是当年那个只适合OLTP的数据库。它内置了JSONB类型支持Gin索引加速JSON查询、全文检索、地理空间PostGIS、向量搜索pgvector、逻辑复制Logical Replication等企业级特性。Supabase正是把这些能力变成了开发者触手可及的功能。关键设计点在于Schema隔离。当你创建一个新Supabase项目它默认给你三个Schemapublic你的业务表放这里比如products、ordersauthGoTrue认证系统专用存用户、刷新令牌、邀请码等storage文件存储元数据存文件名、大小、上传者、权限策略等。这种隔离不是简单的文件夹划分而是数据库级别的权限墙。authSchema里的表业务代码默认无权读写必须通过GoTrue API交互storageSchema的权限则由RLS策略控制。这保证了核心系统表的安全也让你能放心在public里建表不用担心污染系统。提示很多新手一上来就在public里建users表结果发现Auth的用户数据不在里面。记住Supabase的“用户”概念是跨Schema的——auth.users存认证信息public.profiles需手动创建存业务信息两者通过auth.users.id public.profiles.id关联。这是刻意为之的解耦避免认证逻辑和业务逻辑纠缠。2.2 实时引擎Realtime Server——监听WAL日志的信使Supabase的实时能力不依赖任何第三方消息队列如Kafka、RabbitMQ而是直连Postgres的WAL日志。WAL是Postgres保证ACID的核心机制每次事务提交前都会把变更写入WAL文件。Realtime Server作为一个Elixir进程伪装成Postgres的一个“备用节点”standby node通过pg_replication协议订阅WAL流。它的工作流程极简Postgres执行INSERT INTO public.messages (...) VALUES (...);WAL日志记录该操作的物理变更如table: messages, op: INSERT, new_row: {...}Realtime Server捕获WAL记录解析成标准化JSON事件根据客户端订阅的Channel如public:messages和Filter如user_ideq.123将事件推送到匹配的WebSocket连接这个设计的威力在于零延迟、强一致、低侵入。因为WAL是事务提交的最后一步所以客户端收到实时事件时数据必然已持久化到磁盘。而且你不需要在业务代码里加任何publish()调用——只要数据进了PostgresRealtime就自动广播。我曾用它实现一个股票行情推送系统从交易所API接数据入库到前端图表刷新端到端延迟稳定在80ms以内且100%无丢包。注意Realtime默认只监听publicSchema。如果你想监听auth或storage的变化比如用户登出时清理缓存需要在Supabase Dashboard的“Authentication”设置里开启对应Schema的Realtime开关或通过API手动启用。2.3 API网关PostgREST——把SQL变成RESTful接口这是Supabase最惊艳的设计之一。你无需写一行Node.js或Python代码就能获得一个生产级的REST API。原理很简单PostgREST是一个Haskell编写的Web服务器它直接连接Postgres将HTTP请求映射为SQL查询。例如你有张public.products表包含id,name,price,category字段。那么GET /rest/v1/products→SELECT * FROM products;GET /rest/v1/products?selectname,pricecategoryeq.electronics→SELECT name, price FROM products WHERE category electronics;POST /rest/v1/products JSON body →INSERT INTO products (...) VALUES (...);所有这些都不需要定义路由、写控制器、处理参数校验。PostgREST自动根据表结构生成OpenAPI文档支持JWT鉴权通过Authorization: Bearer token并强制执行RLS策略。这意味着你前端调用fetch(/rest/v1/products?pricegte.100)如果当前用户没有权限查价格100的商品PostgREST会在SQL执行前就返回403 Forbidden连数据库都不会碰。实操心得PostgREST的查询语法非常强大但新手容易踩坑。比如?nameilike.%iphone%是模糊搜索?or(category.eq.electronics,category.eq.software)是OR条件。建议把常用查询写成View视图然后对View启用RLS这样既简化前端调用又提升查询性能。2.4 认证中枢GoTrue——JWT驱动的身份管家GoTrue是Supabase Auth的后端一个轻量级的Go语言服务。它不存储密码明文而是用bcrypt哈希后存入auth.users表。所有认证流程注册、登录、密码重置、第三方登录都遵循OAuth2.0和OpenID Connect标准。最关键的创新点是Session管理。Firebase用长生命周期的ID Token而GoTrue采用短时效1小时的Access Token 长时效30天的Refresh Token组合。Access Token用于API鉴权过期后前端用Refresh Token向GoTrue换新Token。这个设计大幅降低了Token泄露的风险——即使Access Token被截获攻击者也只有1小时窗口。更妙的是GoTrue生成的JWT里会注入role角色和email等声明claims这些声明会被PostgREST和Realtime自动提取用于RLS策略判断。比如RLS策略USING (auth.role() authenticated)就是靠JWT里的role字段生效。这实现了“一次登录处处鉴权”的无缝体验。常见误区很多人以为Supabase Auth只能做用户登录。其实GoTrue支持自定义JWT签发。你可以用Admin API为后台任务、IoT设备生成专用Token指定role: service然后在RLS里写USING (auth.role() service)让这些Token只能访问特定API。这比在Firebase里硬编码Service Account更灵活。2.5 存储与函数Storage API与Edge Functions——补齐最后两块拼图Supabase Storage不是另一个S3而是S3兼容层之上的抽象。它把文件上传、下载、删除等操作封装成REST API并把所有元数据如bucket,object_name,owner_id,created_at存入storage.objects表。这样RLS策略就能精确控制“用户A只能删自己上传的avatars桶里的文件”。而Edge Functions基于Deno的Serverless函数则是Supabase的“业务逻辑沙盒”。它不取代传统后端而是处理那些不适合放在数据库里、又不想暴露给前端的逻辑。比如支付回调验签密钥不能放前端图片上传后自动生成缩略图调用Sharp库发送邮件前检查用户余额需查多个表Edge Functions的最大优势是与Supabase Auth深度集成。函数执行时context对象里自带user信息来自JWT你无需再解析Token。一行const { data: profile } await supabase.from(profiles).select().eq(id, user.id).single();就能拿到用户资料。注意Edge Functions的冷启动延迟比Vercel或Cloudflare Workers略高约300-500ms所以高频、低延迟场景如实时游戏状态同步不建议用。但它胜在简单——写完deno.json配置supabase functions deploy myfunc5秒就上线连CI/CD都省了。3. 实战入门从零开始搭建一个带实时协作的笔记应用光说不练假把式。下面我带你用Supabase从零搭建一个“多人实时协作笔记”应用。这个例子覆盖了90%的典型需求用户认证、CRUD操作、实时同步、文件上传、权限控制。我会把每一步背后的“为什么”讲透而不是只给命令。3.1 环境准备三分钟创建你的第一个Supabase项目Supabase提供免费的托管服务Hobby plan足够个人和小团队使用。访问 supabase.com 点击“Start your project”填写项目名如my-note-app、区域选离你最近的如US East、数据库密码记牢这是唯一能重置的凭证。创建完成后你会进入Dashboard。首页右上角的“Project Settings”里有两串至关重要的密钥URL:https://xxxxxx.supabase.co—— 这是所有API的根地址anon key:eyJhbGciOiJIUzI1NiIsInR5c...—— 匿名访问密钥前端SDK用它初始化提示Supabase的密钥体系是“双密钥制”。anon key用于未登录用户的只读访问如公开博客service role key在API Settings里拥有数据库最高权限绝对不能暴露在前端代码里。所有需要高权限的操作如后台批量处理必须放在Edge Functions里用service role key调用。3.2 数据库建模用SQL定义你的业务世界Supabase Dashboard左侧菜单点“Table Editor”再点“Create a new table”。我们建两张表1.notes表笔记主表id: UUID Primary Key, Defaultgen_random_uuid()title: TEXT, Not Nullcontent: TEXT, Not Nulluser_id: UUID, Referencesauth.users(id), Not Nullcreated_at: TIMESTAMP WITH TIME ZONE, Defaultnow()updated_at: TIMESTAMP WITH TIME ZONE, Defaultnow()2.note_collaborators表协作者关系表id: UUID Primary Key, Defaultgen_random_uuid()note_id: UUID, Referencesnotes(id), Not Nulluser_id: UUID, Referencesauth.users(id), Not Nullrole: TEXT, Checkrole IN (editor, viewer), Defaulteditor建表后立即为notes表启用RLSRow Level Security。点表名右侧的“RLS”开关选择“Enable RLS”然后添加两条策略-- 策略1用户只能读自己创建的笔记或被授权协作的笔记 CREATE POLICY Users can read their own notes or shared notes ON public.notes FOR SELECT USING ( auth.uid() user_id OR EXISTS ( SELECT 1 FROM public.note_collaborators WHERE note_collaborators.note_id notes.id AND note_collaborators.user_id auth.uid() ) ); -- 策略2用户只能更新自己创建的笔记 CREATE POLICY Users can update their own notes ON public.notes FOR UPDATE USING (auth.uid() user_id);这两条策略就是整个应用的权限基石。它们确保即使黑客拿到你的anon key也绝不可能读取其他用户的笔记。实操心得RLS策略的USING子句是WHERE条件WITH CHECK子句是INSERT/UPDATE的校验条件。上面的UPDATE策略只用了USING意味着用户可以更新自己笔记但不能把user_id改成别人——因为WITH CHECK默认是USING的逻辑而user_id是受保护字段。这种细粒度控制是Firebase Security Rules难以企及的。3.3 前端集成用supabase-js实现开箱即用的实时协作我们用Vite React快速搭建前端。初始化项目后安装SDKnpm install supabase/supabase-js在src/lib/supabase.ts里初始化客户端import { createClient } from supabase/supabase-js const supabaseUrl import.meta.env.VITE_SUPABASE_URL const supabaseAnonKey import.meta.env.VITE_SUPABASE_ANON_KEY export const supabase createClient(supabaseUrl, supabaseAnonKey)关键来了如何实现“打开笔记页面自动加载内容并实时接收他人编辑”答案是PostgREST Realtime 的组合拳。在笔记页面组件里import { useEffect, useState } from react import { supabase } from ../lib/supabase export default function NotePage({ noteId }: { noteId: string }) { const [note, setNote] useState{ title: string; content: string } | null(null) const [loading, setLoading] useState(true) useEffect(() { // 步骤1用PostgREST一次性加载笔记 const loadNote async () { const { data, error } await supabase .from(notes) .select(title, content) .eq(id, noteId) .single() if (error) throw error setNote(data) setLoading(false) } // 步骤2用Realtime监听该笔记的更新 const channel supabase .channel(note:${noteId}) .on( postgres_changes, { event: UPDATE, schema: public, table: notes, filter: ideq.${noteId} }, (payload) { console.log(收到实时更新:, payload.new) setNote(payload.new as any) } ) .subscribe() loadNote() // 清理组件卸载时取消订阅 return () { channel.unsubscribe() } }, [noteId]) if (loading) return divLoading.../div if (!note) return divNote not found/div return ( div input value{note.title} onChange{(e) { // 步骤3编辑时用PostgREST更新数据库 supabase.from(notes).update({ title: e.target.value }).eq(id, noteId) }} / textarea value{note.content} onChange{(e) { supabase.from(notes).update({ content: e.target.value }).eq(id, noteId) }} / /div ) }这段代码展示了Supabase的精髓PostgREST负责“状态落地”Realtime负责“状态同步”。用户在输入框里打字onChange触发UPDATE请求数据立刻写入PostgresRealtime Server捕获WAL日志瞬间推送给所有订阅了note:${noteId}的客户端。整个过程你不需要写WebSocket连接、心跳保活、消息序列化——全部由Supabase托管。注意上面的UPDATE没有加user_id条件是因为RLS策略USING (auth.uid() user_id)已经确保了用户只能更新自己的笔记。如果用户试图篡改URL参数攻击PostgREST会在SQL执行前就拦截。3.4 权限升级让协作者也能实时编辑上面的代码只允许笔记创建者编辑。现在我们要让协作者也能实时编辑。这需要两步第一步在note_collaborators表里插入一条记录INSERT INTO public.note_collaborators (note_id, user_id, role) VALUES (note-id-here, collaborator-user-id, editor);第二步修改notes表的RLS策略支持协作者更新-- 删除旧的UPDATE策略 DROP POLICY Users can update their own notes ON public.notes; -- 创建新的UPDATE策略创建者或协作者且role为editor可以更新 CREATE POLICY Users can update their own notes or shared editor notes ON public.notes FOR UPDATE USING ( auth.uid() user_id OR EXISTS ( SELECT 1 FROM public.note_collaborators WHERE note_collaborators.note_id notes.id AND note_collaborators.user_id auth.uid() AND note_collaborators.role editor ) );策略更新后协作者的前端代码无需改动Realtime依然会推送更新事件因为他们订阅的是同一个Channel。这就是数据库驱动权限的魅力——逻辑在DB里前端只管呈现。3.5 文件上传为笔记添加图片附件Supabase Storage让文件上传变得像调用一个函数一样简单。假设我们要为笔记添加封面图// 在NotePage组件里 const handleImageUpload async (e: React.ChangeEventHTMLInputElement) { const file e.target.files?.[0] if (!file) return // 1. 生成唯一文件名 const fileName ${noteId}/${Date.now()}-${file.name} // 2. 上传到storage桶需在Dashboard里先创建 const { error } await supabase.storage .from(note-images) .upload(fileName, file) if (error) throw error // 3. 更新notes表存入图片URL const { data } await supabase.storage .from(note-images) .getPublicUrl(fileName) await supabase.from(notes).update({ cover_image_url: data.publicUrl }).eq(id, noteId) }关键点在于getPublicUrl()。Supabase Storage默认生成的URL是带签名的临时链接有效期1小时但getPublicUrl()返回的是永久公开链接前提是该文件所在的Bucket启用了“Public Access”。你可以在Dashboard的Storage设置里为note-images桶开启Public Access然后RLS策略会自动生效——只有协作者才能看到这个URL对应的文件。实操心得Supabase Storage的URL是https://project-id.supabase.co/storage/v1/object/public/note-images/path。这个URL可以直接在HTMLimg src...里使用浏览器会自动缓存。比Firebase Storage的gs://协议更友好。4. 进阶实战用Supabase构建AI应用的向量数据库底座Supabase的爆火和AI浪潮密不可分。标题里提到的“AI Vector/Embeddings Toolkit”不是营销话术而是它把Postgres的pgvector扩展变成了开箱即用的AI基础设施。下面我以一个“智能客服知识库”为例展示如何用Supabase实现语义搜索。4.1 向量数据库选型为什么是pgvector而不是专用向量DB市面上有Pinecone、Weaviate、Qdrant等专用向量数据库但Supabase坚持用pgvector理由很实在数据一致性客服知识库的文本、元数据如所属产品线、更新时间、负责人、向量必须强一致。专用向量DB通常只存向量文本还得另存到Postgres查一次要跨两个系统延迟高、事务难。运维简单pgvector是Postgres的一个扩展CREATE EXTENSION vector;一条命令就装好。而部署Qdrant你需要Docker、配置YAML、管理存储卷对小团队是负担。SQL生态你可以用SQL做混合查询。比如“找和‘退款流程’语义相似且product_line mobile且updated_at 2024-01-01的知识条目”。这在专用向量DB里要么不支持要么要写复杂的filter DSL。Supabase托管服务已预装pgvector你无需任何操作。只需在public.knowledge表里加一个embedding列ALTER TABLE public.knowledge ADD COLUMN embedding vector(1536);这里的1536是OpenAItext-embedding-ada-002模型的输出维度。如果你用其他模型如nomic-embed-text是768维就填对应数字。4.2 数据注入从文本到向量的自动化流水线Supabase本身不提供向量生成服务但它的Edge Functions完美适配这个场景。我们创建一个generate-embedding函数// functions/generate-embedding/index.ts import { serve } from https://deno.land/std0.200.0/http/server.ts; import { createClient } from https://esm.sh/supabase/supabase-js2; const supabaseClient createClient( Deno.env.get(SUPABASE_URL) ?? , Deno.env.get(SUPABASE_SERVICE_ROLE_KEY) ?? ); serve(async (req) { const { text, knowledge_id } await req.json(); // 调用OpenAI API生成向量生产环境请用环境变量存key const response await fetch(https://api.openai.com/v1/embeddings, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${Deno.env.get(OPENAI_API_KEY)}, }, body: JSON.stringify({ input: text, model: text-embedding-ada-002, }), }); const data await response.json(); const embedding data.data[0].embedding; // 将向量存入knowledge表 const { error } await supabaseClient .from(knowledge) .update({ embedding }) .eq(id, knowledge_id); if (error) throw error; return new Response(JSON.stringify({ success: true }), { headers: { Content-Type: application/json }, }); });部署后每当有新知识条目入库后端只需调用这个函数curl -X POST https://project-id.supabase.co/functions/v1/generate-embedding \ -H Authorization: Bearer service-role-key \ -H Content-Type: application/json \ -d {text: 用户申请退款后款项将在3-5个工作日内原路返回。, knowledge_id: k-123}注意Edge Functions的环境变量是安全的OPENAI_API_KEY不会泄露。而如果你在前端调用OpenAI API密钥就暴露了。4.3 语义搜索一行SQL实现毫秒级相似度查询有了向量搜索就变得极其简单。Supabase的PostgREST支持向量运算你前端直接发HTTP请求# 搜索和“怎么退钱”最相似的3条知识 curl https://project-id.supabase.co/rest/v1/knowledge?selectcontent,titleorderembedding-cosine_distanceembeddingneq.[]limit3 \ -H Authorization: Bearer anon-key \ -H Content-Profile: public \ -d {embedding: [0.1, 0.2, ..., 0.1536]}这个请求里embedding-cosine_distance是PostgREST的特殊语法它会调用pgvector的cosine_distance函数计算查询向量与所有embedding列的余弦距离并按距离升序排列距离越小越相似。在前端代码里你只需要const searchQuery 怎么退钱; const embedding await getEmbeddingFromOpenAI(searchQuery); // 用Edge Function或后端API const { data } await supabase .from(knowledge) .select(content, title) .order(embedding, { ascending: true, nullsFirst: false, foreignTable: null }) .match({ embedding }); // match会自动转换为向量距离查询实测在10万条知识的数据集上平均响应时间80ms。这得益于pgvector的IVFFlat索引——你只需在embedding列上建索引CREATE INDEX ON public.knowledge USING ivfflat (embedding vector_cosine_ops) WITH (lists 100);lists 100表示将向量空间划分为100个簇查询时只搜索最相关的几个簇大幅提升速度。4.4 RAG增强把向量搜索结果喂给LLMRAGRetrieval-Augmented Generation是AI应用的核心模式。Supabase让RAG的“检索”部分变得无比轻量。假设你有一个客服对话界面用户问“我的订单还没发货怎么办”流程如下前端调用getEmbeddingFromOpenAI(我的订单还没发货怎么办)生成向量用上述向量搜索knowledge表得到Top 3最相关知识条目把这3条知识 用户原始问题拼成Prompt发给LLM如Open