PostgREST：把 PostgreSQL 数据库直接变成 REST API

**PostgREST 做的事一句话说清：连接你的 PostgreSQL，自动生成完整 REST API。**名为 todos 的表立刻暴露在 /todos 路径下，GET/POST/PATCH/DELETE 自动映射到对应 SQL——没有控制器、没有 ORM、没有路由定义。Supabase 的数据层就跑在它上面，生产级规模有验证。

它在解决什么问题

传统 API 开发里，给表加一个字段要改一串地方：数据库列定义、应用层 Model、校验层、控制器、API 文档。数据库本来就握着约束定义，却要在应用代码里重写一遍——重复定义带来维护负担，真相源（Source of Truth）被撕成两半。PostgREST 的思路是：数据库 Schema 就是唯一定义，其他全部自动生成。

工作原理

启动时读取数据库 Schema，把每张表和视图映射为 URL 路径，把 HTTP 请求直接翻译成 SQL：

• URL 参数 → WHERE、ORDER BY、列选择；
• 鉴权不用应用中间件，直接用 PostgreSQL 原生角色体系 + 行级安全（RLS）。每个请求以配置好的数据库角色执行，RLS 策略用 SQL 定义，决定哪些行可见、可写。

RLS 方案有个关键优势：无论请求来自 PostgREST、数据库直连还是分析工具，访问规则都由数据库统一强制执行——安全边界收进数据库，不存在"绕过中间件直连库"的漏洞。

十分钟跑起来

经典三件套（Docker Compose）：PostgreSQL + PostgREST + Swagger UI。初始化 SQL 建表后启动，即刻可用：

# 读全部
curl http://localhost:3000/todos

# 过滤：completed = true（eq 映射 SQL 的 =）
curl "http://localhost:3000/todos?completed=eq.true"

# 选列 + 排序
curl "http://localhost:3000/todos?select=title&order=created_at.desc"

# 新增
curl -X POST http://localhost:3000/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Learn PostgREST", "completed": false}'

# 更新 id=1
curl -X PATCH "http://localhost:3000/todos?id=eq.1" \
  -H "Content-Type: application/json" -d '{"completed": true}'

# 删除 id=4
curl -X DELETE "http://localhost:3000/todos?id=eq.4"

操作符全家桶：eq、neq、lt、gt、like、ilike、in、is 等，覆盖常用过滤。根路径还暴露 OpenAPI 规范，接上 Swagger UI（示例在 8080 端口）就有可交互的 API 文档，浏览器里直接"Try it out"。

什么时候适合用

适合：以结构化数据读写为核心的应用——原型验证、内部工具、管理后台、单页应用的 BFF 数据层。从建表到可用 API 以分钟计。

不适合：支付处理、第三方 API 编排、跨系统多步流程这类复杂业务逻辑。典型解法是混合架构：PostgREST 管直接数据访问，复杂流程交给一个薄微服务。

性能注意：RLS 策略在每次查询时求值，复杂策略会抬高数据库 CPU 消耗。过滤逻辑下沉到数据库后，索引和查询计划比在应用层过滤的架构更重要——上线前务必用 EXPLAIN 过一遍高频查询。

它背后的洞察

PostgREST 证明了一件事：大量所谓"后端代码"其实只是 HTTP 和 SQL 之间的翻译层。把翻译交给数据库直接完成，bug 的藏身面积缩小了，安全规则收拢到一处，从 Schema 到可用 API 的时间从周缩短到分钟。

观测云对照

API 上线只是开始，持续表现需要观测。用观测云**可用性监测（云拨测）**对 PostgREST 暴露的端点做定时探测，慢响应或 5xx 立刻告警；DataKit 采集 PostgreSQL 慢查询指标，定位"哪个 RLS 策略或缺索引的查询在拖后腿"；若前端是 Web 应用，RUM 能追踪真实用户侧 API 延迟。 1 2 3

常见问题（FAQ）

Q：PostgREST 安全吗？把数据库直接暴露成 API 不危险吗？
安全性取决于你的 RLS 策略和角色设计——PostgREST 不做鉴权绕过，它把每个请求约束在数据库角色的权限内。正确配置下，比"应用层鉴权 + 数据库全权账号"的传统模式边界更清晰。

Q：视图和函数也能暴露成 API 吗？
可以。视图映射为只读/可写端点（取决于定义），数据库存储过程可通过 /rpc/函数名 调用——复杂业务逻辑的推荐出口就是函数。

Q：性能比手写后端差吗？
PostgREST 本体开销很小（Haskell 实现），瓶颈通常在 SQL 本身。简单 CRUD 场景与手写后端相当甚至更优；复杂查询场景性能取决于你的索引和 SQL 质量。

Q：能在现有数据库上直接用吗？
可以，指向现有库即可。但建议先建一个专用 Schema 暴露给 API，配合角色和 RLS 把暴露面收窄到最小。

参考资料

• 观测云可用性监测（云拨测）
• 观测云 PostgreSQL 指标采集
• 观测云真实用户监控 RUM