不会把你的数据库上传到别人服务器的 Retool 替代品

我用过 Retool。我喜欢 Retool。如果你需要周二前建好内部工具且你团队已经懂 JavaScript，Retool 比市面上几乎任何东西都快。它赢得品类默认的地位。组件库真的好用，拖拽构建器快，你能在任何地方下到 JavaScript 意味着你从不会被无代码抽象在恰好错误的时候卡住。

但大多数 Retool 评测不显眼提的、而对特定团队最终最重要的事是：当你的用户在 Retool 应用里跑查询时，那个查询不是直接从他们浏览器到你的数据库。它从他们浏览器到 Retool 的服务器，再从 Retool 的服务器到你的数据库，再经 Retool 的服务器，再回到他们浏览器。Retool 坐在每次数据库交互的中间。你用户读的每行、跑的每个查询、应用的每个筛选——全部经过第三方拥有和运营的基建。

对很多团队，那没问题。真的没问题。如果你的数据库是非敏感分析数据的只读副本，或你在为已经信任 SaaS 供应商一切的团队建内部工具，经 Retool 服务器的数据流不是问题。Retool 是运营良好的公司，有严肃的安全姿态、SOC 2 合规、彻底审查过的企业客户。

但对于有生产数据库、合规要求（HIPAA、你自己的 SOC 2、GDPR 数据驻留约束）、气隙环境、或只是强烈制度性偏好不通过第三方路由数据库流量的团队——这是问题。而这是大多数「Retool 替代品」文章侧面框定的问题。它们谈开源。谈自托管。谈成本。它们很少直说实际的事：你的查询在流经别人的服务器，这里是怎么停止的。

这就是这篇文章关于的。

数据流问题

让我用文字画出来，因为架构比营销更重要。

云端 Retool（默认，大多数团队用的）：

[用户浏览器] --> [Retool 云服务器] --> [你的数据库]
                        ^                         |
                        |                         |
                        +------ 响应 -------------+

你用户跑的每个查询经 Retool 基建往返。你的数据库凭证存在 Retool 服务器上（加密了，是的——但存在那）。你用户写的 SQL、传的参数、返回的结果——全部经 Retool 网络。如果 Retool 宕机，你的内部工具就挂了。如果 Retool 延迟飙升，你的工具感觉慢。如果你的合规团队问「我们的数据库流量去哪了」，诚实答案是「经 Retool 的服务器，在 us-east-1 或他们跑的哪」。

自托管 Retool（仅企业版）：

[用户浏览器] --> [你的 Retool 实例] --> [你的数据库]
                        ^
                        |
                   你在自己的基建上跑这个

从数据流角度这更好。你的 DB 流量留在你网络。但自托管 Retool 是企业功能，意味着你付企业定价（跟销售谈，这是「这会很贵」的代码），且你现在负责在自己基建上跑基于 Docker 的 Retool 实例。你用第三方数据流问题换了服务器维护问题和一张大发票。

本地优先（我最后要论证的）：

[用户桌面应用] --> [你的数据库]
       ^
       |
   完全没有中间服务器

中间没有服务器。没有云账号。没有要保持运行的 Docker 容器。应用跑在你机器上直接跟你的数据库通信，跟 psql 或数据库 GUI 一样。

要澄清，这里的担忧不只是隐私。云端数据流有三个真实问题：

1. 隐私和合规。 你的数据库流量经第三方。对某些数据集和某些司法管辖区，那简直不允许。对其他，允许但需要供应商风险评估、数据处理协议和持续审计——你可以通过不做它完全消除的摩擦。

2. 延迟。 每个查询多一次网络跳。如果你的数据库在 eu-west 而 Retool 服务器在 us-east，你用户的查询跨大西洋两次。那不是理论延迟——它出现在每次表加载、每次筛选、每次搜索。

3. 可用性依赖。 如果 Retool 宕了，你的内部工具就挂了，即使你的数据库完全健康、你自己的基建没问题。你把工具可用性耦合到你不控制的供应商。我经历过数据库在、应用服务器在、但内部管理工具挂了因为 SaaS 供应商区域宕机。这是令人沮丧的失败模式，因为你这边其实什么都没坏。

