Supabase 是什么？看懂 AI 应用背后的数据库、权限与后端

Supabase 为应用提供 1 个完整的 Postgres 数据库，以及登录、文件存储、服务端代码、实时更新和向量搜索服务。AI 应用构建工具可以把生成的界面接到这套后端上，但谁能访问数据、谁掌控项目，以及将来如何迁移，仍然需要你来决定。

Supabase 是什么？它在应用中负责哪一层？

Supabase 是以托管 PostgreSQL 为核心的后端平台。PostgreSQL 通常简称 Postgres，用相互关联的表存储记录。用户关闭浏览器后，负责保存数据、执行规则的部分就是后端；用户看到并点击操作的界面则是前端。

每个 Supabase 项目都有完整的 Postgres 数据库，周边服务则补上原本需要单独开发或集成的功能。你可以在控制台的 Table Editor 中查看记录，在 SQL Editor 中编写查询，也可以通过应用代码连接。正如数据库概览所述，这些入口通向的都是同一个数据库。

可以把客户门户想成一栋配有基础服务的大楼：前端是公共入口，Postgres 保存档案，Auth 核验身份，Storage 存放文件，服务端函数处理不该由访客自行执行的工作。Supabase 提供了大部分基础设施，但哪个客户可以进入哪个房间，仍要由应用制定规则。

这就是这里所说的后端即服务（BaaS）：使用托管的后端组件，省去逐一搭建和运维的工作。业务规则不会因此自动写好。

本文已于 2026 年 11 月 7 日对照线上产品文档核实。 下文围绕数据结构、访问控制、开发流程和可迁移性展开，不预设特定的流量承载能力或可用性保证。

Supabase 适合用来做什么？

当应用需要长期保存记录、管理账号，并控制记录的访问权限时，Supabase 就有用武之地。客户门户、预约服务、内部运营工具和会员产品都是典型场景。没有账号，也不保存应用数据的静态落地页，可能根本不需要这套后端。

以一家服务公司的客户门户为例：客户上传需求、确认交付内容、查看项目进度。数据库可以把客户与项目关联，再把项目与审批记录关联。上传的 PDF 应放在文件存储中；数据库记录则说明由谁上传、属于哪个项目。即使控制台把它们放在一起展示，两者承担的工作也不同。

AI 生成的界面最初可能只在浏览器里展示示例项目。接入 Supabase 后，生成的代码才有地方读写持久化数据。但接通数据库，并不能证明生成的数据关系、权限或审批规则符合你的业务。

Supabase 还会根据数据库 schema，也就是表及其关系的结构，生成 Web API。API 是软件向另一个系统请求执行工作的接口。Data API 文档介绍了如何从浏览器直接调用，也介绍了如何与自己的应用服务器配合使用。正因为如此，构建工具连接生成的界面时，无须先为每项基础数据库操作编写独立的服务端接口。

实际分工如下：

对创始人而言，交接时应拿到一个名称明确、可以自行查看的后端项目，并有人能解释其中的规则。仅有能运行的预览，还回答不了这些问题。

逐个认识 Supabase 的核心组件

每个组件解决的问题不同，按需选用即可。一个简单的账号制门户，不会因为平台支持实时协作或语义搜索，就必须把这些功能都加上。

Postgres：保存应用的业务记录

Postgres 用表存储结构化数据，并连接相关记录。在前面的门户里，客户、项目和审批是不同类型的记录，彼此存在关联。SQL 是查询和修改这些数据的语言。这样，查询“这个客户还有哪些项目尚未审批”时，就可以沿着这些关系找到答案。Supabase 围绕这个数据库构建服务，而没有用专有表格式取代它。架构文档说明了背后的开源组件和标准导出机制。真正的难点仍是数据设计：即使表由 AI 创建，定义不清的归属和关系也不会自动变清楚。

Supabase Auth 是什么？

Supabase Auth 管理用户账号和登录方式，包括密码、邮件登录链接、一次性密码和社交账号登录。它会签发带签名的身份令牌，供应用在后续请求中携带。在客户门户中，Auth 确认登录者是哪位客户；数据库访问策略决定这位客户可以读取哪些项目。Auth 文档明确区分了身份认证与授权：前者核验身份，后者检查访问权限。因此，生成的登录界面可能运转正常，数据权限却仍有问题。验收时，“能登录”和“只能访问应有的记录”应分别检查。

