Nhost
以 PostgreSQL 与即时 GraphQL API 为核心的开源应用后端平台。
项目概述
Nhost 将 PostgreSQL、Hasura GraphQL、认证、文件存储和 Serverless Functions 组合为一套开源后端，可使用托管服务、本地开发环境或自行托管。
Nhost 是以 PostgreSQL 和 GraphQL 为中心的开源 Backend-as-a-Service。每个项目拥有 PostgreSQL 数据库，并由 Hasura GraphQL Engine 为数据表、关系和函数生成 Query、Mutation 与实时 Subscription；Nhost Auth 负责用户、会话、JWT 与登录方式，Storage 负责受权限控制的文件，Serverless Functions 与 Nhost Run 则承载自定义服务端逻辑。平台既提供 Nhost Cloud，也可通过 CLI 在 Docker 中启动接近云端的完整技术栈，并用数据库迁移、Hasura Metadata 和配置文件管理环境。它特别适合偏好 SQL 数据模型、GraphQL API 和声明式角色权限，又希望减少通用后端样板代码的团队。
主要特点
Nhost 把关系数据库、即时 GraphQL、身份、文件和自定义计算放入同一套角色与 JWT 权限体系，并提供可版本化的本地开发流程。
专属 PostgreSQL 数据库
每个项目以标准 PostgreSQL 为数据核心，可使用关系、事务、SQL、函数、触发器以及 pgvector、PostGIS 等扩展。
即时实时 GraphQL API
Hasura 根据数据库 Schema 自动生成 Query、Mutation 和 Subscription，无需为常规 CRUD 手写 Resolver。
行列级角色权限
可按角色、操作、行过滤条件和列定义访问规则，并用 JWT 中的用户 ID、角色及自定义 Session Variable 实现多租户授权。
完整身份认证
Nhost Auth 提供邮箱密码、无密码、OAuth、MFA、WebAuthn、会话刷新和用户角色，并将身份声明传递给 GraphQL 与 Storage。
权限感知的文件存储
Storage 提供上传、下载、处理和文件元数据，并复用用户 JWT 与 GraphQL 权限控制公开或私有文件。
Functions 与自定义服务
Serverless Functions 适合 Webhook 和轻量业务逻辑，Nhost Run 可部署带资源、网络、环境变量及持久磁盘配置的容器化服务。
完整本地开发环境
CLI 通过 Docker 启动 PostgreSQL、GraphQL、Auth、Storage、Functions 和 Mailhog，使身份、权限、邮件及文件流程都能在本地验证。
迁移与 Metadata 工作流
数据库 Schema 以 SQL Migration 管理，GraphQL 权限、关系、事件和远程 Schema 以 Hasura Metadata 管理，适合提交代码审查并同步环境。
适用场景
适合以关系数据和 GraphQL 为中心的 Web、移动及 SaaS 产品，也适合希望保留开源与自托管路径的团队。
GraphQL 优先的 Web 应用
前端可使用 Nhost SDK、Apollo、urql 或其他客户端访问统一 GraphQL Schema，并通过 Subscription 接收实时变化。
多租户 SaaS
以组织、成员和角色建模租户，再用 JWT Session Variable 与行列权限隔离数据和操作。
实时协作产品
GraphQL Subscription 与数据库事件可支持消息、通知、任务状态、运营看板和轻量协作体验。
会员与内容平台
Auth、PostgreSQL 和 Storage 可组合账户体系、文章、媒体、附件和按角色开放的管理功能。
移动与跨平台应用
JavaScript/TypeScript 与 Dart/Flutter 客户端可共享认证、数据和文件服务，减少多端后端适配工作。
AI 与搜索应用
PostgreSQL 扩展、关系数据、GraphQL 和自定义服务可组合向量检索、元数据过滤及异步内容处理。
优点与注意事项
技术选型不仅要看能力，也要理解它带来的团队成本。
主要优点
Nhost 擅长的地方
- 以标准 PostgreSQL 为核心，可复用 SQL、关系建模和数据库生态
- 自动生成 GraphQL Query、Mutation 与 Subscription，减少 CRUD 样板代码
- Auth、GraphQL 与 Storage 共享 JWT 和角色上下文，权限模型较统一
- SQL Migration、Hasura Metadata 和配置文件适合版本控制与团队审查
- CLI 可在本地运行完整技术栈，便于测试认证、邮件、权限与文件流程
- Nhost Cloud、开源组件和自托管方案提供不同程度的运维与数据控制
需要注意
采用前应考虑的问题
自动生成 API 后，未配置或过宽的匿名、用户行列权限可能暴露数据。每个角色、表、操作、关系和聚合都应按拒绝优先原则测试。
Hasura Admin Secret 会绕过普通角色权限，不能进入浏览器、移动客户端、日志或公开仓库；服务端也应优先使用最小权限身份。
索引、约束、事务、查询计划、分页和关系基数仍决定性能与一致性，复杂查询应通过 Explain 和真实数据量验证。
相比单二进制后端，本地和自托管需要 Docker、PostgreSQL、GraphQL、Auth、Storage、邮件与函数等组件，升级和故障定位更复杂。
只在 Dashboard 手工修改会导致环境漂移；Schema、关系、权限、事件和 Seed 应纳入可回放、可审查的交付流程。
大型应用通常还要引入 Fragment、缓存策略、错误处理、代码生成、Schema 演进和 Subscription 生命周期管理。
团队需自行承担 TLS、邮件、对象存储、监控、备份恢复、资源扩展、组件升级与安全补丁；自托管并不等于低成本。
数据库计算、存储、网络、函数和实时连接都会影响容量与费用，生产前应核对区域、配额、备份策略和峰值负载。
快速开始
先使用 CLI 启动本地完整技术栈，再安装 JavaScript SDK，完成注册、GraphQL 数据读取和文件上传。
bashnpm install --save-dev @nhost/cli
npx nhost login
mkdir nhost-demo && cd nhost-demo
npx nhost init
npx nhost upbashnpm install @nhost/nhost-jstypescriptimport { createClient } from "@nhost/nhost-js";
export const nhost = createClient({
subdomain: import.meta.env.VITE_NHOST_SUBDOMAIN,
region: import.meta.env.VITE_NHOST_REGION,
});typescriptimport { nhost } from "./nhost";
const response = await nhost.auth.signUpEmailPassword({
email: "reader@example.com",
password: "replace-with-a-strong-password",
});
console.log(response.body.session?.user.id);typescriptimport { nhost } from "./nhost";
type TodosResult = {
todos: Array<{
id: string;
title: string;
completed: boolean;
}>;
};
const response = await nhost.graphql.request<TodosResult>({
query: `query GetTodos($completed: Boolean!) {
todos(
where: { completed: { _eq: $completed } }
order_by: { created_at: desc }
) {
id
title
completed
}
}`,
variables: { completed: false },
});
console.log(response.body.data?.todos);typescriptimport { nhost } from "./nhost";
const file = new File(["hello Nhost"], "hello.txt", {
type: "text/plain",
});
const response = await nhost.storage.uploadFiles({
"file[]": [file],
});
console.log(response.body.processedFiles);bash# 在本地 Dashboard 修改表、关系和权限后
git add nhost/migrations nhost/metadata nhost/nhost.toml
git diff --cached
git commit -m "add todos schema and permissions"下一步：示例使用当前 SDK 的 createClient 与细分方法。生产环境必须先为匿名和用户角色配置行、列与操作权限；Hasura Admin Secret、数据库连接串和高权限服务凭证只能留在可信服务端。
类似项目
这些平台同样提供数据库、认证、存储和服务端计算，但在 API 风格、权限边界、数据库模型与部署复杂度上不同。
Nhost vs Supabase
Nhost 和 Supabase 都以 PostgreSQL 为核心，提供开源的认证、存储、函数、本地开发和云托管体验。两者最明显的分界是数据 API 与授权方式：Nhost 以 Hasura GraphQL 和角色行列权限为中心，Supabase 更强调 PostgREST、数据库客户端和 PostgreSQL RLS。
| 比较维度 | Nhost | Supabase |
|---|---|---|
| 核心数据库 | 专属 PostgreSQL，支持关系、SQL 与扩展 | 完整 PostgreSQL，支持关系、SQL 与扩展 |
| 主要数据 API | Hasura 自动生成 GraphQL Query、Mutation、Subscription | PostgREST 与客户端 Query Builder，也可组合 GraphQL |
| 访问控制 | Hasura 角色、行过滤、列权限和 Session Variable | PostgreSQL RLS、Role、Grant 与 auth.uid() |
| 实时模型 | GraphQL Subscription 与数据库事件 | Broadcast、Presence 与 Postgres Changes |
| 服务端扩展 | Serverless Functions、Nhost Run、Remote Schema 与 Event | Edge Functions、数据库函数、Hook 与独立服务 |
| 本地配置资产 | SQL Migration、Hasura Metadata 与 nhost.toml | SQL Migration、Seed、配置与生成类型 |
| 客户端取向 | GraphQL 生态，适合 Apollo、urql 与代码生成 | Supabase SDK 与 SQL 风格 Query Builder 更直接 |
| 更适合 | GraphQL 优先、复杂关系查询和声明式角色权限 | SQL/RLS 优先、直接数据访问和更广的 Postgres 工具链 |
如果团队已经采用 GraphQL，希望自动获得类型化关系查询、Mutation、Subscription，并愿意系统管理 Hasura Metadata，Nhost 的整体体验更一致；如果团队更熟悉 PostgreSQL RLS、SQL 和链式数据客户端，或希望以数据库能力为主要扩展面，Supabase 通常更自然。最终应使用真实 Schema 对权限表达力、复杂查询、实时负载、本地工作流和托管成本做一次小型验证。
资料核验
版本、维护信息与本页采用的官方资料来源。
本页依据 Nhost 官方 Docs、CLI 本地开发文档、JavaScript SDK API 与官方源码仓库整理。组件版本来自 Nhost 官方 GitHub Releases；功能、命令和代码示例按当前官方文档核对。
官方仓库未归档，核验时最近可见的代码活动日期为 2026 年 7 月 24 日。该状态表示项目近期仍有公开维护活动，不代表固定发布频率或长期支持承诺。