低代码/无代码平台连接PostgreSQL：五款主流工具深度对比

做后台这几年，我隔三差五就会遇到同一类需求：运营或者业务部门说，PostgreSQL 里已经屯了一大堆订单、工单、客户数据，能不能做个页面，让我们自己去查、去筛、去改？开发一听就想拒绝，因为排期永远不够。这种时候，无代码/低代码平台就成了很多人眼里的救命稻草。

但市面上的宣传话术都太漂亮了，真正能不能用，我只看一个硬指标：它能不能直连你现有的外部数据库，而不是只能活在自带的存储里。如果只能操作平台内置的表，那对已经有大量存量数据的团队基本没有意义——没人愿意把核心业务库迁到一个新平台里当“二等公民”。

这篇文章里，我以 PostgreSQL 作为参照数据库，把 5 个我实际接触过的平台摊开聊：NocoDB、Budibase、Appsmith、Retool、Power Apps。它们在“支持外部数据库”这件事上都做到了，但接入路径、适用人群和隐藏成本，差距比想象中大得多。不是为了对比而对比，只是希望你在决定“要不要引入低代码”之前，先搞清楚自己买的到底是个表格工具，还是应用平台，还是企业管理全家桶。

1. 先弄清楚连库姿势：直连、网关、API 桥接，三种玩法差太多

很多人在选型时没有意识到，低代码平台连接外部数据库并不是一件“同样的事”。不同的接入方式决定了后期运维难度、查询性能，甚至字段类型能不能正确映射。

1.1 自带存储的“假支持”，和外部数据源是两码事

有一部分平台，比如偏业务应用类的工具，默认就会让你用它的内置数据库建表，等你要接 PostgreSQL 时才发现，核心数据在外库，平台业务逻辑在内库，两边同步还要靠定时任务或者 API 来回倒。

这不是说内置存储不好。Budibase 自带 CouchDB 风格的本地库，Power Apps 有 Dataverse，它们在原型和轻量数据场景下很顺手。但一个已经在 PostgreSQL 里跑了两三年的业务系统，里面的表结构、触发器、存储过程、外键关系是不可能整体搬到平台存储里的。真正决定项目能不能落地的，是这个平台是以“外部数据源”为第一公民，还是把它当附加功能。

判断方式很简单：去看它的数据源接入界面，是把 PostgreSQL 放在醒目的默认列表里，还是要你去第三方市场找连接器；是填完连接串就能用，还是需要额外安装一个网关代理。

1.2 我能看到的三种连库姿势

以我实际用过和观察到的现状，低代码平台连外部 PostgreSQL 基本是三种技术路径：

• 原生驱动直连：平台自己实现了数据库驱动，配置 Host、Port、数据库名、用户名、密码就能连上。这是体验最好的一种，NocoDB、Budibase、Appsmith 都属于这一类。查错也最容易，连接不上时直接看 PostgreSQL 侧的网络和认证日志就行。
• 本地数据网关：平台不直接访问你的数据库，而是要求你在内网装一个代理程序，由代理再去连数据库。典型代表是微软系平台里常见的数据网关。好处是数据库不需要暴露公网端口，坏处是多了一个必须时刻在线、需要维护的中间层，网关一挂，整个应用就废了。
• API 桥接/中间件模式：平台并没有原生 SQL 驱动，而是通过预先封装好的 REST API、连接器市场或者第三方服务来访问数据。这种方式灵活，但性能、字段类型保真度、分页查询能力都会打折，遇到复杂查询往往力不从心。

选型的时候，我通常优先推荐原生驱动直连的平台。不是因为别的，就因为在生产环境里，中间环节越少，故障定位越简单。

1.3 为什么拿 PostgreSQL 当试金石

你可能已经注意到，网上搜“低代码平台支持什么数据库”，出现频率最高的参照库就是 PostgreSQL。原因其实很现实：PostgreSQL 是很多公司自建业务库的主力，规模不小、功能也强，JSON、数组、窗口函数、分区表都有，连它都能顺畅兼容的平台，通常去连 MySQL、SQL Server 也没太大问题。反过来，如果一个平台连 PostgreSQL 都支持得磕磕绊绊，那它对外部数据库的支持能力基本可以打个问号。

所以本文虽然标题写着“不只 PostgreSQL”，本质上是借 PostgreSQL 这个大家最熟悉的标尺，去丈量 5 个平台的通用外部数据库接入能力。下面开始逐个拆。

2. 五个平台速览：别被“都支持 PostgreSQL”这句话骗了

在深入每个平台之前，先给你一张我在整理选型笔记时画的总览表。看起来它们都能连 PostgreSQL，但背后的产品形态完全不同。