Storage：存放记录背后的文件

Supabase Storage 保存图片、文档、视频等文件，Postgres 则保存描述文件的元数据。在门户里，需求 PDF 是存储对象，它对应的项目和所有者可以记录在数据库中。Storage 概览介绍了文件分发、访问策略，以及专用的分析存储桶和向量存储桶。关键是区分文件本身与描述文件的那一行记录。项目表受到保护，不代表文件下载路径也已设为私有。需要明确哪些上传内容是公开素材，哪些只能由经过身份认证的客户访问。

Edge Functions：在服务端执行工作

Supabase Edge Functions 在兼容 Deno 的运行时中执行服务端 TypeScript 代码。TypeScript 是编程语言，运行时则是执行代码的环境。函数可以接收其他服务发送的事件通知，也就是 webhook，并调用外部 API。例如，支付通知可以触发函数，核验事件后更新账号状态。Edge Functions 指南还介绍了发送邮件和调用 AI 服务的用途。当浏览器不该持有凭据或决定处理结果时，这类需要受信任环境的工作就应放在服务端。函数仍需授权检查和错误处理，生成一个接口并不代表这些问题已经解决。

Supabase Realtime 是什么？

Supabase Realtime 通过 Broadcast 广播消息、表示在线用户状态的 Presence，以及对 Postgres 变更的订阅，向已连接的客户端推送更新。在门户里，项目状态变化后，其他人的屏幕可以直接更新，无须手动刷新；协作界面也可以显示谁在线。Realtime 文档将这些列为不同能力。它们有助于实时交互，但不会替你定义编辑冲突的处理方式，也不会自动提供离线工作流程。只有用户确实需要立即看到变化时，再引入 Realtime；普通表单提交可能只需要保存记录并刷新视图。

向量搜索：找到含义相近的内容

Supabase 通过 pgvector 在 Postgres 中支持向量搜索。pgvector 是用于存储和比较 embedding 的扩展；embedding 即嵌入，是将内容表示为数值、用来寻找相似性的方式。门户可以用它查找讨论类似客户问题的需求文档，即使用词不同也能匹配。AI 与向量文档涵盖嵌入的存储、索引和查询，以及语义搜索、关键词搜索和混合搜索。这为 AI 功能提供了检索组件，但不会自动读取每份上传的 PDF、生成嵌入、选择正确的权限过滤条件或给出可信答案。这些步骤都需要纳入应用的实现。

AI 应用构建工具和编程智能体如何使用 Supabase？

AI 应用构建工具把生成的应用代码接到后端；编程智能体还可以获得检查或修改后端本身的工具。两者都能减少开发工作，但带来的访问权限不同。开始处理真实客户数据后，这个区别尤其重要。

Lovable：使用自己的项目，还是内置后端？

Lovable 的 Supabase 集成可以把应用连接到你拥有的 Supabase 项目，然后创建数据库结构、执行迁移、部署函数，并让界面读写数据。迁移是有记录的数据库变更，例如新增表或修改列。当前集成文档还说明，内置后端默认启用，并采用 Supabase 的开源基础。因此，并非每个 Lovable 应用都需要单独的 Supabase 账号。

这直接关系到谁掌控后端连接。“使用 Supabase 技术”不等于你的 Supabase 组织中就有一个可直接进入控制台的项目。Lovable 表示，内置后端与自有 Supabase 项目之间无法自动切换。最好在应用积累客户记录和配置之前，就确定采用哪种安排。

Bolt：应用版本历史与数据库历史要分开看

Bolt 可以连接 Supabase，使用数据库、身份认证和 Edge Functions。当前的 Supabase 集成指南说明，新项目默认使用 Bolt 数据库，而在 Supabase 中连接或认领数据库需要 Pro 或 Teams 套餐。如果你的方案要求直接管理 Supabase，就需要主动完成相应连接。

恢复能力有一个关键限制：Bolt 的 Version History 不会还原 Supabase 数据库。 把应用回退到旧版本，数据库仍保持当前状态。如果生成的变更删除或转换了已有数据，恢复旧界面与恢复数据是两件事。在把构建工具的撤销按钮当成恢复方案之前，先要求提供数据库恢复计划。

v0：数据库连接与工具权限是两回事

