Baserow

表計算UIを入口に、データベースを業務アプリの共通データ層として使う

Baserowの出発点は、行と列で操作できるspreadsheet-database hybridです。表形式でデータを管理しつつ、フォームやKanbanなど用途別の見せ方へ広げられます。さらにApplication Builderでは、そのデータを基にページやポータル、社内向けアプリをNo-Codeで構築できます。データ管理と画面構築を別々のSaaSへ分けず、同じworkspace内で扱えることが強みです。

出典：[1][2]

AutomationsとDashboardsを同じデータモデルへ接続し、入力後の処理と可視化までつなぐ

Automationsではtriggerとactionを組み合わせて反復作業をworkflow化し、Dashboardsではデータソースをチャートや集計へつなげられます。リポジトリ内でもApplication Builderのdata source、workflow action、Automation node、Dashboard data sourceが共通のservice / dispatch設計へ接続されており、単なる表データの保存先ではなく、入力・処理・画面・分析を一つのplatformへまとめる方向が明確です。

出典：[1][2]

Airtableを超えて、社内業務のデータ・画面・自動処理を自社管理したいチームへ

顧客管理、案件管理、在庫、申請、コンテンツ管理などをスプレッドシートから始めつつ、後からフォーム、ポータル、ダッシュボード、自動化へ成長させたいチームに向きます。特に、Airtableなどのクラウドサービスへ重要データを固定したくない場合や、REST APIを介して既存システムと統合したい場合に適しています。小規模なら単一Dockerコンテナで試せ、より本格的な運用ではComposeやHelm、クラウド向けの導入手順へ移行できます。

出典：[1]

Open Source EditionとPremium / Enterpriseはライセンスが異なり、AIを含む機能境界を確認して導入する

BaserowはOpen Coreです。トップレベルのLICENSEでは、Open Source Editionとclient-side JavaScriptの対象部分はMIT Expatですが、premium/とenterprise/配下はそれぞれ別ライセンスと明記されています。Premium / Enterpriseコードをproductionで利用するには、各Editionの有効なsubscriptionが必要です。したがって、GitHub上にコードが見えることと、すべての機能をMIT条件で本番利用できることは同義ではありません。

READMEで案内されるKuma AI Assistantの実装にはenterprise/配下のコンポーネントも含まれるため、AI機能を前提に評価する場合は利用Editionを確認した方が安全です。セルフホストではPostgreSQLを含むアプリ基盤、バックアップ、アップグレード、TLS、メールなどの運用も利用者側の責任になります。

出典：[1][4][5][6][3]