Hasura 替代方案：PostGraphile、Supabase 与 Directus 自动生成 API 怎么选

先从一个很常见的场面说起。

一个三个人的小团队，两年前接手公司内部的一套运营看板。数据库是 Postgres，表不多，二十来张。他们用 Hasura 起了服务，把表接进去，行级权限在控制台里点几下，前端当天就拿到了能查能改的 GraphQL 接口。原本要写两周的 CRUD，一个下午就没了，那种轻松感很具体。

两年过去，事情慢慢变味。看板接进了 Mongo 里的埋点数据，报表又要读 ClickHouse。Hasura 的主线走到 DDN，连接器变多了，计费单位从实例换成了活跃模型，免费档只留给一个开发者。团队算了算自己那些表、视图、远程 schema 合起来算多少个模型，再算上要重新学一遍 metadata 的写法，心里开始打鼓。

他们并没有否定 Hasura。他们只是到了一个节点，需要重新问一遍：自动生成 API 这件事，到底该由谁来承担。

自动生成 API，省掉的究竟是哪一段活

这类工具之所以好用，是因为它们把三件本来要手写的事挪走了。

第一件是 schema 反射。你建表，它读表，字段类型、外键关系、可空性都从数据库里拎出来，变成一套类型安全的接口。第二件是查询拼装。前端要“订单连同客户和客户所在城市”，你不用写 join，工具按请求的形状去拼 SQL，顺便解决 N+1。第三件是权限判定。谁能读哪一行、能改哪一列，通常有一个统一的声明位置，而不是散落在几十个 handler 里。

真正让这四个工具分道扬镳的，是第三件事落在哪里。有的把权限写成自己的 metadata，有的直接沿用数据库角色和行级安全策略，有的在做一层独立的 RBAC。这个差别平时看不出来，等你接手别人的项目、或者半夜被叫起来排查一个“为什么他能看到别人的数据”时，会变得非常刺眼。

还有一个容易被忽略的变量：这套东西由谁运维。托管服务替你挡掉升级、备份、连接池；自托管把控制权还给你，也把值班表还给你。

所以下面的表不打分。它只是把四个工具放在同一组坐标上，让你看清自己更怕哪一种麻烦。

工具	部署方式	开源协议	数据库	API 形态	权限写在哪	起步成本
Hasura	自托管（Docker 等）或 DDN 云	Apache-2.0	v2 以 Postgres 为主；DDN 另接 MongoDB、ClickHouse、MS SQL Server	GraphQL 为主，可把保存的查询暴露成 RESTified 接口	自己的 metadata：角色加行级、列级权限	自托管免费；DDN Base 从 $5/活跃模型/月起
PostGraphile	只能自托管，跑成 CLI、Node 中间件或独立 schema	MIT	仅 Postgres	仅 GraphQL	Postgres 角色、RLS 与授权	软件免费，成本是服务器和人力
Supabase	托管为主，官方另有自托管方案	Apache-2.0	仅 Postgres	REST（PostgREST）加 GraphQL（pg_graphql）	Postgres 的 RLS、角色与授权	免费档；Pro 从 $25/月起
Directus	自托管或 Directus Cloud	源码可见，Monospace 自有许可，非 OSI 开源	Postgres、MySQL/MariaDB、Oracle、SQL Server、SQLite、CockroachDB	REST 为主，另有 GraphQL	自带 RBAC：角色加策略，细到字段	自托管可免费；云托管 Core 从 $89/月起

看完这张表，多数人的第一反应是“那选数据库支持最全的”。这个反应通常会后悔。数据库支持面宽，只在你要同时接三种存量库时才算优势；其余时候，它只是多了一堆你永远不会打开的适配器。

第二容易看错的，是把“有 GraphQL”当成同类项。四个工具都能吐出一套 schema，可 schema 的来路不一样：Hasura 的 schema 是从 metadata 编出来的，你能改的东西在 metadata 里；PostGraphile 和 Supabase 的 schema 是从数据库反射出来的，你能改的东西在 SQL 里；Directus 的 schema 一半来自数据库，一半来自 Studio 里点出来的配置。这个差别决定了你以后改一个字段要动几个地方，也决定了新同事上手时该先读哪份文件。

Hasura：纵深最深，也最需要你跟着它走

说一个做 SaaS 后台的五人团队。产品是多租户的，同一张 orders 表里躺着几十家客户的数据，每个登录用户只该看见自己那一家。销售主管还要能看下属的订单，普通销售只能看自己跟进的。财务能改金额，运营不能。

这种权限在 Hasura 里是配置题。角色、行级过滤条件、可写列的集合，都在 metadata 里声明，身份信息从 JWT 或 webhook 传进来的 session variable 里取。写完一版，整个 API 面都受这套规则约束，新增字段时不会漏掉某个手写的接口。行级和列级权限同时支持，加上它处理表关系和多层嵌套查询的能力，这是它到今天仍然最难被替代的地方。

