5款支持PostgreSQL的无代码/低代码平台选型指南

当你带着 PostgreSQL 连接串去找低代码平台，对方却只能给你一个内置表格数据库，这种落差我太熟了。很多团队在选型无代码/低代码平台时，第一句话就是“能不能连我现有的 PostgreSQL？”因为公司数据早就住在 Postgres 里，不可能为了上一个工具把数据迁移到另一个黑盒。我这次挑了 5 个真正支持外部数据库、并且对 PostgreSQL 友好的无代码/低代码平台，按实际使用体验把它们挨个过了一遍。

这 5 个平台分别是我在不同项目里用过的：Retool、Appsmith、Budibase、NocoDB、Directus。它们都能直连外部 PostgreSQL，但侧重点完全不同：有的适合搭内部运营后台，有的适合把数据库变成业务人员也能维护的表格，有的干脆就是给你的数据库套一层后台管理页面。适合谁来读？如果你是运维、后端、产品经理，或者正在帮团队做技术选型，这篇能帮你少踩几个坑。

1. 为什么无代码平台连接外部数据库是个大问题

1.1 自带表格数据库 vs 外部数据库：数据住在哪里才是关键

很多无代码平台默认会给你一套“自带数据库”，界面长得像电子表格，拖一拖就能建表，看起来非常爽。但问题在于：一旦你把数据填进去，数据就住在平台的服务器上了。你想导出来、想迁移、想和现有的业务系统做关联，都会变得非常别扭。更麻烦的是，如果平台本身不支持外部连接，数据只能靠 CSV 手工导入导出，时间一长就变成了新的数据孤岛。

而支持外部数据库的低代码平台，本质上只做一件事：通过数据库驱动连到你的 PostgreSQL、MySQL、SQL Server 等数据源，应用层负责渲染界面和交互，数据仍然留在原数据库里。这意味着你现有的权限体系、备份策略、监控告警都能继续用，不用额外维护一套“平台数据副本”。我见过不少团队最初被自带表格吸引，半年后开始痛苦地写脚本同步数据到数仓，那时候才意识到：选平台其实就是选“数据的家住在哪里”。

1.2 选型前先回答三个问题：只读还是读写、数据量多大、谁来用

在开始对比各个平台之前，我建议你先想清楚三个问题，否则很容易被功能列表带偏。

第一个问题是“连接后是只读还是读写”。有些平台虽然能连 PostgreSQL，但写操作限制很多，比如只能更新单行、不支持事务、更新大字段容易超时。如果业务需要同时改多张表，选型时要特别确认平台对外键约束和事务的支持程度。

第二个问题是“数据量到底有多大”。我实测过，NocoDB 这类表格化工具在十万行以内体验很好，但一旦表里数据量到百万级，直接加载整张表会卡到怀疑人生。Retool 和 Appsmith 这类组件化平台则可以通过 SQL 分页、聚合、筛选来控制返回的数据量，你写什么 SQL 它执行什么，性能相对可控。

第三个问题是“最终使用的人是谁”。业务人员需要的界面是“一眼能看懂、能编辑、能筛选”，开发人员则更在意“能不能写 SQL、能不能拿到 API”。这三个问题对应的其实是同一个核心：你要的是给数据库做界面，还是用数据库做应用后台，还是把数据库表变成在线表格。选型方向从一开始就分叉了。

2. 5款能连 PostgreSQL 的常用平台，各自适合谁

2.1 Retool：适合做内部工具的数据库直连标杆

Retool 是我最早用的商业低代码平台，也是数据库直连体验最成熟的之一。它的数据源配置界面很干净，选择 PostgreSQL 后，把 host、port、database、user、password 填进去，测试连接通过后就可以在查询编辑器里直接写 SQL。

我印象最深的一点是它对“查询结果”和“UI 组件”的映射做得特别顺手。你写一句 SELECT * FROM orders WHERE status = {{status_filter.value}}，然后把结果绑到 Table 组件上，一个按状态筛选的订单管理页面就出来了。Retool 对 PostgreSQL 的版本兼容也做得比较好，我从 9.6 用到 15，基本没遇到驱动层面的问题，函数、触发器、视图都能正常调用。

不过 Retool 是商业产品，免费版限制多，自托管功能要企业版才解锁。如果你预算充足、追求效率，用它做内部运营后台很合适；但如果你想要一个完全可控、自己部署的开源方案，它就不是最优解了。

2.2 Appsmith：开源免费，适合有开发能力的团队自建

Appsmith 是我目前的主力工具，因为它开源，可以直接用 Docker 部署到内网，数据安全可控。连接 PostgreSQL 的方式和 Retool 类似，界面里选择数据源、填参数、测试连接，然后新建查询、写 SQL、绑定组件。

Appsmith 的杀手锏是“JS 表达式”能力。比如你要做一个带搜索条件的报表，可以在 SQL 里写 SELECT * FROM customers WHERE city = '{{city_input.text}}'，前端输入框的值会直接注入 SQL。它还支持在组件的事件里写 JavaScript，比如在按钮点击后调用多个查询、做条件判断、控制组件显隐，灵活度已经接近传统前后端开发。

