前言
这两年，国内外围绕 PostgreSQL 做文章的产品越来越多。
有的在做云原生数据库，有的在做 Serverless Postgres，有的在做向量检索，有的在做 HTAP，有的则试图把 PostgreSQL 变成应用开发的后端底座。
前阵子看到瀚高发布 HigoBase，我其实一直挺好奇：一个国内数据库厂商来做类似 Supabase 的 BaaS 平台，到底会做成什么样？它是简单复刻一个开发者工具，还是能结合国产数据库、私有化交付和企业安全治理，走出一点自己的味道？
HigoBase 大致属于最后这一类。
它不是一个单纯的数据库管理工具，也不是把 PostgreSQL 套个控制台就完事。更准确地说，HigoBase 想做的是一个基于 HGDB/PostgreSQL 的 BaaS 平台。
BaaS，全称 Backend as a Service，后端即服务。这个概念并不新，Firebase 很早就在做。后来 Supabase 火起来，很大程度上是因为它把这件事放到了 PostgreSQL 之上，借助 PG 成熟的生态和可扩展能力，让开发者不只是拿到一台数据库，还能同时拿到认证、自动 API、实时订阅、对象存储、边缘函数等一整套后端能力。
HigoBase 的思路也类似。
BaaS 是什么？
过去我们做一个应用，数据库只是其中一块。
表要自己设计，接口要自己写，登录注册要自己接，权限要自己管，文件要自己存，实时推送要自己搭，日志和监控也要再找一套系统。
对大团队来说，这些事情都能做，无非是多几个模块、多几个服务、多一些规范。
但对很多中小团队、内部系统、AI 应用、原型项目来说，麻烦的是每次都要重新搞一遍。BaaS 这类平台的价值就在于此，把数据库周边那些高频后端能力收拢起来。
如果我们建一张表，它可以围绕这张表生成 API；要做权限，它可以把 PostgreSQL 的 RLS 策略放到产品界面里管理；要存文件，它也提供对象存储；你要补一点业务逻辑，可以用 Edge Functions；你要做实时数据同步，可以接 Realtime。
也就是说，它降低的不是数据库本身的门槛，而是从数据库走到可用后端的距离。
HigoBase Studio 把数据库、认证、对象存储、边缘函数、实时、日志、集成等入口放在同一个工作台里。
像 Supabase，但不只是 Supabase
聊 HigoBase，肯定绕不开现今 PostgreSQL 生态里面的当红炸子鸡 —— Supabase。
Supabase 的定位很清楚：开源的 Firebase 替代品，底层是 PostgreSQL，上层提供 Auth、Storage、Realtime、Edge Functions、Data API 等能力。
HigoBase 在产品形态上和 Supabase 有明显相似之处：
- 都以 PostgreSQL 体系作为核心数据层；
- 都强调建表之后自动生成 API；
- 都把认证、权限、存储、实时、函数放在一个工作台里；
- 都面向开发者，希望减少后端样板代码；
- 都在往 AI/Agent 友好的方向走。
所以，如果你熟悉 Supabase，理解 HigoBase 并不困难，如果只看产品入口和功能组合，HigoBase 很容易让人联想到 Supabase，但两者的出发点有点不太一样：
- Supabase 更像是一个全球开发者生态里的开源 BaaS 平台，重点是开发体验、开源社区、云服务和前端开发者友好。
- HigoBase 的差异点，则更偏向国产数据库底座、企业交付、私有化部署和信创环境，对国内更友好。
它背后依托的是瀚高自己的 HGDB/PostgreSQL 体系。对于很多国内企业来说，因为各种各样的因素，并不是所有场景都适合直接用海外云服务，也不是所有单位都能接受核心数据和后端能力跑在不可控的平台上，也就是说，HigoBase 想补出一套更适合国内企业使用的后端底座。
如果说 Supabase 解决的是开发者如何更快构建应用后端，那么 HigoBase 更关心的是：
在国产化、私有化、企业级交付场景下，能不能也拥有类似 Supabase 的开发体验？
这是我觉得 HigoBase 值得关注的地方。
官方发布时还强调了多模一体化和 AI 就绪混合负载，比如图、向量、全文检索、GIS、时序，以及面向 AI 客户端和 Agent 的 MCP Server。也就是说，它不只是想把后端模块打包到一起，还想把更多 AI 应用会用到的数据能力收拢到 HGDB/PostgreSQL 这套底座里。
效率、收敛、连接、治理
很多产品宣传 BaaS，容易落到一句话：提高开发效率。
这当然没错，但只说效率，其实不够。
在我看来，这类平台更重要的价值至少有四层。
第一层是开发效率。
CRUD、登录、文件、权限、实时推送，这些都是应用开发里的常见问题。平台能把它们标准化，确实能省掉不少重复劳动。
第二层是架构收敛。
以前这些能力可能散落在不同服务里，数据库归数据库，接口归接口，权限归权限，文件归文件。系统一复杂，治理成本就上来了。
如果这些能力都围绕数据库模型组织，开发者和 DBA 至少有一个共同的中心：数据结构、访问策略和后端接口不再完全割裂。
第三层是生态连接能力。
这一点我觉得容易被忽略。BaaS 平台如果只提供数据库、鉴权、存储、函数，那它更像是把常见后端模块打了一个包。但如果它进一步提供集成市场、插件、外部数据源连接、日志引流、Webhook、GraphQL、Cron、Queues 这类能力，它就不只是帮你把应用后端搭起来，而是在尝试成为一个后端能力的汇聚入口。
这也是我在 HigoBase 里比较感兴趣的一点。它的 Studio 里不仅有数据库、认证、对象存储、边缘函数、实时这些基础模块，也能看到集成相关能力，比如 Data API、Database Webhooks、GraphQL、Vault，以及一些面向外部系统和数据源的连接选项。这意味着数据库不再只是等着应用来访问，而是可以主动和外部系统、业务流程、AI 工具链发生连接，把数据库从一个孤立组件，变成企业内部系统和外部服务之间的连接点。
集成市场里可以看到 Data API、Database Webhooks、GraphQL、Vault，以及 Cron、Queues、外部数据源 Wrapper 等能力。
第四层才是治理能力。
企业真正关心的往往不是”能不能快速做出来”，而是做出来以后能不能管住。比如 API 暴露是否受控，权限是否可审计，日志是否可查，数据库对象是否有安全建议，扩展和角色是否清楚。
这一点上，HigoBase 不是只停留在 BaaS 常见的 Auth 层。它把一些更偏企业数据库的安全能力也放进来了：比如 JWT、OAuth2/OIDC、MFA 这类认证能力，和 PostgreSQL RLS 做集成；对象存储的访问权限也可以和数据库 RLS 策略挂钩；角色管理里强调最小权限和按需授权；网关层有统一鉴权、API 速率限制和跨域处理；企业版能力里还提到国密、三权分立、审计，旗舰版进一步强调细粒度审计。
这些东西对个人开发者来说可能没那么性感，但对企业场景很关键。因为企业不是只怕”做得慢”，更怕”做出来之后没人说得清谁能访问什么、谁改过什么、出了问题怎么查”。如果一个 BaaS 平台只解决开发效率，而不解决安全边界和审计问题，那它很难真正进入严肃生产环境。
角色管理页面体现的是另一类价值：不仅要让后端能力快速可用，还要让权限和连接状态可见、可管。
这也是 HigoBase 相比纯开发者玩具更值得看的地方。它不只是给你一个在线表格编辑器，而是把数据库、权限、日志、Advisor、插件/集成和部署放在了一个企业交付的语境里。
PostgreSQL 的边界正在变化
过去我们讲 PostgreSQL，往往是在讲数据库内核、SQL 能力、事务、索引、扩展、优化器、复制、高可用。
这些当然还是核心。
但今天的一个变化是：越来越多产品不再满足于”把 PostgreSQL 做成一台更好的数据库”，而是在问另一个问题：PostgreSQL 能不能成为应用后端的平台？
Supabase 是一个答案。Neon 是另一个答案。这两者都是 AI 类应用的后端承接者，现在 HigoBase 也在给出自己的答案。
它们的方向不同，但共同点是：PostgreSQL 正在从一个数据库，变成很多新型数据产品的底座。
这背后的原因其实也不复杂，PostgreSQL 足够开放，有扩展体系；足够成熟，有事务和 SQL；生态足够丰富，有开发者基础；同时又不像传统商业数据库那样封闭。
不知道各位读者是否有关注 DB-Engines 的排名趋势。最近几年 PostgreSQL 的势头非常明显，和 SQL Server 的差距已经越来越小，最新排名只相差 10 分左右，生态势能、扩展能力和开发者心智都在变强。对很多新应用，尤其是 AI 应用、Agent 应用和内部数据应用来说，PostgreSQL 正在成为一个越来越自然的默认底座。PostgreSQL 已经不再只是”开源数据库里的一个选择”，而是在不断逼近传统商业数据库长期占据的位置。
换句话说，过去 Oracle、MySQL、SQL Server 三足鼎立的叙事，正在被 PostgreSQL 改写，成为 AI 时代的事实标准。
所以在 AI 应用、Agent、内部工具、数据应用快速增长的背景下，大家自然会想：既然数据已经在 PostgreSQL 里，为什么不把 API、权限、实时、函数、插件集成这些能力也围绕它组织起来？进一步说，向量检索、知识图谱、全文检索、SQL 级模型调用这些能力，也会越来越自然地被拉到数据库附近。
HigoBase 看中的应该也是这个趋势。它不是要重新发明一个数据库，也不是只做一个漂亮的管理界面，而是试图把 HGDB/PostgreSQL 往应用后端、企业集成和 AI Agent 可调用的数据底座方向再推一层。
并非银弹
当然，BaaS 也不是银弹。
平台帮你生成 API，不代表你不需要理解数据模型；平台提供 RLS，不代表权限设计可以随便写；平台提供对象存储和函数，也不代表复杂业务系统可以不做架构设计。
尤其是企业级场景，默认配置是否合理、权限边界是否清楚、日志链路是否完整、和现有系统怎么集成、出了问题谁来兜底更为重要。
所以我更愿意把 HigoBase 看成一个值得观察的方向，而不是简单喊一句”颠覆后端开发”。
它的亮点在于：把 Supabase 这类开发体验，放到了国产数据库和企业交付语境里，对于国内环境更加友好。
当然现阶段我觉得也有一些待改进的地方：产品文档和界面里仍能看到一些 Supabase 生态命名痕迹；部分体验还需要更顺；AI 助手、日志、可观测性这些能力，也需要在真实项目里继续验证。
最后
如果只从数据库角度看，HigoBase 不是一个特别”内核向”的产品。
它关心的是在 AI 时代，当应用开发越来越快，AI Agent 越来越多，数据库能不能直接向上长出一套后端能力？
这件事，可能比单纯多一个数据库管理界面更重要。
因为未来很多应用未必需要从零搭一套后端。它们需要的是一个可信的数据底座，一个能快速暴露 API、管理权限、接入文件、支持实时、承载函数逻辑的平台。
从这个角度看，HigoBase 值得关注。
它不是要替代 PostgreSQL，而是想把 PostgreSQL/HGDB 推到更靠近应用的一层。
对于瀚高来说，这可能也是一个值得讲的新故事：数据库不只是基础软件，也可以成为 AI 时代应用后端的基础设施。
其次，国内数据库厂商做 BaaS 的特殊之处，它不只是服务前端开发者，也要面对政企客户、私有化环境、信创适配、安全审计和数据库治理。
这比”又发布了一个平台”，要有意思得多。
参考资料：
- HigoBase 官网：https://higobase.highgo.com/
- HigoBase 使用手册：https://higobase.highgo.com/manual.html
- 瀚高新闻《HigoBase重磅发布》：https://www.highgo.com/about/news
- Supabase Docs：https://supabase.com/docs
评论区按需加载，正文阅读不会被第三方服务拖慢。