PostgREST 与 Hasura 与自定义 API

“PostgREST 或 Hasura 或自定义 API”这个问题隐藏了一个更有用的问题：谁编写您的业务逻辑，使用哪种工具，以及谁在生产中使用此代码？这三种架构的反应不同，这种差异决定了其他一切——安全性、实施速度、长期技术债务。

严格来说，这三个专栏都没有更好：每个专栏都将工作转移到其他地方。 PostgREST 将其移至 SQL，Hasura 移至配置和 Webhooks，这是经典应用程序代码的自定义 API。

PostgREST 将您的 Postgres 架构转换为 REST API（过滤器、关系嵌入、RPC、由 JWT 驱动的 RLS），无需编写后端。我们在文章中深入详细介绍了该范围，了解其真正的 兼容性及其 替代方案；对于此比较来说，重要的是 PostgREST 停止的位置。

PostgREST 没有任意业务逻辑的概念。每个规则都必须用 SQL 表示：RPC 函数、触发器、约束、RLS 策略。这是一个可接受的约束，而不是疏忽——图表仍然是唯一的事实来源，这消除了应用程序层与其服务的基础之间的任何偏差。

具体来说，无法通过直接的 PostgREST 请求调用第三方支付服务、发送确认电子邮件或在 JavaScript 中计算分数。该逻辑必须存在于 SQL（pl/pgsql 函数）中，或者在外部触发 - 一个发布 NOTIFY事件的触发器，由不再是 PostgREST 的外部服务监听。

我们关于 Postgres 上的 GraphQL 层 的文章详细介绍了 Hasura 引擎的运行位置以及其权限与 Postgres RLS 有何不同。这里的角度是业务逻辑的角度：如何将自定义代码插入到 Hasura 管理的数据库中，以及在哪里插入。

操作 Hasura 公开自定义 GraphQL 突变或查询，由您用您选择的语言编写的 HTTP Webhook 支持。 Hasura 根据声明的架构验证输入，调用您的 webhook，然后将其响应返回给客户端。它是通往 CRUD 以外任何逻辑的门户：调用支付提供商、复杂计算、多步骤编排。

事件触发器 遵循相反的方向：表上的插入、更新或删除会异步触发 Webhook，并在发生故障时自动重新启动。这是大多数 Hasura 集成用于同步第三方服务（计费、事务电子邮件、搜索引擎）的机制，无需将此代码与初始客户请求耦合。

Hasura 还可以将已经编写的 GraphQL 查询公开为典型的 REST 路由，并带有命名路径和参数——用其自己文档的术语来说，它的 RESTified端点。如果您的前端团队更喜欢使用 REST，而不放弃底层 GraphQL 权限引擎，则非常有用。

上下文提醒，在我们的专门文章中提出：自 2025 年 6 月以来，Hasura 已将其通信重新集中在 PromptQL（一个为 AI 代理设计的层）上，但没有删除其 GraphQL 引擎，该引擎在其官方网站上仍然显示为“经过实战测试”。

根据定义，手写 API 没有任何限制：任何业务逻辑、任何语言、任何依赖项。它也是三个选项中唯一一个不为您生成任何内容的选项 - 每个路由、每个验证、每个数据库连接都是您拥有且必须维护的代码。

// 过滤、排序和关系嵌入都是手工编写的，
// 仅针对此路线 — 对每个 API 资源重复
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

该模型所提供的，以换取手动工作：完全控制错误和返回的 HTTP 代码、经典的可测试性（处理程序，而不是声明性配置），并且对于已经掌握其语言的团队来说，无需学习新的 DSL。

作为交换，它的成本是：为每个资源手动编写和维护 CRUD、分页和过滤器；身份验证和授权自行实施和审计，无需自动继承RLS；如果每个嵌套关系无规律地触发自己的 Postgres 查询，则存在 N+1 查询的风险；和 API 文档需要手动维护，或者通过第三方生成器进行集成。

在原始性能方面，“Node.js 比 Rust 慢吗”这个问题本身就是一个主题——我们关于 Rust 与 Node.js 延迟 的文章详细介绍了这个问题，并在我们的 基准测试方法页面上游声明了方法。自定义 API 与您已经使用的任何 HTTP 服务具有相同的性能配置文件，不会因为构造而变得更好或更差。要准确了解 PostgREST 在何处饱和以及何时需要自定义层，请参阅我们关于 PostgREST 在生产中的真正限制的文章。

除了架构之外，选择时最常出现的四个标准：实施速度、实际业务灵活性、长期技术债务以及每个选项最舒适的典型用例。

在 Aurabase Postgres 引擎项目中，CRUD 层已被实际的 PostgREST 实例覆盖，而不是近似的重新实现。对于这种比较，仍然存在一个问题：在哪里编写超出 CRUD 范围的内容？

存在两条路径，并且它们并不相互排斥。第一个：在 RPC 中公开的 SQL 函数，用于在 SQL 中合理表达的任何逻辑 — 计算总数、多个表之间的交叉验证、单个事务中的级联更新。

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

第二种方式：Edge Functions，适用于 SQL 域之外的所有内容 — 调用支付 API、发送电子邮件、计算嵌入。 Aurabase 有两条路径：Studio 编辑器，它运行与 Supabase 完全相同的 Deno (TypeScript) 代码；以及 aura functions deployCLI，它的目标是为用 Rust 编写并在 WASM 中编译的函数提供单独的路径——详细信息请参见我们的 统一 Rust 架构。这两种路径都不需要托管单独的 Node 服务器，这与本文中的纯“自定义 API”选项不同，该服务器完全由您负责。

这种分布并不是这里比较的三个模型之间不稳定的妥协：它实际上是用于 CRUD 的 PostgREST，是一个接近 Hasura Actions 的砖块，用于通过 RPC 和触发器进行事件逻辑，以及避免完整应用程序服务器操作的 Edge Functions - 无需强制在“所有 PostgREST”和“所有自定义”之间进行二元选择。

最常出现四种情况。正确的选择主要取决于您的业务逻辑需要什么，而不是工具的受欢迎程度。

• 您的架构是稳定的，您的业务逻辑是在 SQL 中。 自托管 PostgREST 或本机集成（Aurabase、Supabase）就足够了：无需再托管，模式仍然是唯一的事实来源。
• 您想要整合多个数据源，或者您的路线图适合人工智能代理使用您的数据。 Hasura 及其 PromptQL 层更适合这种地形。
• 您的产品具有丰富的业务逻辑、众多的第三方集成以及已经配备应用语言的团队。 自定义 API 仍然是最直接的选择，但代价是随着时间的推移编写和维护它。
• 您想要自行生成 CRUD，而又不放弃业务逻辑（RPC、边缘函数）的实际空间，也不希望再堆叠一项应用程序服务来利用。 这是上一节中应用于 Aurabase 的比较中记录的角度。