选择接入数据库
数据墙DBW 支持三种关系型数据库：SQL Server、PostgreSQL 和 MySQL。三者在基本的 REST 数据操作上表现一致，但在 GraphQL 高级特性和数据库对象类型上存在差异。选择一个数据库时，既要考虑已有系统的技术栈，也要关注功能支持的完整度。
支持概览
| 数据库 | 最低版本 | REST CRUD | GraphQL 基本操作 | 聚合 | 多重变更 | 视图 | 存储过程 |
|---|---|---|---|---|---|---|---|
| SQL Server | 2016 | 全部 | 全部 | 支持 | 支持 | 支持 | 支持 |
| PostgreSQL | 11 | 全部 | 全部 | 不支持 | 不支持 | 支持 | 支持 |
| MySQL | 8 | 全部 | 全部 | 不支持 | 不支持 | 支持 | 支持 |
三种数据库在 REST、GraphQL、视图、存储过程、关系、字段映射、缓存、健康检查和 MCP 工具方面全部支持。主要差异在于 GraphQL 聚合查询和多重变更仅 SQL Server 支持。
按功能选择
如果你的需求是全功能
选择 SQL Server。它是三个数据库中能力最完整的：
- 支持 GraphQL 聚合查询（
count、sum、avg等）和多重变更。 - 支持视图和存储过程作为 API 实体。
- 支持会话上下文，可将 JWT 声明注入数据库查询，配合行级安全策略使用。
- 支持
autoentities自动实体发现，按模式匹配批量公开数据库对象。
如果你的应用需要服务端聚合统计、需要暴露已有存储过程、或需要细粒度的声明注入，SQL Server 是最佳选择。
如果你的技术栈在 PostgreSQL 上
选择 PostgreSQL。它在基础能力上与 SQL Server 持平：
- REST CRUD、筛选、排序、分页、字段选择全部支持。
- GraphQL 基本的查询和变更支持完整。
- 支持视图和存储过程作为 API 实体。
- 安全方面支持实体权限、字段过滤和数据库策略。
主要差异在于不支持 GraphQL 聚合和多重变更。如果你的场景以 REST 为主，或 GraphQL 使用场景为基础查询和变更，PostgreSQL 的表现和 SQL Server 没有明显差距。
如果你在 MySQL 环境下
选择 MySQL。它覆盖了最常见的需求：
- REST CRUD、查询参数全部可用。
- GraphQL 基本查询和变更支持完整。
- 支持视图和存储过程作为 API 实体。
- 安全方面支持实体权限、字段过滤和数据库策略。
如果主要使用表作为数据来源，MySQL 完全可以胜任。需要视图或存储过程暴露时同样可用。
按数据库对象选择
选择数据库时，也需要考虑你打算暴露哪些类型的数据库对象：
| 数据库对象 | SQL Server | PostgreSQL | MySQL |
|---|---|---|---|
| 表 | 支持 | 支持 | 支持 |
| 视图 | 支持 | 支持 | 支持 |
| 存储过程 | 支持 | 支持 | 支持 |
三种数据库均支持表、视图和存储过程作为 API 实体。
安全能力对比
| 安全能力 | SQL Server | PostgreSQL | MySQL |
|---|---|---|---|
| 实体权限（角色 + 操作） | 支持 | 支持 | 支持 |
| 字段级访问控制 | 支持 | 支持 | 支持 |
| 数据库策略（行级过滤） | 支持 | 支持 | 支持 |
| 会话上下文（声明注入） | 支持 | 不支持 | 不支持 |
实体权限、字段控制和数据库策略三种数据库全部支持。会话上下文是 SQL Server 独有的能力——它能将 JWT 令牌中的声明自动传入数据库会话，在行级安全策略中通过 @claims 引用用户属性，实现声明驱动的数据过滤。
选择建议
| 你的情况 | 推荐 |
|---|---|
| 新项目，无历史负担，需要全部功能 | SQL Server |
| 已有 PostgreSQL 基础设施，功能需求集中在 REST | PostgreSQL |
| 已有 MySQL 数据库，以 REST + 基础 GraphQL 为主 | MySQL |
| 需要 GraphQL 聚合统计 | SQL Server |
| 需要 GraphQL 多重变更 | SQL Server |
| 需要会话上下文配合行级安全 | SQL Server |
无论选择哪个数据库，数据墙DBW 都提供统一的配置方式和 API 形态。从开发到生产，操作体验一致。