当然，代价是学习曲线稍微陡一点。你需要理解“数据源—查询—组件绑定”这三层关系，还要会一点 JavaScript 基础知识。但一旦上手，你会觉得它比那些封闭的平台自由太多。适合有开发能力、想自建内部工具的团队。

2.3 Budibase：自动读取表结构，适合快速搭业务后台

Budibase 给我的感觉是“既有内置数据库，也能连外部数据源”。它支持 PostgreSQL、MySQL、SQL Server 等常见数据库，连接后可以自动识别表结构和字段关系，然后为外部表生成默认的列表、详情、创建页面。如果你只是想快速搭一个能录入、能查询的部门管理系统，它的效率非常高，基本不用怎么写 SQL。

但实际用下来，我对 Budibase 的复杂查询支持还是有些保留。比如 PostgreSQL 里带 JSON 字段的表，在 Budibase 的默认表单里可能渲染不出来，需要把数据提前处理成视图或额外字段。它的自动化流程设计器更适合“表单提交后发通知”这类业务场景，而不是复杂的数据处理。如果你需要的是一套“能看、能改数据”的内部系统，Budibase 上手很快；但如果是复杂业务逻辑，你可能还是得回到 Appsmith 这类更开发向的平台。

2.4 NocoDB：把 PostgreSQL 变成业务人员也能改的“表格”

NocoDB 的思路和前面几个不太一样。它连接到现有 PostgreSQL 后，会把每张表渲染成一个类似 Airtable 的在线表格界面，支持筛选、排序、分组、公式、关联记录。它的目标用户很明确：不关心 SQL 的业务人员，他们可以像操作 Excel 一样去维护 PostgreSQL 里的数据。

我用 NocoDB 给运营团队搭过一个客户信息维护后台，运营同学直接在线改字段，数据实时写回数据库，完全不需要经过开发。它还会自动生成 REST API，方便其他系统调用数据。不过要注意，NocoDB 对表的数据量比较敏感，表太大会卡，字段特别多的时候界面也会变慢。建议把大表做成视图，只暴露必要的字段，或者通过卡片视图分页展示。如果你们团队没有专职前端、又希望业务人员能直接维护数据库，NocoDB 是非常合适的选择。

2.5 Directus：不改数据库结构，直接生成 API 和管理后台

Directus 和 NocoDB 有一点像，但它更偏“后端服务”而不是“在线表格”。它连接 PostgreSQL 后，会扫描数据库结构，自动生成一整套 REST/GraphQL API，还附带一个可以定制的管理后台。也就是说，它几乎是“零侵入”地给你的已有数据库加了一层壳，数据库表结构基本不用改，业务人员用后台做增删改查，开发人员用 API 做前端对接。

我比较喜欢 Directus 的权限设计，角色权限可以精细到字段级别。比如某个角色只能看客户表里的姓名和电话，不能看金额字段，这在数据敏感的场景里很实用。缺点是部署需要 Node.js 和一定的配置经验，学习曲线比 NocoDB 陡一些。如果你们已经有一个相对规范的 PostgreSQL 库，想快速给他配一个后台和 API，Directus 是很贴合需求的方案。

3. 实操：在 Appsmith 中连接 PostgreSQL 并做一张只读报表

3.1 数据源配置：连接串拆开填，测试连接是关键

为了让这部分更容易复现，我用 Appsmith 来演示。假设你已经部署好 Appsmith，进入应用编辑页面后，左侧找到“数据源”图标，点击新建数据源，选择 PostgreSQL。

配置页会要求你填写这些字段：

• Host：数据库地址，比如 db.example.com
• Port：默认 5432
• Database：数据库名，比如 sales_analysis
• User：建议使用专用低代码账号，别用超级管理员
• Password：对应用户的密码
• SSL Mode：按需选择 Require 或 Disable

填完之后点击 Test Connection，如果显示成功，就说明网络、账号、权限都通。失败的话，九成是白名单、密码或者 SSL 配置的问题。这里特别提醒一句：连接参数最好分开填，不要图省事直接粘贴一个 JDBC 连接串，因为每个平台的解析方式可能不同，经常会把 sslmode 或 currentSchema 参数搞丢。

3.2 用 SQL 查询绑定表格组件，实现页面筛选

连上数据源后，新建一个查询，命名为 get_customers，在 SQL 编辑器里输入：

sql复制SELECT id, name, city, created_at::date AS created_date
FROM customers
WHERE city = '{{city_filter.text}}'
ORDER BY id DESC
LIMIT {{limit_select.selectedOptionValue}};

这段 SQL 里的双层大括号是 Appsmith 的绑定语法，city_filter 和 limit_select 是页面上两个组件的名字。运行时会把输入框里的值替换进去。接着从右侧组件库拖一个 Table 组件，把 Table Data 设置为 {{get_customers.data}}，再拖一个 Select 组件设置城市选项，再拖一个 Select 设置每页数量，最后把查询的 Run on page load 打开。

