PostgREST 兼容性：它涵盖的内容和替代方案

PostgREST 是一个自治 Web 服务器，可直接从其架构将现有 PostgreSQL 数据库转换为 REST API。无需编写应用程序层：表、视图和函数成为路由，SQL 权限（角色、RLS 策略）成为授权层。

具体来说，PostgREST 涵盖了几乎所有评估中都会出现的五种功能：

• 水平过滤 — 大约 30 个运算符（eq、 gt、 like、 ilike、 in、 is、 cs、 ov、 fts...）直接在查询字符串中。
• 垂直过滤和嵌入 — ?select= 通过外键投影列并嵌入关系，例如 customer:customers(email)。
• RPC — POST /rpc/{fonction} 直接调用 SQL 函数，该函数成为端点。
• 由 JWT 驱动的 RLS — PostgREST 根据收到的令牌 (SET LOCAL ROLE) 切换活动的 Postgres 角色，因此您的策略按原样应用，而无需在应用程序端重复授权逻辑。
• 自生成 OpenAPI — 该规范是从公开的架构中推导出来的，无需手动维护文件。

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

单个 HTTP 请求即可过滤已付款订单，通过外键嵌入客户的电子邮件，并按日期排序 — 无需手动编写单个路由。

RPC 遵循相同的逻辑：数据库中已编写的 SQL 函数成为 POST 端点，其参数以 JSON 形式传递。

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

这一原则（Postgres 模式是 API 的单一事实来源）使 PostgREST 可预测：每个行为更改都会通过 SQL 迁移，而不是通过可以从实际模式派生的单独应用程序层。该项目是开源的，在 GitHub上开发，独立于任何特定的 BaaS 提供商。

PostgREST 解析 CRUD 层。它不解析应用程序后端的其余部分。单独采用它的团队会系统性地出现四个缺点。

• 身份验证 — 无 JWT 发行或集成用户管理。您必须使用 SQL 构建它或将其委托给外部服务。
• 文件存储 — 无。 S3 存储桶或等效设备仍需单独连接。
• 实时 — PostgREST 响应一次性 HTTP 请求，它不推送任何事件。
• 连接池程序 — PostgREST 本身连接到 Postgres，但不集成任何高级池程序。在规模上，管理它本身就成为一项运营决策：经典事务模式下的池化器与 PostgREST 架构重新加载机制发生冲突（请参阅下面的 Aurabase 如何解决这种妥协）。

一个实际的结果值得明确说明：如果没有身份验证，您的 RLS 策略将成为匿名客户和您的数据之间的唯一安全边界。关于 anon 角色的写得不好的策略不会被额外的应用程序层取代——没有。

在 Aurabase Postgres 引擎项目（默认引擎）上，网关将每个 CRUD 请求直接路由到专用于此项目的 PostgREST v12.2.8 实例（两个副本），与租户的 Postgres 集群位于同一位置。这不是近似兼容性：它是 PostgREST 上游二进制文件本身，具有相同的运算符、相同的嵌入、相同的 RPC、由 JWT 驱动的相同的 RLS。

在 MongoDB 引擎项目中，情况有所不同。 MongoDB 没有与 PostgREST 相当的东西：这些请求被路由到内部 Aurabase 服务，该服务重新实现了相同约定的子集 — 相同的运算符名称、带嵌入的 ?select= 语法、Prefer 和 Content-Range 标头 — 但在文档引擎上，而不是关系引擎上。该层有其自身的局限性：在突变返回的表示中请求的嵌入被显式拒绝而不是默默地忽略，并且不存在与 SQL 函数等效的 RPC 路由。

技术细节与直觉相反：每个专用 PostgREST 实例保持直接连接到主 Postgres，而不通过为此租户部署的 PgBouncer 池化器。假设原因：事务池模式会破坏 PostgREST 架构重新加载，该模式依赖于 LISTEN/NOTIFY — 持久连接，与为每个事务回收连接的池不兼容。

生产中另一个有用的细节：可以暂停不活动的项目以节省资源。休眠项目上的第一个请求会触发其唤醒并收到带有重试延迟的 503 ，这是专用 PostgREST 实例恢复的时间 - 假定是成本和冷延迟之间的折衷，而不是隐藏事件。

PostgREST 有一个明确的用途：Postgres 模式是事实来源，团队希望避免手动编写 CRUD 层。除了这种特定情况之外，还存在多种替代方案，具体取决于您想要添加的内容 - 从什么都没有（裸自托管）到完整的即用型后端。

下表比较了每个选项本身涵盖的内容以及它明确留给您的内容——无需对每个项目选择的架构进行价值判断。

选择“自托管”时经常低估的一点是：PostgREST 本身运行起来仍然很轻，但生产操作（版本更新、高可用性、与池化器关联、监控）仍然完全由您负责 - 托管平台吸收的是此操作工作，而不是软件。

有关 GraphQL 方法（pg_graphql、Hasura 和 PostGraphile）之间的详细比较，请参阅 我们专门介绍 Postgres 上 GraphQL API 的文章。

最常出现四种情况。正确的选择主要取决于您愿意自己组装和维护什么。

• 您只需要一个基于现有 Postgres 架构的 REST API，仅此而已。 自托管 PostgREST 就足够了：它的功能完全一样，不需要安装其他任何东西。
• 您需要额外的身份验证、存储和实时性，并且您已准备好组装多项服务。 Supabase 或 PostgREST 以及您自己的应用程序堆栈可以满足此需求。
• 与 REST 相比，您更喜欢 GraphQL。 Hasura 或 PostGraphile 涵盖了这个领域——不同的架构选择，而不是 PostgREST 的直接替代品。
• 您想要一个完整的 Postgres 后端，而不需要将多个单独的服务拼接在一起。 这是我们的 统一 Rust 架构 文档的角度：CRUD 层的真正 PostgREST，原生围绕着身份验证、存储、实时和边缘功能。