database.build を採用する前に読む、PGlite と pg-gateway の構成とセットアップの実際
In-browser Postgres sandbox with AI assistance (formerly postgres.new)
ひと目でわかる
- これは何？
- database.build（旧 postgres.new）は、PGlite をブラウザ内で動かし、IndexedDB に永続化する Postgres サンドボックスに LLM を組み合わせたモノレポだ。TCP 接続をブラウザへ戻す browser-proxy と、Supabase へデプロイする deploy-worker まで含めた構成を、README の記述だけを頼りに読み解く。
- 誰に向いている？
- 採用を検討すべきなのは、Postgres を共有サーバーなしで試したい個人や、CSV からスキーマを起こす作業を LLM に補助させたい小規模チームだ。逆に、複数人で同じデータベースを同時編集する用途や、認証・権限管理を自前で設計したい本番運用には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 104 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
database.build が埋めるのは「Postgres を試すまでの待ち時間」という隙間
Postgres の挙動を確かめたいだけのときに、いま多くの人は Docker を起動し、イメージを取得し、psql で接続する。この準備そのものが目的ではなく、SQL を書いて結果を見たいだけなら無駄な手順だ。database.build はこの手順を丸ごとブラウザに移す。README によれば、作成できるデータベースの数に上限はなく、それぞれが独立した PGlite インスタンスとして動く。
対象読者は二種類いる。ひとつは SQL や Postgres の機能を手元で試したい開発者。もうひとつは、CSV を取り込んで表を起こし、そのままレポートやグラフを作りたい非エンジニア寄りの利用者だ。README はドラッグ&ドロップによる CSV インポート、レポートの生成とエクスポート、チャート生成、データベース図の作成を LLM と組み合わせた用途として挙げている。つまり単なる SQL 実行環境ではなく、データを読み込ませて形にする作業を想定した作りになっている。
ここで注意したいのは、これは Postgres 公式プロジェクトではないという点だ。README は postgres.new から database.build への改名理由として「公式プロジェクトではないのに誤解を与えたくない」ことを明記している。名前から連想される公式性はないものとして扱うべきである。
ブラウザ内で完結する仕組みと、そこからはみ出す部分
中心にあるのは PGlite だ。Postgres を WASM に変換したもので、これをブラウザ上で起動する。README は「リモートの Postgres コンテナも WebSocket プロキシも存在しない」と述べており、クエリはすべてブラウザ内で実行される。作成したデータベースはそれぞれ新しい PGlite インスタンスを立ち上げ、データは IndexedDB に保存されるため、リロードしても変更が残る。
ただし、すべてがブラウザ内で閉じるわけではない。モノレポは三つのアプリに分かれている。apps/web は Next.js で作られた本体の Web アプリ。apps/browser-proxy は pg-gateway と WebSocket を使い、Postgres の TCP 接続をブラウザ側へ戻すためのプロキシ。apps/deploy-worker はブラウザ内のデータベースをデータベース基盤へデプロイするワーカーで、README の記述では現時点で Supabase のみが対象とされている。
この分割は、ブラウザ内 DB という設計が外部ツールとの接続やデプロイという要求に直面したとき、どこで折り合いをつけているかを示している。TCP を話す既存クライアントから PGlite に到達させるには browser-proxy を経由する必要があり、ブラウザ内のデータを永続的な場所へ移すには deploy-worker が要る。IndexedDB はあくまでブラウザのストレージであり、別のマシンから同じデータベースを開くことはできない。
セットアップはモノレポ前提、turbo を迂回すると壊れる
README の手順はモノレポのルートから始まる。まず npm i で依存を入れ、npx supabase start でローカルの Supabase スタックを起動する。次に npx supabase status -o env に --override-name を付けて api.url を NEXT_PUBLIC_SUPABASE_URL、auth.anon_key を NEXT_PUBLIC_SUPABASE_ANON_KEY に読み替え、その出力を grep NEXT_PUBLIC で絞って ./apps/web/.env.local へ追記する。
LLM を使うには OpenAI の API キーが必要で、OPENAI_API_KEY として同じ .env.local に書き込む。レート制限用の Redis もローカルで動かす必要があり、KV_REST_API_URL に http://localhost:8080、KV_REST_API_TOKEN に local_token という固定値を設定する。README はこの二つについて「正確にこの値を使うように」と指示している。Redis コンテナは docker compose -f ./apps/web/docker-compose.yml up -d で起動し、8080 番で API を提供する。
残りの変数は ./apps/web/.env.example、./apps/browser-proxy/.env.example、./apps/deploy-worker/.env.example の三つを参照して埋める。起動はルートから npm run dev だ。ここで README が重要と明記しているのは、このコマンドが内部で turbo を使い、./packages/* の依存関係を理解して自動ビルドするという点である。turbo を迂回した場合、各 ./app/* が使う前に ./packages/* を手動でビルドしなければならない。
ブラウザ内 DB という設計がそのまま制約になる場面
最もはっきりした制約は、データが IndexedDB に置かれることだ。README は永続化の手段としてこれを挙げているだけで、複数クライアントからの同時接続や、サーバー側でのバックアップについては何も述べていない。ブラウザのプロファイルを消せばデータも消えるという前提で使うべきで、壊れては困るデータの置き場所ではない。
browser-proxy を使えば TCP 経由で接続できるが、これはブラウザが開いている間だけ成立する経路だ。夜間にバッチ処理を走らせる、別のサーバーから定期的に集計する、といった使い方は、この構成の延長にはない。deploy-worker で Supabase へ送り出すのが、その境界を越えるための用意された出口になる。
もう一点、LLM に依存する機能は OpenAI の API キーがなければ動かない。CSV の取り込みやレポート生成、チャート生成、データベース図の作成は README 上で LLM と対になる機能として説明されており、キーを設定しない構成ではこれらの価値が抜け落ちる。SQL を実行するだけのサンドボックスとして使うなら問題ないが、database.build の売りはそこではない。
PGlite を直接使う場合との違い
同じ PGlite の上に何かを載せるなら、PGlite を自分で組み込む選択肢がある。この場合、永続化の方式、スキーマ管理、UI はすべて自分で決めることになり、その自由度と引き換えに、CSV 取り込みやレポート生成、チャート、データベース図といった機能は自分で作る必要がある。database.build はそこを既成の Web アプリとして提供し、加えて browser-proxy と deploy-worker という二つの出口を用意している。
もうひとつの比較対象は、普通の Postgres をコンテナで立てて使う方法だ。こちらは複数接続、バックアップ、権限管理が最初から使える。代わりに、環境を用意する手間と、マシンのリソースを消費する。database.build が短縮するのはこの準備の部分であり、Postgres の運用機能を置き換えるものではない。どちらを選ぶかは、そのデータベースを自分だけが、短い期間だけ使うのかどうかで決まる。
ライセンスと、追いかけるコストの見積もり
ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。Apache-2.0 は商用利用や改変、再配布を許容する寛容なライセンスだが、特許に関する条項や NOTICE の扱いなど、条件の解釈は利用形態によって変わる。ここでは法的助言はできないので、自組織で配布物を作る場合は法務に確認してほしい。
更新コストの面で見ておくべきは、この構成が外部サービスに依存していることだ。LLM 機能は OpenAI の API キーを要求し、デプロイ先は README の記述では Supabase のみ、ローカル開発には Supabase スタックと Redis コンテナが必要になる。追跡すべき変更は、PGlite の WASM ビルド、pg-gateway、Next.js、そしてこれら三つのアプリそれぞれの .env.example が要求する変数の変化である。リリースは取得できていないため、バージョン間の移行手順がどこまで整備されているかは、この材料からは判断できない。
導入を決める前に確かめること
第一に、browser-proxy と deploy-worker の .env.example の中身を開き、そこで要求される外部サービスの認証情報を自分の環境で用意できるか確認する。README はこれらを「各アプリの残りの変数を埋める」とだけ書いており、中身は示していない。ここで詰まると、Web アプリ本体が動いても TCP 接続やデプロイは使えない。
第二に、データの寿命を決める。IndexedDB に置いたデータベースをどれだけの期間保持する必要があるか、消えてよいものかどうかを先に決めておく。長期保持が必要なら、deploy-worker による Supabase へのデプロイを前提に運用を組み立てることになる。
第三に、LLM 機能を実際に使うかを決める。使わないなら OPENAI_API_KEY の設定は不要だが、その場合 database.build を選ぶ理由はブラウザ内で Postgres が動くことだけになる。使うなら、API キーの管理と、レート制限のためにローカル Redis が果たしている役割を本番構成でどう置き換えるかを設計する必要がある。
編集部の結論
採用を検討すべきなのは、Postgres を共有サーバーなしで試したい個人や、CSV からスキーマを起こす作業を LLM に補助させたい小規模チームだ。逆に、複数人で同じデータベースを同時編集する用途や、認証・権限管理を自前で設計したい本番運用には向かない。導入前に確認すべきは、browser-proxy と deploy-worker の .env.example に何が要求されているか、そして deploy-worker が現時点で Supabase 以外を対象にしていないという点である。
コミュニティノート