v0 通过数据库集成支持 Supabase。数据库连接文档介绍了如何选择现有数据库，或通过 Marketplace 创建数据库，再让后续生成过程使用这个连接。这样，构建工具就能基于真实后端工作，而不只是生成界面样稿。

v0 还介绍了 Marketplace 集成提供的 MCP 工具，包括 Supabase 的工具，以及连接其他 MCP 服务器的方式。MCP 指南区分了生成过程中可用的工具与生成后应用能够调用的能力。给开发工具接入某项能力，并不会自动让客户获得同一工具。应用使用的后端连接，以及构建它的智能体获得的权限，都需要检查。

Supabase MCP 服务器：开发权限会带来实际影响

Model Context Protocol，简称 MCP，是 AI 智能体使用外部工具的一种标准方式。Supabase MCP 服务器可以提供检查数据库、执行 SQL、应用迁移、查询日志和部署 Edge Functions 的工具。智能体不必再猜测有哪些表，而是可以查看实际项目，并针对它进行修改。

Supabase 的 MCP 文档建议使用开发项目而非生产数据，将访问范围限制到具体项目，手动审批工具调用，并在适当情况下启用只读模式。这些措施分别回答：智能体能连接哪个项目、能执行哪些操作，以及哪些动作需要审核。只读访问仍可能暴露数据，因此不能替代对智能体可见信息范围的判断。

普通应用连接服务于用户，MCP 连接服务于开发智能体。不能默认认为智能体会自动受到每位客户在应用中有限权限的约束。

Supabase 的 AI 工具目录还区分了实时 MCP 访问、提供可复用操作指引的 Agent Skills，以及将两者打包的插件。复制来的提示词也是指令来源，但不是实时数据库连接。更广泛的集成目录则列出控制台集成、合作伙伴目录、Vercel Marketplace 和 Stripe Projects。这些是连接或开通服务的不同路径，不能都当作 MCP 的别称。

Supabase 的 RLS 是什么？

Row Level Security，简称 RLS，即行级安全，是数据库中决定某个请求可以访问哪些行的策略系统。在客户门户中，它可以实现这样的规则：客户能读取和修改自己组织的记录，但不能访问其他客户的记录。

它与登录的分工很明确：Auth 提供身份；数据库授权决定该身份对应的角色是否能对某张表执行某项操作；RLS 策略决定这项操作可以影响哪些行。Supabase 的行级安全指南要求开发者配合配置数据库授权与策略，并同时测试应该允许和应该拒绝的操作。

创始人在验收生成的应用时，最有用的是测试客户之间的隔离。创建相互独立的测试客户，让他们各自对自己的记录执行预期操作，同时确认读取或修改另一位客户记录的尝试都会失败。还要纳入未登录访客。开发者应测试底层数据请求，因为隐藏按钮不等于设置访问策略。

Supabase 安全吗？

Supabase 提供访问控制机制，但具体应用是否安全，取决于这些机制的配置和使用方式。界面精美或成功登录，都不足以证明安全。要看未经授权的请求是否会在提供数据的那一层被拒绝。

文件也需要单独检查。Supabase 的存储桶访问文档指出，公开存储桶允许任何拿到资源 URL 的人获取该资源。这适合公开图片，却不适合作为机密客户需求文件的默认设置。检查数据库策略时，也要一并核对存储访问模式。

Supabase 的 anon key 是什么？

anon key 是旧版的可发布 API 密钥，对应现在的 publishable key，用于公开的应用组件。API 密钥标识应用组件，登录用户的身份则另行提供。Supabase 当前的 API 密钥文档建议新项目使用 publishable key 和 secret key。如果生成代码还在使用旧术语，应让开发者对照当前文档核查，不能假设所有密钥拥有相同权限。

secret key 和旧版 service_role key 会绕过 RLS。 它们应放在受信任的后端组件中，由这些组件自行执行授权检查，绝不能随浏览器代码一起交付。为了让失败的请求成功而换上高权限密钥，可能恰好破坏了应用原本需要的客户隔离。

你掌控什么？哪些能迁移，哪些需要额外处理？

Supabase 提供开源基础和标准 Postgres 数据，因此有切实可行的退出路径。但迁移整个应用，仍不只是导出数据库。

首先确认控制权：应用所在的代码仓库、Supabase 组织和项目、相关配置，以及能管理访问权限的账号。如果后端由承包方或构建工具开通，就让对方明确说明这些控制入口在哪里。这是对实际运维控制权的核查，并不表示所有构建工具的账号安排都一样。

