データベースを他人のサーバーにアップロードしないRetool代替品

Retoolを使ったことがあります。Retoolが好きです。火曜日までに内部ツールが必要で、チームがすでにJavaScriptを知っているなら、Retoolは市場のほぼすべてのものより速く到達できます。カテゴリのデフォルトとしての地位は正当に獲得したものです。コンポーネントライブラリは本物に優れており、ドラッグ&ドロップのビルダーは速く、どこでもJavaScriptに落ちられるということは、最悪のタイミングで壊れるノーコードの抽象化に閉じ込められないことを意味します。

しかし、多くのRetoolレビューが目立つ形で触れないことがあり、特定の種類のチームにとって最終的に最も重要になるのはそれです。ユーザーがRetoolアプリでクエリを実行するとき、そのクエリはブラウザから直接データベースには行きません。ブラウザからRetoolのサーバーへ、そこからデータベースへ、そしてRetoolのサーバーを経由して戻り、ブラウザに戻ります。Retoolはすべてのデータベース操作の中間に位置します。ユーザーが読むすべての行、実行するすべてのクエリ、適用するすべてのフィルター——そのすべてが第三者が所有・運営するインフラを通過します。

多くのチームにとって、それは問題ありません。本当に問題ありません。データベースが機密でない分析データの読み取りレプリカであったり、すでにすべてをSaaSベンダーに信頼しているチームの内部ツールを構築しているなら、Retoolのサーバーを経由するデータフローは問題になりません。Retoolは真剣なセキュリティ姿勢、SOC 2コンプライアンス、徹底的に審査したエンタープライズ顧客を持つ、しっかり運営された会社です。

しかし、本番データベース、コンプライアンス要件（HIPAA、独自のSOC 2、GDPRのデータ居住性制約）、エアギャップ環境、あるいはデータベーストラフィックを第三者に経由させないという強い組織的方針を持つチームにとっては、それは問題です。そして、それは多くの「Retool代替品」記事が横から枠組みます。オープンソースについて語り、セルフホストについて語り、コストについて語ります。しかし、実際のこと——あなたのクエリは他人のサーバーを流れていて、これがそれを止める方法です——とはめったに言いません。

この記事はそれについてのものです。

データフローの問題

アーキテクチャはマーケティングより重要なので、テキストで描いてみましょう。

クラウドRetool（デフォルト、ほとんどのチームが使うもの）：