4. 供应商锁定。 Retool 应用在 Retool 构建器里建、以 Retool 格式存。迁移离开 Retool 意味着在别的里重建你的工具。这个类别里每个工具某种程度上都这样，但云端依赖让它更尖锐——你迁移时甚至不能继续跑现有工具，因为运行时是托管的。

Retool 做得好什么

进入替代品前，我想对 Retool 公平，因为否定它不诚实。Retool 受欢迎有真实原因，如果数据流担忧不适用于你，那些原因仍成立。

应用构建器快。 我两个意思。在里面建东西快——你几分钟内得到表上的可用 CRUD 界面，一下午得到更复杂的多步骤工具。而结果应用用起来相当快，尽管有云端数据流。拖拽画布、属性面板、组件拼接方式——是精致的软件。我用过更笨的构建器，Retool 不是。

组件库真的好用。 表格、图表、表单、模态框、标签页、容器、地图——都在，都能用，都够可定制让你能建真正应用而不只是 dashboard。表格组件尤其是我用过的更好的之一。它处理大数据集、排序、筛选、内联编辑而不倒。

到处 JavaScript。 这是 Retool 的杀手功能，在我看来。任何你能放值的地方，你能放 JavaScript 表达式。任何你需要逻辑的地方，你能写 JavaScript 函数。你不受无代码抽象支持的限制——你需要时能下到真正代码，代码在能访问你查询、你组件、你应用状态的上下文里跑。对开发者，这是能扩展的工具和在边界情况崩溃的工具的区别。

AI 应用生成。 Retool 在 AI 上重投入，看得出来。你能用自然语言描述应用得到合理的初稿。你能让 AI 修改组件、写查询、生成 JavaScript。不完美——生成的应用仍需人工审查和调整——但它有意义地减少从想法到可用工具的时间。这是 Retool 的资源（他们是资金充足的公司）体现为真正产品优势的领域。

生态。 Retool 存在够久，有模板库、社区组件、集成、教程。如果你想建什么，大概有人建过类似的并写过。这对采用新工具的团队重要。

所以：Retool 好。如果数据流架构适合你，没理由换。这篇文章是给不适合的团队。

5 个让你的数据更近的替代品

五个替代品，大致按数据离你多近组织。前四个是自托管开源工具——它们跑在你基建上，所以你的 DB 流量留在你网络，但你在维护服务器。第五个是完全不同类别：完全没有服务器的本地优先桌面应用。

1. Appsmith（自托管，开源）

Appsmith 可能是 Retool 最直接的开源竞争者，GitHub stars 证明——撰写时约 39.6K。Apache 2.0 许可，这是更宽松的开源许可之一（你能商业用、修改、分发而无 copyleft 义务）。架构直接：你在自己基建上自托管 Appsmith 实例——VM、Docker 容器、Kubernetes 集群——你的用户通过浏览器访问，跟 Retool 一样。区别是 Appsmith 实例是你的。你的数据库凭证在你服务器上。你的查询从你服务器到你的数据库。什么都不经别人的网络。

构建器体验跟 Retool 类似：拖拽画布、组件库、JavaScript 做自定义逻辑、连接你数据库和 API 的查询编辑器。如果你用过 Retool，Appsmith 会感觉熟悉。组件库不如 Retool 精致，模板和社区内容生态更小，但核心功能——在你数据上建内部工具——扎实。

取舍是服务器维护。你在跑 Appsmith 实例，意味着你处理更新、备份、SSL 证书、访问控制、可用性。对有 DevOps 能力的团队，这是已知成本。对小团队或独立开发者，这是真实开销。Appsmith 也提供云端版，但如果你读这篇文章，你可能对云端版没兴趣——那有跟 Retool 云端一样的数据流担忧。

Appsmith 是对的选择如果：你想要 Retool 式体验、你有自托管基建、你想要让你自由修改分发的 Apache 2.0 许可。

2. ToolJet（自托管，开源）

ToolJet 是另一个主要开源 Retool 替代品，约 35K GitHub stars。AGPL v3 许可，这跟 Appsmith 的 Apache 2.0 是重要区别。AGPL 是强 copyleft 许可——如果你修改 ToolJet 并通过网络提供（你托管内部工具平台时正是做的），你有义务向你用户公开你修改的源代码。对大多数内部用例这没问题——你的用户是你自己员工，跟他们分享源代码不是问题。但如果你建修改的 ToolJet 暴露给外部用户，或你法务团队对 copyleft 许可保守，承诺前理解 AGPL 含义值得。