接下来有两种不同的迁移选择：迁往另一个 Supabase 部署，保留周边服务；或者把数据库迁到其他 Postgres 托管平台，并替换应用调用的 Supabase 专有服务。两种情况下，保留 SQL 数据都有价值。但后一种方案无法仅靠修改连接字符串完成。

从托管平台恢复到自托管环境的指南把边界说得很具体：

数据库函数与 Edge Functions 是不同的东西。 前者在 Postgres 内部运行，属于数据库定义；后者是在函数运行时执行的应用代码。混淆两者，会高估一次导出的完整程度。

自托管方面，Supabase 推荐使用 Docker，让平台服务在容器中运行。自托管文档明确要求你自行负责服务器维护、安全更新、数据库维护、备份、恢复和监控。文档也列出了自托管环境没有的托管功能，包括托管分支、托管备份、时间点恢复，以及向量存储桶。其中，时间点恢复指将数据库还原到选定的历史时刻。因此，开源不意味着与云端功能逐项对等。

如果小公司没有专人负责运维，从托管 Supabase 起步更合理。退出方案需要清楚，但不必仅仅因为可以自托管，就承担这份工作。如果确实需要掌控基础设施，应先演练恢复和周边服务配置，再决定迁移。

什么时候选 Supabase，什么时候考虑其他后端？

选择应依据应用的数据与运维需求。AI 构建工具的推荐能简化集成，但不能代替完整的架构判断。

Supabase 好用吗？

如果应用包含相互关联的业务记录，并且需要数据库访问、身份认证、文件和服务端逻辑协同工作，Supabase 很合适。相比展示型网站，一个由客户拥有各自项目的服务公司门户更能发挥它的价值。即使大部分实现由 AI 编写，也应有人能够解释和维护数据关系及授权规则。

真正绕不过去的是应用本身的责任归属。Supabase 托管组件，却不会替你决定客户能否邀请其他用户、审批能否撤销，或员工能否查看所有账号。如果无人负责这些决定，换一个后端也解决不了。

套餐、内含用量和超额费用，可参阅我们的 Supabase 价格指南。

Firebase：以离线文档工作流为核心时

如果应用的核心需求是支持离线操作的移动端工作流，且数据适合文档模型，就值得仔细考察 Firebase。它的文档数据库 Cloud Firestore 支持缓存读取和写入，并在设备重新联网后同步。Firestore 文档介绍了这种行为。例如，外勤人员需要在网络不稳定时记录拜访情况，就是一个明确的评估理由。

代价是必须选好并理解这种数据模型及同步行为。不能假设 Firestore 可以直接替换围绕关系表设计的应用。同样，“Firebase 只有 NoSQL”现在也过于笼统：Google 还在 Firebase SQL Connect 下提供了托管 PostgreSQL 产品的文档。应比较具体的数据库产品，而不只是平台名称。我们的 Supabase 与 Firebase 对比进一步讨论了如何选择。

Neon：开发流程依赖数据库分支时

如果隔离的数据库分支是开发和测试的核心，就值得评估 Neon。分支为计划中的变更提供独立的数据库状态，让你能在影响父分支之前先行验证。分支文档介绍了独立的开发和测试环境；当不宜复制生产数据时，也可以使用仅包含 schema 的分支。

选择 Supabase 或 Neon 时，不要沿用“完整后端对比纯数据库”的过时划分。Neon 的当前产品文档也列出了身份认证、存储、函数和实时能力。托管身份认证文档说明，用户和会话数据会随数据库一起分支。应按应用需要的开发流程及服务行为选择。把现有的 Supabase 服务调用改接过去，仍需要集成工作。

普通 Postgres 托管：其他后端组件已经齐备时

如果现有应用服务器已经处理登录、授权、文件存储和后台任务，那么普通的 Postgres 托管可能更简洁。此时你需要的也许只是托管数据库连接，以及托管商的数据库运维能力，无须再引入另一套应用服务。

代价在于组装与维护。周边后端或所选配套服务，仍由你负责。对这些部分已经就位的现有产品，这可能很合适；对只有生成界面、还没有后端的创始人而言，要让应用端到端运转，可能就得先做更多决定。

关于 Supabase，哪些说法被夸大了？