[User's Browser] --> [Retool Cloud Servers] --> [Your Database]
                        ^                         |
                        |                         |
                        +------ responses --------+

ユーザーが実行するすべてのクエリはRetoolのインフラを往復します。データベースの認証情報はRetoolのサーバーに保存されます（暗号化されていますが、そこに保存されています）。ユーザーが書くSQL、渡すパラメータ、戻ってくる結果——そのすべてがRetoolのネットワークを通過します。Retoolに障害が起きれば内部ツールはダウンします。Retoolにレイテンシのスパイクがあれば、ツールは遅く感じられます。コンプライアンスチームに「データベーストラフィックはどこに行くのか」と聞かれたら、正直な答えは「Retoolのサーバー、us-east-1か彼らが動かしている場所を経由します」です。

セルフホストRetool（エンタープライズ層のみ）：

[User's Browser] --> [Your Retool Instance] --> [Your Database]
                        ^
                        |
                   You run this on your own infra

データフローの観点からはこちらが良いです。DBトラフィックはあなたのネットワークに留まります。しかし、セルフホストRetoolはエンタープライズ機能であり、エンタープライズ価格（営業に相談、これは「高額になります」のコード）を払うことになり、自分のインフラ上でDockerベースのRetoolインスタンスを動かす責任を負います。第三者のデータフロー問題を、サーバー保守問題と巨額の請求書に交換したことになります。

ローカルファースト（最後に主張するもの）：

[User's Desktop App] --> [Your Database]
       ^
       |
   No intermediate server at all

中間にサーバーはありません。クラウドアカウントもありません。稼働させ続けるDockerコンテナもありません。アプリはあなたのマシンで動き、psqlやデータベースGUIと同じようにデータベースに直接話します。

ここでの懸念はプライバシーだけではありません、明確にしておきます。クラウドのデータフローには3つの（訳注：原文では4つ）現実的な問題があります。

プライバシーとコンプライアンス。 データベーストラフィックが第三者を通過します。一部のデータセットと一部の管轄区域では、それは単に許可されません。他のものでは許可されるものの、ベンダーリスク評価、データ処理契約、継続的な監査が必要であり、それをしないことで完全に排除できる摩擦です。
レイテンシ。 すべてのクエリが余分なネットワークホップを取ります。データベースがeu-westにありRetoolのサーバーがus-eastにあるなら、ユーザーのクエリは大西洋を2回横断します。それは理論上のレイテンシではなく、すべてのテーブル読み込み、すべてのフィルタ、すべての検索に現れます。
稼働時間の依存。 Retoolがダウンすれば、データベースが完全に健康で自分のインフラも問題なくても、内部ツールはダウンします。ツールの可用性を制御できないベンダーに結びつけてしまいました。データベースが上がっていて、アプリサーバーも上がっていても、SaaSベンダーのリージョン障害で内部管理ツールがダウンしたインシデントに居合わせたことがあります。自分側では実際には何も壊れていないので、フラストレーションのたまる障害モードです。
ベンダーロックイン。 RetoolアプリはRetoolのビルダーで構築されRetoolの形式で保存されます。Retoolからの移行はツールを別のものに作り直すことを意味します。このカテゴリのすべてのツールにある程度当てはまりますが、クラウド依存がそれをより鋭くします。ランタイムがホストされているため、移行中も既存のツールを使い続けることすらできません。

Retoolの優れた点

代替品に入る前に、Retoolに公平でありたいと思います。退けるのは不誠実だからです。Retoolは現実的な理由で人気があり、データフローの懸念が当てはまらないなら、その理由は依然として有効です。

アプリビルダーが速い。 2つの意味で言っています。構築が速い——テーブルの上に動くCRUDインターフェースを数分で、より複雑な多段階ツールを午後中で作れます。そして、クラウドのデータフローはあるものの、出来上がったアプリもそこそこ速く動きます。ドラッグ&ドロップのキャンバス、プロパティパネル、コンポーネントがスナップする仕組み——洗練されたソフトウェアです。もっと不格好なビルダーを使ったことがありますが、Retoolはそれらの仲間ではありません。

コンポーネントライブラリが本物に優れている。 テーブル、チャート、フォーム、モーダル、タブ、コンテナ、マップ——すべて揃っていて、すべて動き、ダッシュボードだけでなく本物のアプリケーションを構築できるほどカスタマイズ可能です。特にテーブルコンポーネントは私が使った中でもより良い部類のものです。大規模なデータセット、ソート、フィルタ、インライン編集を倒れることなく処理します。

どこでもJavaScript。 これがRetoolのキラー機能だと私は思います。値を置ける場所ならどこでもJavaScript式を置けます。ロジックが必要な場所ならどこでもJavaScript関数を書けます。ノーコードの抽象化がサポートするものに制限されず、必要なときはいつでも実際のコードに落ちられ、そのコードはクエリ、コンポーネント、アプリの状態にアクセスできるコンテキストで動きます。開発者にとって、これがスケールするツールとエッジケースで壊れるツールの違いです。

AIアプリ生成。 RetoolはAIに大きく投資しており、それは表れています。自然言語でアプリを説明して合理的な初稿を得られます。AIにコンポーネントの変更、クエリの作成、JavaScriptの生成を依頼できます。完璧ではありません——生成されたアプリには人間のレビューと調整が必要です——しかしアイデアから動くツールまでの時間を意味的に短縮します。これはRetoolの資源（資金を十分に調達した会社です）が実際の製品の利点として現れる領域です。

エコシステム。 Retoolは十分に長く存在しているので、テンプレート、コミュニティコンポーネント、連携機能、チュートリアルのライブラリがあります。何かを構築したいなら、おそらく誰かが似たものを構築して書いています。新しいツールを採用するチームにとって、それは重要です。

つまり、Retoolは良いです。データフローのアーキテクチャがあなたに合うなら、切り替える理由はありません。この記事は、合わないチームのためのものです。

データをより近くに保つ5つの代替品

5つの代替品を、データをどれだけ近くに保つかでおおよそ並べて紹介します。最初の4つはセルフホストのオープンソースツールです。自分のインフラで動くのでDBトラフィックはネットワークに留まりますが、サーバーを保守します。5つ目は完全に異なるカテゴリです。サーバーのないローカルファーストのデスクトップアプリです。

1. Appsmith（セルフホスト、オープンソース）

AppsmithはおそらくRetoolに対する最も直接的なオープンソースの競合で、それを証明するGitHub starsがあります。執筆時点で約39.6Kです。Apache 2.0でライセンスされており、より寛容なオープンソースライセンスのひとつです（商用利用、改変、コピーレフトの義務なく配布できます）。アーキテクチャはシンプルです。自分のインフラ——VM、Dockerコンテナ、Kubernetesクラスタ——にAppsmithインスタンスをセルフホストし、ユーザーは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は強いコピーレフトライセンスです。ToolJetを改変してネットワーク経由で利用可能にした場合（内部ツールプラットフォームをホストするときにまさにそうします）、改変のソースコードをユーザーに公開する義務があります。ほとんどの内部ユースケースでは問題ありません。ユーザーは自分の従業員で、ソースコードを彼らと共有するのは問題ないからです。しかし、外部ユーザーに公開する改変ToolJetを構築している場合や、法務チームがコピーレフトライセンスに保守的な場合は、コミットする前にAGPLの意味を理解しておく価値があります。

機能面ではToolJetはAppsmithに似ています。セルフホスト、ブラウザベース、ドラッグ&ドロップのビルダー、カスタムロジック用のJavaScript、インスタンスから直接データベースとAPIに接続。コンポーネントライブラリは同等です。ビルダーの体験も同等です。ブラインドテストなら、ほとんどの開発者はビルダーだけからAppsmithとToolJetの違いを見分けるのに苦労するでしょう。本当の違いはライセンス、コミュニティ、それぞれがより良くサポートする特定の連携機能にあります。

トレードオフはAppsmithと同じくサーバー保守です。そして法務チームがコピーレフトに意見を持つ場合はAGPLライセンスが考慮事項です。

ToolJetが正しい選択なのは、Retoolのような体験が欲しく、AGPLに問題がなく、ToolJetの特定のコンポーネントセットやコミュニティを好む場合です。正直なところ、AppsmithとToolJetの選択は多くの場合、ライセンスの好みとどちらのドキュメントがわかりやすいと感じるかに帰着します。

3. Budibase（セルフホスト、オープンソース）

Budibaseは約23.6KのGitHub starsで、AppsmithやToolJetとは少し異なる角度を取ります。AppsmithとToolJetが明確に「オープンソースのRetool」であるのに対し、BudibaseはスペクトルのローコードCRUDアプリビルダー寄りに傾いています。フォーム、テーブル、データの上のCRUDインターフェースの構築に優れており、既存のものに接続するのではなく新しいデータソースを作りたいときのための組み込みデータベースレイヤーもあります。

その組み込みデータベースは語る価値があります。Budibaseは外部データベース（PostgreSQL、MySQL、MongoDBなど）に接続できますが、独自のデータストアが必要なアプリのための内部データベースも同梱しています。これはメインデータベースから読みつつ、独自の状態を追跡する必要があるツール——承認ワークフロー、フォーム送信、監査ログ——を構築するときに便利です。また混乱の元にもなります。データが2箇所（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スニペットではなく、実際のファイル内の実際のスクリプトで、バージョン管理されデプロイされるものです。開発チームにとってこれはバグではなく機能です。内部ツールのロジックは他のコードと同じようにテスト、レビュー、保守できる本物のコードです。非開発者やノーコードの体験を求めるチームにとっては障壁です。

Windmillが正しい選択なのは、内部ツールがスクリプト中心で、ツールのロジックをバージョン管理された本物のコードにしたい場合で、UIと並んでワークフロー自動化が必要な場合です。速いCRUDビルダーが欲しいだけなら間違った選択です。

5. BaseVolt（ローカルファースト・デスクトップ）

ここで私のバイアスを直接述べておきます。私はBaseVoltに関わっているので、このセクションは適切な懐疑心を持って読み、自分で検証してください。しかし、これを含めたのは、このリストで唯一根本的に異なるアーキテクチャアプローチを取る選択肢であり、そのアプローチこそがこの記事の核心だからです。

BaseVoltはローカルファーストのデスクトップアプリです。セルフホストするウェブアプリではありません。Dockerコンテナでもありません。TablePlusやDBeaverのようなデータベースGUIをインストールするのと同じように、MacやWindowsマシンにインストールするネイティブアプリケーションです。BaseVoltをデータベースに接続するとき、接続は直接です。あなたのマシンから、他のデータベースクライアントが使うのと同じネットワークパスを通ってデータベースへ。中間にサーバーはありません。クラウドアカウントもありません。Dockerもありません。保守するインフラもありません。

トレードオフは明らかで、前もって述べておきます。デスクトップアプリであり、共有ウェブUIではありません。チーム全体がブラウザからアクセスするツールが必要なら、BaseVoltは適していません。データベースを直接管理する人や小規模なグループ向けです。別の言い方をすれば、片方のウィンドウにTablePlusを開き、もう片方にRetoolアプリ、3つ目にpsqlのターミナルを開いているような人です。BaseVoltはそのセットアップの管理パネル部分を置き換えるのであって、共有ウェブアプリ部分を置き換えるのではありません。

BaseVoltが提供するもの：SQLite、PostgreSQL、MySQL、Cloudflare D1の管理パネル。データの上のグリッド、ギャラリー、カンバン、ダッシュボードのビュー。AIアシスタント（Claude、Cursor、何を使っていても）を接続してスキーマの管理を手伝わせる——マイグレーションの生成、テーブルの探索、クエリの作成——ための組み込みMCPサーバー。必要ならクロスデバイス同期（Pro層）で、保存したビューや接続がマシン間で追従します。すべてローカルで動き、データはあなたのものなので、オフラインサポートもあります。

無料枠は最大2つのデータソースまでで、本物のデータベースで本格的に試すには十分です。Proは$99/年でクロスデバイス同期と無制限のデータソースが追加されます。サインアップの壁もなく、開始にクレジットカードも不要です。アプリをダウンロードしてデータベースに接続するだけです。

BaseVoltが正しい選択なのは、あなたがデータベースを管理する人で、中間にサーバーのない直接接続が欲しく、より広いチームのための共有ウェブ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中心	ビュー付き管理パネル（グリッド、ギャラリー、カンバン、ダッシュボード）
AI	AIアプリ生成、AIクエリ作成	AIアプリ生成、AIクエリ作成	AI支援ビルド	AI支援ビルド	AI支援ビルド	AI支援スキーマ管理のための組み込みMCPサーバー
コスト	無料枠、その後$10+/ユーザー/月	エンタープライズ価格（営業に相談）	無料セルフホスト、有料クラウド	無料セルフホスト、有料クラウド	無料セルフホスト、有料クラウド	無料（2ソース）、Pro $99/年
保守すべきサーバー	いいえ（Retoolが保守）	はい	はい	はい	はい	いいえ
最適な用途	クラウドデータフローに問題がなく最も洗練されたビルダーが欲しいチーム	エンタープライズ予算と厳格なデータ居住要件を持つ大規模チーム	寛容なライセンスのオープンソースRetoolが欲しいチーム	オープンソースRetoolが欲しくAGPLに問題ないチーム	CRUDアプリを構築し、内部DBが必要かもしれないチーム	直接のデータベース接続とサーバーなしが欲しい個人管理者や小規模チーム

スペクトラム：クラウド → セルフホスト → ローカルファースト

この選択を最も明確に枠組む方法は、データがどれだけ自分に近く留まるかのスペクトラムとして捉えることだと思います。

クラウド（Retool Cloud、Appsmith Cloud、ToolJet Cloud、Budibase Cloud）： データが最も遠くにあります。ベンダーのサーバーを通過します。最も簡単なセットアップ、最小の保守、最も洗練された体験が得られますが、データの近さを便利さと交換しています。データフローが懸念事項でないチームにとって、これはスペクトラムの正しい端です。

セルフホスト（Retool セルフホスト、Appsmith、ToolJet、Budibase、Windmill）： データがより近くにあります。あなたのネットワークに留まり、あなたが制御するインフラを通過します。コストとしてサーバー保守を引き受けます——更新、バックアップ、稼働時間、アクセス制御。これはスペクトラムの中間であり、データ懸念を持つほとんどのチームが落ち着く場所です。第三者のデータフローなしにウェブアプリの体験（ブラウザからの共有アクセス）が得られます。

ローカルファースト（BaseVolt）： データが最も近くにあります。サーバーはまったくなく、アプリがあなたのマシンから直接データベースに話します。共有ウェブUIを手放し、その代わりにサーバーを完全に排除します。保守もDockerもクラウドアカウントも、いかなる中間インフラもありません。これはスペクトラムの最も遠い端であり、共有ウェブUIを必要としない個人管理者や小規模チームにとって正しい端です。

ほとんどのRetool代替品の記事はこれをクラウド対セルフホストの二択として提示します。スペクトラムとして見るほうが有用だと思います。本当の問いは「クラウドかセルフホストか」ではなく「データをどれだけ近くに留める必要があり、それのために何を手放せるか」だからです。クラウドは便利さのためにデータの近さを手放します。セルフホストはデータの近さのために便利さ（サーバー保守）を手放します。ローカルファーストは最大のデータの近さとゼロ保守のために共有ウェブUIを手放します。

普遍的に正しい答えはありません。あなたの特定の状況にとっての正しい答えがあります。それはあなたのデータが何か、誰がアクセスする必要があるか、コンプライアンスの制約が何か、どれだけのインフラを動用意があるかに依存します。

それぞれのアプローチが勝つとき

これを具体的にしましょう。抽象的なフレームワークは実際の決定を下すまでしか有用ではありません。

Retool Cloudを使うべきなのは： データが第三者のデータフローを心配するほど機密ではなく、最も洗練されたビルダー体験が欲しく、AIアプリ生成が欲しく、インフラを保守するよりユーザーごとに課金したい場合。正直なところ、これはほとんどのチームです。Retoolがデフォルトなのには理由があり、データフローの懸念が当てはまらないなら、これについて考えすぎる必要はありません。

Retool セルフホストを使うべきなのは： 特にRetoolが必要（ビルダー、エコシステム、洗練度）で、エンタープライズ予算があり、セルフホストを義務づけるコンプライアンス要件がある場合。これは狭いケースです。特定のツール標準とそれに見合う予算を持つ大企業です。

Appsmithを使うべきなのは： Retoolのようなビルダーが欲しく、寛容なライセンス（Apache 2.0）のオープンソースが欲しく、セルフホストするインフラがある場合。ライセンスについて不確かな場合、Appsmithは最も安全なオープンソースの選択です。Apache 2.0はよく理解されており、法的な摩擦をめったに生みません。

ToolJetを使うべきなのは： Retoolのようなビルダーが欲しく、AGPL v3に問題がない（または法務チームがクリアした）場合で、ToolJetの特定のアプローチを好む場合。AppsmithとToolJetの間では、ライセンスがしばしば決定要因です。AGPLがユースケースで問題にならないなら、試した後でビルダーが好きなほうを選んでください。

Budibaseを使うべきなのは： 内部ツールが主にCRUDアプリ——フォーム、テーブル、レコード管理——で、アプリ固有の状態のための組み込みデータベースが欲しいかもしれない場合。BudibaseはAppsmithやToolJetより意見があり、ツールがそのモデルに合えば機能になり、合わなければ制限になります。

Windmillを使うべきなのは： 内部ツールが本物のロジックを含み——多段階ワークフロー、スクリプト実行、APIオーケストレーション、スケジュールジブ——そのロジックをビルダー内のJavaScriptスニペットではなくバージョン管理されたコードにしたい場合。Windmillはここでスクリプトを一級市民として扱う唯一の選択肢であり、ツールがスクリプト中心なら、純粋なRetoolの置き換えではないものの適切な選択です。

BaseVoltを使うべきなのは： あなたがデータベースを直接管理する人で、中間にサーバーのない直接接続が欲しく、より広いチームのための共有ウェブUIが不要な場合。BaseVoltはワークフローの管理ツール部分——別ならデータベースGUIをRetoolアプリと並べて開いている部分——を、直接接続する単一のローカルファーストアプリで置き換えます。共有ウェブツールを構築するチーム向けのRetoolの置き換えではありません。そもそも共有ウェブツールを必要としなかった個人管理者向けのRetoolの置き換えです。

まとめ

Retoolは良いです。オープンソースの代替品（Appsmith、ToolJet、Budibase、Windmill）も良いです。データフローの懸念がRetool Cloudから離れる動機なら、どれも時間を費やす価値があり、すべて同じ方法で問題を解決します。ベンダーの代わりにあなたのインフラにサーバーを置くことです。それは正当な解決策であり、共有ウェブUIが必要なチームにとっては正しいものです。

しかし、あなたが個人管理者や小規模チームで、データベースクエリが第三者を流れないようにするためだけにセルフホストのAppsmithインスタンスを保守しているなら、そもそもサーバーが必要かどうかを問う価値があります。多くの内部ツールは、1人または小規模なグループがデータベースを直接操作するものです。その場合、データベースに直接接続するローカルファーストのデスクトップアプリ——サーバーもDockerもクラウドアカウントも保守もなし——は、同じ問題をより少ない可動部で解決するシンプルなアーキテクチャです。

それがBaseVoltが埋めるギャップです。すべての人向けではなく、合わない場所については正直に書いたつもりです。しかし、コンテナをデプロイするよりアプリをインストールしたいタイプで、データベース接続をデータベースGUIの接続と同じくらい直接にしたいなら、一見の価値があります。

basevolt.app で試してみてください — サインアップ不要、クレジットカード不要。データベースに接続して、直接接続モデルが自分に合うか確認してください。まず見て回りたい場合はデモが demo.basevolt.app にあります。

質問、フィードバック、またはセルフホストAppsmithが自分のケースに本当に適しているか（そうかもしれません）について議論したい場合は、X でフォローしてください。