功能上，ToolJet 跟 Appsmith 类似：自托管、基于浏览器、拖拽构建器、JavaScript 做自定义逻辑、从你实例直接连你的数据库和 API。组件库可比。构建器体验可比。盲测里，大多数开发者从构建器 alone 难以区分 Appsmith 和 ToolJet——真正区别在许可、社区、各自更好支持的特定集成。

取舍跟 Appsmith 一样：你在维护服务器。而 AGPL 许可是考虑如果法务团队对 copyleft 有意见。

ToolJet 是对的选择如果：你想要 Retool 式体验、你 OK AGPL、你偏好 ToolJet 的特定组件集或社区。老实说，Appsmith 和 ToolJet 之间，选择常归结到许可偏好和哪个文档你觉得更清楚。

3. Budibase（自托管，开源）

Budibase 约 23.6K GitHub stars，角度跟 Appsmith 和 ToolJet 略不同。Appsmith 和 ToolJet 明确是「Retool 但开源」，Budibase 更偏低代码 CRUD 应用构建器端。它擅长在你数据上建表单、表格、CRUD 界面——内部工具的面包黄油——有内置数据库层用于你想创建新数据源而不是连接现有的时。

那个内置数据库值得谈。Budibase 能连外部数据库（PostgreSQL、MySQL、MongoDB 等），但也自带内部数据库用于需要自己数据存储的应用。如果你建需要跟踪自己状态的工具——审批工作流、表单提交、审计日志——连同它从你主数据库读的数据，这有用。它也是潜在混乱源：你现在数据在两处（Budibase 内部 DB 和你外部 DB），你需要清楚哪个是哪个。

Budibase 提供免费自托管版和付费云端计划。自托管版把数据留在你基建，这是本文相关点。取舍，再次，是服务器维护——加上如果你选择用内部数据库层的额外复杂度。

Budibase 是对的选择如果：你的内部工具主要是 CRUD 应用（表单、表格、记录管理）、你可能想要内置数据库做应用特定状态、你想要比 Appsmith 或 ToolJet 空白画布方式更有主见的构建器。

4. Windmill（自托管，开源）

Windmill 是列表上的异类，我想说清楚为什么在这。Windmill 主要不是内部工具构建器——它是工作流和脚本自动化平台，恰好也包含 UI 构建器。约 16.2K GitHub stars，跟其他根本不同的心智模型。

在 Windmill 里，你写脚本（Python、JavaScript、Go、Bash 等），Windmill 把它们变成可链成工作流的可复用步骤。工作流可由计划、webhook 或 UI 交互触发。UI 构建器让你建调用这些脚本和工作流的前端——所以你能建内部工具，但工具是脚本上的前端，不是直接数据库查询上的前端。

这是有意义的区别。如果你的内部工具主要是「跑这个查询在表里显示结果」，Windmill 太重——你会写脚本包装 Appsmith 或 ToolJet 让你直接跑的查询。但如果你的内部工具涉及真正逻辑——多步骤数据处理、调用外部 API、在系统间转换数据、跑计划任务——Windmill 的脚本优先方式真的比把逻辑螺栓到查询驱动工具上好。

取舍是更陡的学习曲线。Windmill 期望你写代码。不是属性面板里的 JavaScript 片段——实际文件里的实际脚本、版本控制、部署。对开发团队，这是功能不是 bug：你的内部工具逻辑是真正代码，你能像任何其他代码一样测试、审查、维护。对非开发者或寻找无代码体验的团队，它是障碍。

Windmill 是对的选择如果：你的内部工具脚本重、你想要工具逻辑是真正版本控制代码、你需要 UI 旁边的工作流自动化。是错的选择如果你只想要快速 CRUD 构建器。

5. BaseVolt（本地优先桌面）

我直说我的偏见：我跟 BaseVolt 有关，所以这部分带适当怀疑读、自己去验证。但我包含它因为它是列表里唯一采取根本不同架构方式的选项，而那个方式是这篇文章的全部要点。