“接上后端，生成的应用就可以放心依赖了”是一种夸大。连接成功只能证明组件之间能够通信，不能证明权限正确、可以恢复，或业务行为符合预期。

“开源意味着迁移不费事”同样夸大了便利性。导出路径确实有价值，但前面提到的文件和配置工作仍然存在。“有向量搜索就是 AI 产品”跳过了文档预处理、检索质量、权限，以及负责生成答案的模型。“实时更新就是离线同步”则混淆了即时更新与断网可用这两种需求。

计算资源也有明确边界。Supabase 托管 Edge Function 的限制规定，每个请求可使用 256 MB 内存和 2 秒 CPU 时间，不计等待异步输入或输出的时间。函数等待外部服务响应，与用同样长的时间执行计算，是不同情况。重度处理需要合适的工作进程设计；升级套餐本身不会解除所有运行时约束。

应依据这些限制安排工作在何处执行。接收通知并更新一条记录的门户，与处理大型媒体文件的门户，负载不同。实际要问的是哪些工作在哪里运行，而不是平台能否无限“扩展”。

正式依赖生成的应用之前，要先做什么？

如果 Supabase 符合应用需求，就继续构建，但在接收真实客户数据前，必须把后端交接说清楚。接手现有应用的运营者，应先检查当前安排，再考虑更换服务商。如果创始人只是在搭建公开的信息网站，则等到真正需要持久化数据时再引入后端。

1. 1

   确认自己能掌控的后端

   让构建方或开发者展示具体项目、控制它的组织、应用代码仓库，以及连接应用和后端的配置。确认使用的是你自己的 Supabase 项目，还是构建工具管理的后端。

2. 2

   验证客户之间的数据隔离

   要求提供证据，证明测试客户可以访问自己的记录，却不能读取或修改其他客户的记录。测试应涵盖未登录请求、私有文件下载和服务端操作。除界面外，也要检查底层请求。

3. 3

   隔离开发变更与客户数据

   为编程智能体提供开发项目，只授予它需要的工具。在将变更推向正式环境之前，审核迁移和权限变更。开发智能体的访问权限应与应用用户的权限分开管理。

4. 4

   明确恢复与退出流程

   问清楚由谁恢复误删的数据、从哪里恢复文件，以及哪些函数代码和设置需要重新部署。把答案和应用资料放在一起。代码导出或构建工具的版本历史，不应是全部答案。

下周就可以安排一次简短演示：用实际项目证明控制权、客户隔离和恢复能力。如果构建方解释不清这些部分，应先补齐，再增加新功能。

创始人常问的 Supabase 问题

Supabase 如何处理身份认证？

Supabase Auth 管理登录并签发身份令牌。应用在请求中携带用户令牌，数据库和存储策略决定该用户可以访问什么。添加登录与定义客户权限，是不同的任务。

superbase 是什么意思？

如果你指的是这个后端产品，它的名称是 Supabase。它将 Postgres 数据库与身份认证、存储、函数和实时更新等服务组合在一起。“Superbase”不是这个产品的正确拼写。

Supabase 有哪些优势？

主要优势是围绕标准 Postgres 数据库集成了后端服务。构建账号制应用时，无须逐一拼装所有组件，同时保留数据库导出和自托管的选择。权限设计和负责任的应用运维，仍然需要有人承担。

有哪些比 Supabase 更合适的选择？

Firebase 的 Firestore 可能更适合离线文档工作流；当分支是开发的核心时，值得评估 Neon；已有周边后端服务的应用，则可能适合普通 Postgres 托管。当 Supabase 的集成组件符合正在构建的应用时，它就是很有力的选择。

有大公司使用 Supabase 吗？

Supabase 发布的客户案例包括 eXp Realty。这能证明有企业采用它，但不能保证你的项目能达到某种容量或可用性。应评估自己应用的具体架构和运维要求。

Supabase 适合新手吗？

托管组件和可视化数据库编辑器能降低起步难度。但新手仍需理解记录、关系和访问规则，或与懂这些内容的人合作。AI 可以帮助实现，最终行为仍需验证。

Supabase 为什么受欢迎？

它的实际吸引力在于，常见应用需求都围绕同一个 Postgres 项目提供，并有构建工具可用的 API 和集成。这减少了需要逐一连接的独立后端组件数量，但不意味着每个应用都需要所有 Supabase 服务。

想继续了解 AI 产品背后工具的实际用法，可以订阅邮件通讯。