Supabase：现代 AI 应用为何再次选择 Postgres

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式。

后端复杂性正悄然变得可选

多年来，构建生产应用意味着要组合一套熟悉的技术栈：

• 后端框架（Node/Express、Django 等）
• 认证系统
• 数据库 API
• 文件存储
• 实时基础设施
• 权限层
• 部署流水线

甚至在编写实际业务逻辑之前，工程师们就要花数周时间搭建这些基础设施。

随后 Supabase 等工具出现——并且发生了一件有趣的事。

开发者开始在不编写传统后端代码的情况下交付全栈应用。

本文将解释 Supabase 实际上是什么，它的技术实现原理，以及它为何在 AI 与基于 RAG 的应用中变得尤为重要。

什么是 Supabase？

Supabase 是一个围绕 PostgreSQL 构建的开源 后端即服务 (BaaS)。
Supabase 并不是用专有系统取代数据库，而是将 PostgreSQL 变成完整的后端平台。

Supabase 结合了：

• PostgreSQL 数据库
• 身份验证
• 自动生成的 API
• 实时订阅
• 文件存储
• 无服务器边缘函数

全部在同一个平台上统一管理。

可以把它想象成：
PostgreSQL + Backend Infrastructure = Supabase

核心理念：你的数据库即后端

传统架构：

Frontend → Backend Server → Database

Supabase 将其简化为：

Frontend → Supabase → PostgreSQL

后端层并未消失——它已实现自动化。

当您在 Supabase 中创建表时

• REST APIs 会自动生成。
• Permissions 通过数据库策略强制执行。
• Realtime listeners 会立即可用。
• 您的数据库模式实际上定义了您的 API。

为什么 PostgreSQL 很重要

许多后端平台会抽象掉数据库，而 Supabase 则相反，提供完整的 PostgreSQL 功能：

• 关系建模
• 联接和事务
• 索引
• SQL 查询
• 扩展生态系统

这点很重要，因为真实的应用最终需要关系型数据。

示例查询

SELECT users.name, projects.title
FROM users
JOIN projects ON users.id = projects.owner_id;

此类查询在 Postgres 中很自然，但在以 NoSQL 为主的系统中会非常痛苦。

自动 API（无需编写后端）

Supabase 自动将数据库表暴露为安全的 API。

JavaScript 客户端示例

const { data } = await supabase
  .from('projects')
  .select('*');

• 无服务器路由。
• 无控制器。
• 无 ORM 设置。

API 层直接从你的模式生成。

在不重新发明登录系统的情况下进行身份验证

Supabase Auth 包括：

• 邮箱/密码登录
• OAuth 提供商（Google、GitHub 等）
• 魔法链接
• 基于 JWT 的会话

行级安全（RLS）：数据库层面的安全

Supabase 不在后端代码中强制权限，而是使用 PostgreSQL 行级安全。

策略示例

CREATE POLICY "Users can see their own data"
ON projects
FOR SELECT
USING (auth.uid() = owner_id);

• 即使直接访问 API，数据库本身也会强制访问规则。
• 安全性更贴近数据——它本该所在的位置。

无 WebSocket 的实时系统

Supabase 实时流式传输数据库更改。

当数据更改时：

Database update → Realtime event → UI update

使用场景

• 聊天应用
• 协作工具
• 仪表盘
• 实时通知

无需自定义 WebSocket 基础设施。

为什么 Supabase 在 AI 开发中迅速崛起

现代 AI 应用需要：

• 用户数据
• 对话历史
• 嵌入向量
• 语义搜索
• 实时响应
• 安全的执行环境

Supabase 对这套技术栈的支持出乎意料地好。

1. 使用 pgvector 的向量存储

Postgres 扩展 pgvector 允许直接在数据库中存储嵌入向量。

Text → Embedding → Stored in Postgres → Similarity search

这使得检索增强生成（RAG）系统无需单独的向量数据库。

2. 统一的数据 + AI 上下文

不再需要：

App DB + Vector DB + Auth System + API Server

你可以使用 单一平台：

Supabase（关系数据 + 嵌入向量共存）

3. 用于 AI 工作流的 Edge Functions

Edge Functions 允许安全执行：

• LLM API 调用
• 文档处理
• 后台任务
• Webhooks

它们成为 AI 流水线的编排层。

架构转变：后端轻量应用

Supabase 代表了一种更广泛的转变：工程师正从 基础设施工程 转向 产品智能工程。

我们不再围绕数据库构建系统，而是在数据库之上配置平台。

开发者关注点转向

• 用户体验
• AI 工作流
• 数据建模
• 系统设计

Supabase 与 Firebase（快速比较）

当 Supabase 是绝佳选择时

• ✅ AI 应用（RAG，副驾驶）
• ✅ SaaS 平台
• ✅ 仪表盘
• ✅ 协作工具
• ✅ 需要生产级可扩展性的 MVP

何时可能不使用它

您可能更倾向于使用自定义后端，如果：

• 您需要高度复杂的后端业务逻辑。
• 系统中大量的后台处理占主导。
• 存在严格的本地企业约束。

最终思考

Supabase 不仅仅是一个生产力工具——它反映了更深层次的架构变革。

PostgreSQL 正在从“数据库”演进为 应用平台。

随着 AI 驱动的产品增长，能够在保持完整关系功能的同时降低基础设施开销的平台将变得越来越有价值。

Complexity while keeping architectural flexibility will likely define the next generation of web development.

The interesting question isn’t whether Supabase replaces backend engineering.

It’s whether backend engineering itself is being redefined.