BaseVolt 是本地优先桌面应用。不是你自托管的 web 应用。不是 Docker 容器。你装在 Mac 或 Windows 机器上的原生应用，跟你装 TablePlus 或 DBeaver 这样的数据库 GUI 一样。当你把 BaseVolt 连到你的数据库，连接是直接的——从你机器、到你的数据库、经你会用于任何其他数据库客户端的网络路径。没有中间服务器。没有云账号。没有 Docker。没有要维护的基建。

取舍很明显我想先说：它是桌面应用，不是共享 web UI。如果你需要整个团队通过浏览器访问的工具，BaseVolt 不对。它给直接管理数据库的人或小群——否则会一个窗口开 TablePlus、另一个开 Retool 应用、第三个开 psql 终端的人。BaseVolt 替代那个设置的管理面板部分，不是共享 web 应用部分。

BaseVolt 给你：SQLite、PostgreSQL、MySQL 和 Cloudflare D1 的管理面板，带 grid、gallery、kanban、dashboard 视图。内置 MCP 服务器让你连 AI 助手（Claude、Cursor、你用什么）帮忙管理 schema——生成迁移、探索表、写查询。跨设备同步如果你要（Pro 版），所以你保存的视图和连接在机器间跟着你。离线支持，因为一切本地跑，你的数据是你的。

免费版支持最多 2 个数据源，够在真实数据库上认真试。Pro $99/年加跨设备同步和无限数据源。没有注册墙、不用信用卡开始——你下载应用连数据库。

BaseVolt 是对的选择如果：你是管理数据库的人、你想要没有中间服务器的直接连接、你不需要更广团队的共享 web UI。是错的选择如果你在为非技术用户通过浏览器访问建工具。

对比表

	Retool（云端）	Retool（自托管）	Appsmith	ToolJet	Budibase	BaseVolt
部署	SaaS，Retool 托管	自托管（Docker），企业版	自托管（Docker/K8s）	自托管（Docker/K8s）	自托管（Docker）	桌面应用（macOS、Windows）
数据流	浏览器 → Retool 云 → 你的 DB	浏览器 → 你的实例 → 你的 DB	浏览器 → 你的实例 → 你的 DB	浏览器 → 你的实例 → 你的 DB	浏览器 → 你的实例 → 你的 DB	桌面应用 → 你的 DB（直接）
安装时间	分钟（注册、连 DB）	小时到天（Docker、基建、企业采购）	小时（Docker 部署、配置）	小时（Docker 部署、配置）	小时（Docker 部署、配置）	分钟（下载、连 DB）
应用构建器 vs 管理面板	完整应用构建器	完整应用构建器	完整应用构建器	完整应用构建器	低代码应用构建器，CRUD 聚焦	带视图的管理面板（grid、gallery、kanban、dashboard）
AI	AI 应用生成、AI 查询编写	AI 应用生成、AI 查询编写	AI 辅助构建	AI 辅助构建	AI 辅助构建	内置 MCP 服务器做 AI 辅助 schema 管理
成本	免费版，之后 $10+/用户/月	企业定价（跟销售谈）	免费自托管，付费云端	免费自托管，付费云端	免费自托管，付费云端	免费（2 源），Pro $99/年
要维护服务器	否（Retool 维护）	是	是	是	是	否
最适合	OK 云端数据流且要最精致构建器的团队	有企业预算和严格数据驻留要求的大团队	想要宽松许可开源 Retool 的团队	想要开源 Retool、OK AGPL 的团队	建 CRUD 应用、可能需要内部 DB 的团队	想要直接数据库连接无服务器的个人管理员或小团队

光谱：云端 → 自托管 → 本地优先

我认为框定这个选择最清晰的方式是数据离你多近的光谱。

云端（Retool 云、Appsmith 云、ToolJet 云、Budibase 云）： 你的数据离你最远。它经供应商服务器。你得到最简单设置、最少维护、最精致体验——但你用数据邻近换方便。这是光谱数据流不是担忧的团队的正确端。

自托管（Retool 自托管、Appsmith、ToolJet、Budibase、Windmill）： 你的数据更近。它留在你网络，经你控制的基建。你以服务器维护为代价——更新、备份、可用性、访问控制。这是光谱中间，是大多数有数据担忧的团队落的地方。你得到 web 应用体验（通过浏览器共享访问）而没有第三方数据流。