它也能出 REST。v2 里有 RESTified endpoints，把保存好的查询和 mutation 挂到一个 URL 模板上，还能导出 OpenAPI 描述。这不是完整的 REST 框架，但对“要给第三方开两个固定接口”的场景够用。

代价在于绑定。metadata 是 Hasura 自己的方言，权限逻辑写进去之后，你很难把它原样搬到别处。v2 到 v3 是一次架构换代，连接器、supergraph、构建流程都换了说法，老项目不会被强制迁，可新特性和新连接器只往新架构上长。计费也跟着架构变了：DDN Free 是 $0，但只有一名 supergraph 开发者；Base 从每个活跃模型每月 $5 起。模型数量一多，账单会长得比请求量快。

所以留在 Hasura 的理由，基本可以归纳成一句：你的权限复杂度已经高到“重写一遍”比“付钱”更贵。

PostGraphile：把权限写进数据库的人会松一口气

另一个三人团队，负责内部数据看板，负责人是 DBA 出身。他们的习惯是权限只认数据库：谁是 analyst，谁能读哪张表，哪一行属于哪个区域，全在 Postgres 里用角色和 RLS 写清楚。任何在应用层再复制一份权限表的方案，他们都不太愿意接受。

PostGraphile 正好顺着这个习惯。它读 Postgres 的 schema，把表、视图、函数、外键关系反射成 GraphQL，权限则直接沿用数据库里已有的角色和 RLS。用户登录后，你把身份塞进 pgSettings，后面每条 SQL 都在那个角色的上下文里跑。规则只有一份，用 psql 连进去看到的和 API 看到的是同一套。

它对 SQL 的尊重还体现在别处。函数可以直接变成 mutation，复杂的业务逻辑可以留在数据库函数里；smart tags 让你在注释里标注哪些表暴露、哪些字段改名；最实用的是 export，能把生成的 schema 导成可执行的 JavaScript，之后你完全可以自己维护，官方文档把这叫“没有锁定”。

它的性能口碑来自执行方式。传统 GraphQL 服务靠 DataLoader 一层层攒请求，表一多就变成一串串小查询；PostGraphile 走的是另一条路，把整棵查询树编译成一条或少数几条 SQL，让数据库自己去优化。官方文档对这件事的说法很直接，大意是用常规写法很难做到同样的速度。对读多写少的后台系统，这个差别在数据量上来之后才显形，前期感觉不到。

不顺的地方也很清楚。它只认 Postgres，接第二种数据库没有官方办法。它只出 GraphQL，要 REST 得自己在前面套一层。它没有官方托管服务，进程、连接池、升级、监控都得自己管。v5 换了执行引擎，速度快了很多，插件还在陆续迁移，官方文档里就写着 PostGIS 尚未移植到 v5。还有一个细节常被忽略：schema 是从数据库实时反射的，改表结构不用重新生成代码，可这也意味着权限一旦写错，接口会立刻跟着错，没有一层中间代码替你兜着。

选它等于选了一种工作方式：你愿意把数据库当成产品的核心资产，并且团队里有人能读懂执行计划。

Supabase：买的不是 API，是一整套后端

还有两个人做小程序后端的场景。他们需要登录、头像上传、消息推送，还需要一个能直接查的接口。这个规模下，单独搭一套 API 层再单独接一个认证服务，纯属给自己找活。

Supabase 的定位就在这里。一个项目开出来，Postgres 有了，Auth 有了，对象存储和实时订阅也有了。接口一层是现成的：PostgREST 把表直接映射成 REST，pg_graphql 扩展再把同一套 schema 映射成 GraphQL，两个端点共用同一份数据库权限。你在 SQL 里写 RLS 策略，REST 和 GraphQL 同时生效，匿名用户、登录用户、service role 各走各的角色。

它的权限模型和 PostGraphile 同源，都是“数据库说了算”，区别在于 Supabase 把周边的脚手架一起给了你。代价是这套脚手架也把你往它的形态上带：数据库只能是 Postgres，自托管虽然官方有方案，但要自己维护一串容器，遇到问题时的排查面比托管大得多。免费档的限制也要提前知道，500MB 数据库、最多两个活跃项目、一周不动会被暂停；Pro 从 $25/月起，含 8GB 磁盘和一个 Micro 实例的额度，多开项目要另算计算资源。GraphQL 是扩展层，pg_graphql 1.6 之后 introspection 默认关闭，接 GraphiQL 之前得先手动打开。

如果你的需求里有“登录”和“上传文件”，Supabase 往往比任何一个纯 API 工具都省事。如果这两样你都不需要，你就是在为一个用不上的后台付理解成本。