这样页面的逻辑就是：打开页面自动加载最新客户列表，切换城市或选择条数后重新执行查询。整个过程中没有写任何后端代码，但页面已经变成了一个真正的“数据库报表工具”。我一般还会在 Table 组件里开启分页和数据下载，方便业务导出现有数据。

3.3 连接失败排查：白名单、SSL 和权限三件套

实际踩坑最多的就是下面这几类问题，我整理成速查表：

排查时建议先用 psql 手动连接一遍，确认连接串本身没问题，再回平台填参数。这样能把问题隔离在“数据库端”还是“平台端”。我遇到过很多次，平台连接失败但 psql 能连上，最后发现是平台所在 VPC 和数据库不在同一个网络。这种情况不是连接参数的问题，而是部署架构的问题，最直接的解法是把 Appsmith 也部署到同一网络内。

4. 横向对比与选型建议

4.1 5款平台关键能力对比表

这张表主要是帮你快速定位：如果你想快速搭一个运营后台，Retool 和 Appsmith 最合适；如果想让业务人员直接改数据库，NocoDB 最直接；如果既要后台又要 API，Directus 最省事；如果需要一个包含表单、流程的部门系统，Budibase 效率更高。

4.2 按团队类型选择的四种组合

我之前帮几个团队做过选型，比较典型的组合有以下四种：

第一种是“已经有稳定 PostgreSQL，需要快速做内部运营后台”的团队。预算充足选 Retool，追求开源自建选 Appsmith。这两种都能直接帮开发者省去大量重复 CRUD 页面。

第二种是“希望业务人员维护数据库数据，但不想给数据库管理工具”的团队。NocoDB 非常合适，把表和视图配置成在线表格后，运营人员零门槛上手。

第三种是“已经有规范化的数据库，需要对外提供 API 和管理后台”的团队。Directus 是最贴合需求的，既不用改表结构，又能得到 REST/GraphQL API。

第四种是“什么都想试试，团队技术水平一般”的团队。Budibase 的上手体验最友好，适合先搭一个原型验证，等需求真正复杂了再迁移到更开发的平台。

另外，这几个平台都不只支持 PostgreSQL，MySQL、MariaDB、SQL Server、SQLite 甚至 MongoDB 大多也能连。我选型时非常在意这一点，因为这意味着后续数据库迁移时，应用层可以基本不改。低代码平台如果只能连自己的自带表格，等于把你锁死在里面；能连外部数据库的平台，才真正给你留了后路。

5. 我的踩坑记录：外部数据库连接中的“隐形坑”

5.1 最容易忽略的几个连接参数

很多人看到连接页面只需要填 host、port、user、password，就以为完事了。实际上，PostgreSQL 连接里还有几个参数，在低代码平台里经常被忽略。

第一个是 currentSchema。如果数据库里建了多个 schema，默认只连 public，你查不到其它 schema 下的表。有个项目里我们明明授权了，但 Appsmith 一直报“表不存在”，最后发现就是没指定 schema。

第二个是 ssl 和 sslmode。云数据库一般强制 SSL，如果平台的连接参数默认是 disable，就会报错。反过来，内网环境强制开着 SSL 又没配证书，也会连不上。

第三个是 socketTimeout。数据量大或查询慢的时候，如果超时时间太短，查询会被中途打断。遇到这种问题可以适当调大连接超时和空闲时间。

第四个是 prepareThreshold。这个参数对 JDBC 驱动影响很大，关系着预编译语句的复用。某些低代码平台默认可能设成 0，导致每个查询都重新生成执行计划，性能下降明显。如果发现平台查询明显比 psql 慢，优先检查这个参数。

5.2 数据库账号权限：别拿 superuser 去连低代码平台

我见过不少团队为了方便，直接用超级管理员账号去连低代码平台，结果业务人员在页面里不小心改错数据，连个审计日志都查不到。低代码平台生成的界面通常会把表的字段暴露出来，如果账号权限过大，风险会成倍放大。

建议为每个低代码平台单独创建一个数据库账号，只授予所需的最小权限。以只读场景为例，可以这样建：

sql复制CREATE ROLE nocodb_user LOGIN PASSWORD 'strong_password';
GRANT CONNECT ON DATABASE app_db TO nocodb_user;
GRANT USAGE ON SCHEMA public TO nocodb_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO nocodb_user;

如果需要写权限，再按需放开 INSERT、UPDATE、DELETE。以后要回收权限也很干净，直接 REVOKE 就行。另外，所有查询尽量用参数化方式，不要在 SQL 里拼接用户输入，避免注入风险。低代码平台虽然帮你省了后端代码，但数据库安全底线不能省。

我在实际项目里最后用的是 Appsmith 加 NocoDB 的组合：Appsmith 给开发做内部工具，NocoDB 给运营维护数据。如果你也在评估这些平台，先别急着对比功能表，把你们团队真正要解决的“数据入口”问题想清楚，再决定用哪种形态。每次踩过坑之后我都会发现，选工具最核心的标准不是“功能多”，而是“数据和逻辑都在自己手里”。