Supabaseを閲覧するGUIを権限から比較する

Supabaseのデータを確認するだけなら、管理者向けのGUIを最初から選ぶ必要はありません。

ただし、画面に編集ボタンがないことと、データベースが読み取り専用であることは別です。

この比較では、先にPostgreSQLの権限を絞り、その上でGUIの操作感と共有方法を比べます。

先に「閲覧」の意味を分ける

目的	候補	比較の焦点
ときどき行を確認する	DBeaver、pgAdmin	接続の安全性と検索のしやすさ
SQLを含む調査を行う	DBeaver、CloudBeaver	schema、query、export
定型の集計を共有する	Metabase	question、filter、dashboard
ブラウザで複数人が使う	CloudBeaver	user、team、connection権限
一時的に軽量な画面が必要	Adminer	公開範囲と更新管理

ツールのread-only表示は、DB側の書き込み権限を取り消しません。

GUIを変えても同じcredentialで書き込めるなら、事故の境界は変わっていません。

PostgreSQL側を最初の防波堤にする

本番相当のデータを扱うGUIへ、postgres userやSupabase Secret keyを渡しません。

用途専用のread-only roleを作ります。

create role notes_reader login;

-- passwordはSQL本文やshell historyへ書かず、安全な管理手順で設定します。
-- psqlなら、たとえば次の対話コマンドを使います。
-- \password notes_reader

grant connect on database postgres to notes_reader;
grant usage on schema public to notes_reader;
grant select on all tables in schema public to notes_reader;

-- 指定したownerが今後作るtableへSELECTを付けます。
alter default privileges for role postgres in schema public
  grant select on tables to notes_reader;

実際のdatabase、schema、tableは必要な範囲へ絞ります。

ALTER DEFAULT PRIVILEGESは既存objectへ遡及せず、指定したroleが今後作るobjectへ適用されます。

migrationを複数のroleで実行する場合は、実際の作成者ごとに設定します。

table全体ではなく、公開用viewへだけSELECTを付ける設計もできます。

このroleへINSERT、UPDATE、DELETE、CREATE、ALTER、DROPを与えません。

GUIの編集機能を無効にしても、DB権限が強ければ別clientから書き込めるからです。

SupabaseのRLSを使うData API経路と、PostgreSQLへ直接接続するDB roleの境界は別に監査します。

5つの候補を同じ軸で見る

ツール	得意なこと	UI	read-onlyの境界	向く用途
Metabase	question、filter、chart、dashboard	browser	分析用DB user	定型の分析共有
CloudBeaver	DB explorer、table、SQL	browser	DB roleとUI権限	複数人の共有
DBeaver Community	SQL、schema、data、export	desktop	editionのread-only機能とDB role	個人の調査
pgAdmin	PostgreSQLのrole、schema、設定	desktop / Web	PostgreSQL権限	DB固有機能の確認
Adminer	軽量なDB管理	browser	DB roleが必須	一時的な接続

OSS版、commercial edition、バージョンによって、user管理、接続制限、編集制限の範囲は変わります。

導入前に、使うeditionの公式資料を確認します。

Metabaseは閲覧を分析へ育てる

Metabaseは、行の確認からsaved question、filter、chart、dashboardへ進めたい場合に向きます。

分析対象のschemaやtableへCONNECTとSELECTだけを持つ専用userで接続します。

CSV upload、Actions、modelの永続化などを使う場合は、追加の書き込み権限が必要になることがあります。

閲覧用connectionと書き込みを伴うconnectionを分けます。

Metabase自身のuser、question、dashboardを保存するapplication databaseも別に必要になります。

個人がたまに見るだけなら、その運用負担をDBeaverと比較します。

CloudBeaverは共有ブラウザGUIです

CloudBeaverは、table閲覧、filter、SQLをbrowserへまとめます。

チームで使うなら、DB roleに加えてeditionが提供するuser、team、connection、Data Editor権限を確認します。

Data Editorでは、edit、import、export、SQL実行を分けて扱える場合があります。

read-only接続で編集が無効でも、UI権限はDB権限の代替ではありません。

1人がlocalで調査するだけなら、CloudBeaverのserver運用は大きすぎる可能性があります。

DBeaverは個人の調査から始めやすい

DBeaverはschema確認、SQL、実行計画、exportを1つのdesktop UIで扱います。

SupabaseのDBeaver手順を使い、IPv6環境ではDirect connection、IPv4だけの環境ではSession Poolerを検討します。

対応editionにconnection単位のread-onlyや編集制限があっても、server側のroleは別にread-onlyへします。

production-readonlyとdevelopmentを別connection名、背景色、credentialで分けると、対象を取り違えにくいです。

pgAdminはPostgreSQLを深く確認する

pgAdminはPostgreSQLのrole、schema、SSL、SQL、backupを確認する用途に向きます。

単純なtable検索だけなら、管理者向けの機能が過剰に見えます。

主キーのないtableやviewは、行を一意に識別できずgridがread-onlyになる場合があります。

これはDB roleの安全性を保証する表示ではありません。

常にread-only roleで接続します。

Adminerは軽いが公開しない

Adminerは単一PHP fileで動かせる軽量なDB管理toolです。

一方で、rowの追加、更新、削除、SQL、schema変更の機能を持ちます。

使う場合は、次の条件を満たします。

専用read-only DB userで接続する
internetへ直接公開しない
Web認証、IP制限、VPNなどを追加する
更新を止めない
使い終わったら削除する

軽量であることは、安全であることを意味しません。

目的別の出発点

ときどきtableを見る

DBeaverのread-only connectionから試します。

既にlocalへ入っているなら、DB roleを作って接続するだけで十分です。

browserでチーム共有する

CloudBeaverを検討します。

DB roleとCloudBeaver側のuser、team権限を二重に管理する点を受け入れます。

定型レポートを作る

Metabaseを使います。

分析用connectionはread-onlyにし、書き込み機能が必要なら別roleへ分離します。

PostgreSQLの構造を見る

pgAdminを候補にします。

行の閲覧だけなら、DBeaverの方が軽いです。

一時的な軽量toolが必要

Adminerを使えるが、公開範囲とDB権限を厳しく制限します。

まとめ

比較で重要なのは、tool名ではなく書き込みをどこで止めるかです。

DB roleで最小権限を作り、GUIのread-only設定を追加の防止策として重ねます。

本番と開発のcredentialを分け、browser GUIをinternetへ公開しません。

個人の調査はDBeaver、共有browserはCloudBeaver、dashboardはMetabaseから試すとよいです。

どのtoolを選んでも、Supabaseの管理者credentialをそのまま渡さないことが最優先です。