Directus：给不写代码的同事一个后台

最后是一个内容团队。六个人，运营要自己加字段、改文案、调排序，产品经理要能给不同角色开不同权限。开发只有一个人，他最不想做的事是每次运营想加个字段就发一次版。

Directus 解决的是这一层。它把现有数据库当真相源，在上面盖一个 Studio，运营在界面里改数据，开发在数据库里改结构，两边不打架。接口是附带的：REST 是主接口，GraphQL 也有，OpenAPI 描述能直接导出。权限是它自己的 RBAC，角色加策略，能细到某个字段能不能读、能不能写。数据库支持面是这四个里最宽的，Postgres、MySQL/MariaDB、Oracle、SQL Server、SQLite、CockroachDB 都行，这对那些数据库已经被历史决定的公司很实际。

有一个变化必须说清楚。Directus 的仓库现在用的是 Monospace 自己的 Sustainable Core License，不在 OSI 的开源许可名单里，源码可见、可改，但商用规模和功能挂钩。年营收 500 万美元以下、员工少于 50 人的组织可以申请 Open Innovation Grant，自托管免费；超出这个范围，或者要用 SSO，就得往上走，云托管 Core 从每年付费折算的 $89/月起，SSO 在 Core 档不提供。把它当“免费开源 CMS”评估的团队，通常会在半年后收到一封提醒邮件。

它适合的场景也很明确：需求的核心是“让人在界面上管理数据”，API 只是顺带要有的东西。如果核心是给前端供数，Studio 再漂亮也帮不上忙。

动手之前，先做一次两周的对照实验

看到这里，最危险的动作是直接把生产库接过去试。四个工具都能在半小时内跑起来，也都能在半小时内让你产生“这个更简单”的错觉。

比较靠谱的做法，是挑三张真实的表、两个真实的权限场景，在两个候选工具里各做一遍。三张表要包含一张主表、一张多对多关联表、一张带软删除的表；两个场景要包含一个行级过滤（比如只能看自己部门的数据）和一个列级限制（比如金额字段只有财务能读）。做完之后看三件事，比看功能列表有用得多。

第一件是权限怎么写。是写在一段 YAML 里，还是写成一个 SQL 策略，还是一个界面里的勾选。写完之后，找一个没参与过的人，让他判断“销售能不能改这个字段”，看他几分钟内能给出答案。

第二件是改结构时的返工量。加一列、改一个外键、把一个字段拆成两张表，各做一遍，记下需要同步修改的文件和界面。这一项最能拉开差距，也最容易被演示视频掩盖。

第三件是出错时的第一现场。故意把权限写错，看报错信息指向哪里：是 metadata 的哪一行，是哪个 SQL 策略，还是只有一句 500。第一现场清楚，以后每次排查都省半小时；第一现场含糊，团队会在半年内养成“先重启试试”的习惯。

那到底怎么选

把上面的东西压成几句可以直接用的话。

权限复杂、多租户、数据源还要继续增加，并且团队已经熟悉 Hasura 的 metadata，那就留在 Hasura。迁到别处意味着把整套权限重写一遍，重写的风险比账单更贵。真要上 DDN，先数清楚活跃模型有多少个，把月费算出来再决定，别等到第一个账单周期。

只有 Postgres，权限已经在 RLS 里，团队有人愿意看 SQL，选 PostGraphile。它给的是一种干净：一套权限、一份 schema、一个 Node 进程，出问题时你知道该看哪里。前提是你能接受没有托管服务。

需要登录、文件、实时订阅，团队小到没人愿意维护基础设施，选 Supabase。别把它当成 Hasura 的替代品去对比功能表，它卖的是整套后端，API 只是其中一层。

需求是让运营自己维护内容，字段和权限要频繁变，选 Directus。先确认自己的营收和人数落在许可的哪一档，再决定自托管还是云。

如果四个都不完全合适，还有一个折中的做法：把自动生成 API 用在一部分表上，把复杂的业务逻辑放在它旁边，用它的 remote schema 或者你自己的服务接起来。这类工具最擅长的始终是那些长得像 CRUD 的接口，硬让它承担领域逻辑，最后会变成一堆写在配置里的 if。

还有一个更朴素的判断标准，比任何功能对比都管用：这套东西半夜出问题时，你更愿意读 SQL，还是更愿意读一份 metadata。选那个你还能看懂的东西。迁移真正贵的部分在搬家之后的每一天，那天本身反而花不了多少时间。

延伸阅读

• Postman 替代品推荐：2026 年最好用的 5 个 API 开发工具
• API 开发工具怎么选：Insomnia vs Bruno vs Hoppscotch vs HTTPie，2026 谁更适合你？
• Kimi K3.1 Pro 上线那天，有人把 API 账单重新算了一遍

查看完整选型指南 →