本地优先（BaseVolt）： 你的数据最近。完全没有服务器——应用从你机器直接跟你数据库通信。你放弃共享 web UI，换取完全消除服务器。没有维护、没有 Docker、没有云账号、没有任何中间基建。这是光谱最远端，是不需要共享 web UI 的个人管理员和小团队的正确端。

大多数关于 Retool 替代品的文章把这呈现为二元：云端 vs 自托管。我认为看作光谱更有用，因为真正问题不是「云端还是自托管」——而是「你需要数据保持多近，你愿意放弃什么来达到？」云端放弃数据邻近换方便。自托管放弃方便（服务器维护）换数据邻近。本地优先放弃共享 web UI 换最大数据邻近和零维护。

没有普遍对的答案。有你特定情况对的答案，取决于你的数据是什么、谁需要访问、你的合规约束是什么、你愿意跑多少基建。

每种方式什么时候赢

让我具体化，因为抽象框架只在你必须做实际决定前有用。

用 Retool 云端如果： 你的数据不够敏感不用担心第三方数据流、你想要最精致构建器体验、你想要 AI 应用生成、你宁愿按用户付费也不维护基建。这老实说是大多数团队。Retool 是默认有原因的，如果数据流担忧不适用于你，没必要想太多。

用 Retool 自托管如果： 你特别需要 Retool（构建器、生态、精致）、你有企业预算、你有要求自托管的合规要求。这是窄情况——有特定工具标准和匹配预算的大公司。

用 Appsmith 如果： 你想要 Retool 式构建器、你想要宽松许可的开源（Apache 2.0）、你有自托管基建。Appsmith 是你不确定许可时最安全的开源选择——Apache 2.0 被充分理解，很少制造法律摩擦。

用 ToolJet 如果： 你想要 Retool 式构建器、你 OK AGPL v3（或你法务团队已清）、你偏好 ToolJet 的特定方式。Appsmith 和 ToolJet 之间，许可常是决定因素。如果 AGPL 对你用例不是问题，试用后选你更喜欢哪个构建器。

用 Budibase 如果： 你的内部工具主要是 CRUD 应用——表单、表格、记录管理——你可能想要内置数据库做应用特定状态。Budibase 比 Appsmith 或 ToolJet 更有主见，如果你的工具适合它的模型这是功能，不适合是限制。

用 Windmill 如果： 你的内部工具涉及真正逻辑——多步骤工作流、脚本执行、API 编排、计划任务——你想要那个逻辑是版本控制代码而不是构建器里的 JavaScript 片段。Windmill 是这里唯一把脚本当一等公民的，如果你的工具脚本重，即使它不是纯 Retool 替代品，它是对的选择。

用 BaseVolt 如果： 你是直接管理数据库的人、你想要没有中间服务器的直接连接、你不需要更广团队的共享 web UI。BaseVolt 替代你工作流的管理工具部分——否则你会数据库 GUI 旁边开 Retool 应用的部分——用单个本地优先应用直接连。它不是给团队建共享 web 工具的 Retool 替代品。它是给从不需要共享 web 工具的个人管理员的 Retool 替代品。

总结

Retool 好。开源替代品（Appsmith、ToolJet、Budibase、Windmill）好。如果数据流担忧是驱使你离开 Retool 云端的，它们都值得你时间，都以同样方式解决问题：通过在你基建上放服务器而不是供应商的。这是合理解决方案，对于需要共享 web UI 的团队，是对的。

但如果你是个人管理员或小团队，你维护自托管 Appsmith 实例纯粹是为了数据库查询不经第三方，值得问你是否到底需要服务器。很多内部工具是一个人或小群直接用数据库。对那种情况，直接连你数据库的本地优先桌面应用——不用服务器、不用 Docker、不用云账号、不用维护——是更简单架构，用更少动件解决同样问题。

这就是 BaseVolt 填补的空白。它不适合所有人，我试过诚实说哪里不适合。但如果你是宁愿装应用也不部署容器的人，且你想要数据库连接跟数据库 GUI 的连接一样直接，值得看看。

在 basevolt.app 试试 — 不用注册，不用信用卡。连个数据库看直接连接模型是否适合你。demo 在 demo.basevolt.app 如果想先逛逛。

如果你有问题、反馈、或想争论自托管 Appsmith 是否其实更适合你的情况（可能），在 X 上找我。