不通过后端服务器，利用 PostgREST 处理复杂的业务逻辑

PostgreSQL 如今已经不仅仅是一个简单的数据存储库了。在 2025 年 Stack Overflow 的调查中，它以 15% 的差距领先 MySQL 位居榜首，这并非偶然。在这个强大的数据库之上搭载 PostgREST，你就无需再用 Node.js 或 Python 去编写那些乏味的 CRUD API。然而，面对支付对接或复杂的权限设置，大家往往会犹豫，心中不免产生疑问：“这真的能在没有服务器的情况下实现吗？” 结论先行：完全可以。而且实现得非常优雅。

解决外部 API 对接中产生的响应延迟

在使用 PostgREST 时，最令人担心的部分是支付确认或发送邮件等外部 HTTP 调用。在数据库内部等待外部服务器响应是一个糟糕的想法。但是，如果你使用 pg_net 扩展模块，情况就大不一样了。这个基于 libcurl 运行的工具不会等待外部 API 的响应，而是采用异步方式发送请求。

在对接像 Toss Payments 这样的支付 API 时，这种方式大放异彩。主事务仅保存数据并立即结束，实际的 API 调用则在后台队列中处理。通过这种方式，无论外部服务器状态如何，都能将 API 响应时间控制在 200ms 以内。当你看到系统整体吞吐量提升 3 倍以上时，你可能会感叹：过去为什么要在 API 服务器上费那么大劲。

将校验逻辑迁移至数据库约束

核对库存并处理订单的复杂逻辑，通常在后端代码中通过 if-else 语句来解决。但这是数据污染的开始。相反，请尝试使用 pg_jsonschema。这个由 Rust 编写的扩展在 48ms 内即可完成 10 万件 JSON 模式匹配。

方法很明确：在表中添加 CHECK 约束或创建 BEFORE INSERT 触发器。如果条件不符，通过 RAISE EXCEPTION 抛出错误即可。此时，如果将 SQLSTATE 指定为 PT402，PostgREST 会自动向客户端发送 402 Payment Required 状态码。省下在后端编写校验代码所耗费的 5 小时，将其投入到更重要的数据建模中吧。

通过查询分析降低基础设施成本

在 PostgREST 中，客户端的 URL 参数会直接转化为查询。这虽然方便，但也存在风险。如果在没有索引的列上设置过滤器，性能地狱将立即降临。这时，pg_stat_statements 是必不可少的，因为它能实时展示哪些查询正在吞噬资源。

实际上，仅通过 EXPLAIN (ANALYZE, BUFFERS) 命令剖析执行计划，并将顺序扫描转换为索引扫描，性能就能提升 3 倍以上。云服务成本降低 30% 则是额外奖励。如果需要复杂计算，在 PostgreSQL 18 的虚拟生成列上创建索引也是一个好方法。

基于用户等级的动态访问控制

别再为了安全而在后端堆砌中间件了。PostgREST 100% 利用了 PostgreSQL 的行级安全性 (RLS)。通过 current_setting 函数读取 JWT 中携带的用户信息，即可在 SQL 层面控制权限。

“仅允许付费订阅者查看此文章”的策略，只需一条 CREATE POLICY 语句即可搞定。这从源头上杜绝了因开发者忘记在代码中调用权限检查函数而导致的数据泄露事故。对于修改密码等敏感操作，只需使用带有 SECURITY DEFINER 选项的函数进行封装。安全逻辑集中在数据库中，管理起来会方便得多。

减少部署错误的架构管理

在 PostgREST 架构中，架构（Schema）变更即意味着 API 更新。如果手动操作，必然会发生事故。务必使用 dbmate 等工具，将所有变更事项作为 .sql 文件进行管理。

如果在 GitHub Actions 中设置好流水线，每当推送代码时，变更都会自动反映到测试服务器上。迁移完成后，向 PostgREST 发送 SIGUSR1 信号或执行 NOTIFY pgrst, 'reload schema'。这样，API 就能在零停机的情况下更新至最新状态。即使是个人开发者，这也是获得企业级运营稳定性的最可靠方法。