PostgreSQL向け最良のAIビルダーは制御権を渡す

既存のPostgreSQLデータベースがあると、選定基準は変わります。AIビルダーに試作用のテーブルを数個作らせる話ではありません。生成コードに、すでに重要なデータ、制約、拡張機能、移行履歴、運用手順へのアクセスを与える話です。

2026年に一般的なPostgreSQLへ接続するなら、この4製品ではReplitが最良の出発点です。実際のランタイム、シェル、暗号化されたSecretsがあり、既存のドライバーと移行ツールを使えるからです。アプリをVercelで動かし、Neon、Supabase、または通常の接続文字列で到達できるサービスを使うならv0が僅差で続きます。LovableとBoltは既存Supabaseでは速いものの、それはSupabase向けの経路であり、PostgreSQL全般への対応ではありません。

ただし、どの製品にも本番のowner資格情報を渡し、即興でスキーマを変更させてはいけません。探索を制限し、移行をレビューし、接続動作を明示できる製品を選ぶべきです。見栄えのよい接続ボタンでは、この問題は解決しません。

既存PostgreSQLにも複数の形がある

「既存」の意味で選択は変わります。Supabaseプロジェクト、Neon、プライベートネットワーク内のPostgreSQL、独自型を持つ15年前のデータベースは、同じPostgreSQLでも接続の管理面が異なります。

Lovableは既存Supabaseを選べる直接連携を文書化しています。Boltも接続できますが、新しいClaude Agentプロジェクトの既定はBolt Databaseです。v0はVercel Marketplace経由でNeonとSupabaseを扱い、プロジェクト環境変数も使えます。ReplitはDATABASE_URLを暗号化Secretとして保存し、一般的なPostgreSQLクライアントと移行ツールを動かせるランタイムを提供します。

実務上の選び方は次のとおりです。

• Supabaseの認証、ストレージ、関数、テーブルにWeb画面を付けるならLovable。
• Supabaseを使い、対応するWebスタックとブラウザ作業環境が合うならBolt。
• Next.jsまたはReactをVercelへ出し、Marketplace連携か通常の接続文字列を使うならv0。
• 任意のPostgreSQL、独自サーバー、生成バックエンドの直接確認が必要ならReplit。

接続とスキーマ探索は別です。public.customersを読めても、部分インデックス、遅延制約、行レベルセキュリティ、トリガー、ドメイン、安全なビューを理解しているとは限りません。接続ボタンは資格情報の受け渡しと考え、探索は別にテストします。

総合ではReplit、ただし限界もある

Replitはホスト型開発環境に近く、既存DBへの自由度が最も高い製品です。コードのインポート、既存パッケージの導入、Secrets、シェルでのSQLと移行、生成ファイルの確認、サーバープロセスのデプロイができます。DBがMarketplace製品でない場合、この自由度が効きます。

2位はv0です。2026年のプロジェクトモデルはチャットをVercelプロジェクトへ結び、暗号化変数をプロジェクト単位で持ち、以前のブラウザプレビューより本番に近いsandboxでサーバーコードを実行します。対応連携ではSQLも生成、実行できます。Next.jsアプリをDBの周りに作るのは得意ですが、Vercel、Next.js、そこで提供されるプロバイダーへ寄ります。

LovableとBoltは、対象が既存Supabaseなら初日から快適です。認証やデータフローの文脈が得られますが、その外では手動設定が急増します。Lovableの外部ホスティング文書も、PostgreSQL単体ではSupabaseの認証、ストレージ、realtime、edge serviceを置き換えられないと説明しています。Postgres URLだけでバックエンドが交換可能になるわけではありません。

任意のURL、独自の検査、プール制御ではReplitが優位です。リポジトリと既存移行ツールを正とできます。一方、Secretsは環境変数としてコードへ届くため、出力内容と受け取るプロセスを監視する必要があります。

v0もサーバーからDBへ到達できれば柔軟です。インポート済みリポジトリ、Vercel変数、対応連携の組み合わせが強みです。ただし移行レビューと接続予算はチームの仕事です。

BoltとLovableは既存Supabaseへの直結で勝ります。設定は少なくても、生成されたスキーマ変更のレビューは必要で、プーリングは主にプロバイダー依存です。Supabase以外では手動設計が増えます。

安全な開発コピーがない場合も評価は変わります。Replitとv0は任意URLへ向けやすいので、むしろ権限を厳しくすべきです。狭い連携も権限が狭くなければ安全ではありません。製品分類はgrant、監査ログ、隔離DBの代わりになりません。

Replitの自由は正しい構成にも誤ったコマンドにも使えます。BoltとLovableは設定を減らしますが、サービス境界を隠す場合があります。v0の便利な変数伝播も、強すぎる資格情報をpreviewへ渡す可能性があります。

スキーマ探索は制限ロールから始める

移行やバックアップの資格情報ではなく、メタデータと選択した開発データだけを読める専用ログインを渡します。最初の処理はレビュー用インベントリの作成だけです。生成コードに合わせてテーブルを変更させません。

移植可能な構造はinformation_schema、PostgreSQL固有のインデックス、policy、extension、制約はpg_catalogで確認できます。表名と列名だけでは不十分です。schema、table、view、主キー、外部キー、unique constraint、index、enum、domain、生成列、trigger、row policy、trigger関数、extensionを報告させます。

破棄できるbranchまたはstagingで探索ロールを作り、schema名とgrantを調整します。

CREATE ROLE builder_reader LOGIN PASSWORD 'replace-at-secret-store';
GRANT CONNECT ON DATABASE app_staging TO builder_reader;
GRANT USAGE ON SCHEMA app, reporting TO builder_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA app, reporting TO builder_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA app
  GRANT SELECT ON TABLES TO builder_reader;

パスワードをチャットへ貼らず、Replit Secrets、v0変数、LovableまたはBoltのプロバイダー設定へ置きます。ソースは環境からDATABASE_URLを読みます。生成ファイルにURLが入ったら削除し、資格情報をローテーションし、履歴を確認します。

インベントリは人が確認します。ビューはアプリに許した列だけを見せる場合があります。usersは認証システムの内部テーブルかもしれません。トリガーが監査表を更新し、生成された一括処理が必要なセッション変数を設定する業務経路を迂回することもあります。探索で分かるのは存在であり、所有権ではありません。

独自コマンドが必要ならReplitが最も容易で、v0も連携やterminalで対応できます。Supabase内ではLovableとBoltが文脈を持ちますが、明示的なインベントリと管理下の移行ファイルを比較すべきです。

生成品質より移行管理が重要

有用なbuilderは通常のpipelineでレビュー、適用できる移行ファイルを書きます。危険なbuilderはSQLの成功を本番適用の根拠にします。

移行の正は一つにします。Prisma Migrate、Drizzle Kit、Flyway、Liquibase、Alembic、Rails、番号付きSQLのどれを使っていても同じ仕組みを使わせます。Dashboard変更、ORM自動同期、生成SQLフォルダーを競合させると、復元や新環境でずれが表面化します。

Lovableの文書はsupabase/migrations/をtimestamp順に実行すると明記しています。よい仕組みですが、安全性の保証ではありません。policy、function、trigger、破壊的SQLを読みます。Boltでも同様です。v0ではchat履歴だけでなくリポジトリに残し、Replitではコマンド、ファイル、diffを提示させます。

資格情報を分けます。

DATABASE_URL=postgresql://app_runtime:[email protected]/app
MIGRATION_DATABASE_URL=postgresql://app_migrator:[email protected]/app

runtimeロールは必要な操作だけ、migratorは承認済みオブジェクトの変更だけを行います。後者は移行jobだけに渡します。隔離DBへレビュー済み移行を適用する場合を除き、previewへMIGRATION_DATABASE_URLを渡しません。

よくある失敗では、previewの列不足をowner URLで直接直し、ORMだけ更新します。previewは直りますが移行ファイルはありません。新しいDBでは古いスキーマから作られてbuildが失敗します。本番を直接変えていればrollbackは記憶とlog頼みです。アプリは偶然の一状態でしか再現できません。

Secret保存だけでは安全にならない

4製品とも直書きを避けられますが、重要なのはSecretが読める場所です。保存時に暗号化されても、実行プロセスは値を受け取り、生成コード、build log、browser bundle、debug endpoint、agent commandが漏らす可能性があります。

Replit文書はSecretsが環境変数になり、DATABASE_URLを含むと説明し、コードが環境変数を表示できるとも警告します。v0も変数を暗号化してVercelと共有します。NEXT_PUBLIC_はクライアント用なのでDB資格情報には絶対に付けません。

Supabase上のLovableとBoltでは、公開クライアント設定と特権サーバー資格情報を分けます。公開キーはrow policyが効く場合にだけクライアントで使えます。service roleや直接URLはサーバー専用です。生成queryを直すためrow securityを無効化すると、ブラウザ利用を許した制御自体が消えます。

local、preview、test、staging、productionで資格情報を分け、previewには合成または除染データを使います。共有schemaよりDB branchが安全です。最初のprompt前に、誰がpasswordを変え、各環境のどこに置き、何を再起動するか決めます。

exportには変数名と設定説明だけを含め、値は含めません。Koder.aiはsource export、deployment、hosting、snapshot、rollbackをサポートします。同じ原則でSecretをsource外に置き、変更をレビューします。製品snapshotはPostgreSQL backupや検証済み移行rollbackの代わりではありません。

Connection poolingはアプリ設計の仕事

安全なpool sizeはpromptだけでは決まりません。DB上限、instance数、deployment concurrency、transaction時間、PgBouncerなどのproxyで変わります。

各instanceが10接続を開き20instanceになれば、jobや移行の前に200接続です。providerは待機または拒否します。上限を増やすだけでは症状しか直らず、memoryを消費します。

pooled endpointとdirect endpointを分けます。通常アプリはpoolを使い、session state、advisory lock、特別なDDLが必要な移行はdirectを使う場合があります。transaction poolingはsessionが続く前提のコードを壊します。prepared statementもdriverとpoolerの整合が必要です。

既定値任せにせずコードへ制限を書きます。

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: Number(process.env.DB_POOL_MAX ?? 5),
  idleTimeoutMillis: 20_000,
  connectionTimeoutMillis: 5_000,
  ssl: { rejectUnauthorized: true }
})

値は例です。運用用接続を除き、残りを最大instance数で割り、deployment重複分を残します。providerのTLS検証方法を確認します。previewが失敗したからrejectUnauthorized: falseにするのは危険です。

Replitはdriverと常駐serverを直接制御できます。v0もコード制御はありますが、Vercelのscaleには明示的上限とserverless対応providerが必要です。BoltとLovableはSupabase側のpoolingを使うことが多いものの、URLの種類、ORM対応、移行用endpointの確認は残ります。

手動設定で本当の差が見える

公平な試験では同じstaging DB、schema brief、受入テストを使います。一方のmanaged wizardと他方のprivate legacy clusterへの手動接続を比べて、知能差とは呼べません。

Replitではアプリをimportまたは作成し、stagingのDATABASE_URLをSecretsへ置き、既存driverと移行ツールを入れ、コード生成前にinventoryを求めます。private networkだけなら接続経路を先に確認します。Replitの自由度はfirewallを越えません。

v0では正しいVercel projectへchatを接続し、対応するMarketplace連携かproject変数を使います。development、preview、productionへ届く変数を確認し、移行があるrepositoryをimportし、既存data layerを保持させます。

Boltでは作成時にSupabaseを選ぶか既存projectを接続します。現行文書ではSupabase接続はVite向けでNext.js非対応です。汎用PostgreSQLならserverまたはAPI境界を手動で用意します。

LovableではSupabase組織とprojectを接続し、client、policy、function、migrationをレビューします。汎用PostgreSQLでは他のSupabase機能を置き換えるAPIまたはserverが必要で、その接続は自分の設計になります。

ネットワーク到達性は別に試します。subnet、VPN、固定IP限定のDBはhosting previewを拒否します。公開Internetへ開けず、private connector、内部API、一時branch、既存接続環境へのdeploymentを選びます。使えないbuilderは非対応と判断します。

古いschemaではnumeric、timestamptz、jsonb、enum、array、nullable foreign keyを読み書きさせます。JavaScript driverは精度維持のため大きな整数や小数をstringで返すことがあります。Number()変換はDB errorなしでIDや金額を壊します。timezone offsetを消すUIも同様です。

所有境界も試します。アプリschemaのtable、reporting view、runtimeから読めない内部tableを用意します。最初の二つを使い、三つ目の拒否を権限拡大なしで扱うべきです。GRANT ALLと答えたら試験を止めます。権限errorは境界が働く証拠です。

隔離DBで移行を途中失敗させます。良いflowは明確なerrorを残し、未適用を完了扱いせず、移行systemで修正できます。多くのDDLはtransaction内で動きますが、concurrent indexなどには特別な規則があります。promptではなく移行ツールが実行を決めます。

再現可能な受入手順です。

1. 探索資格情報で、trigger、非公開schema、index、row policyを含むinventoryを作る。
2. nullable列とindexなどの追加移行を既存形式で生成し、隔離branchへの適用前にレビューする。
3. runtime roleで読むpageと、許可された1件を書くserver actionを作り、browserへ特権を渡さない。
4. 同時requestでpool metricsを見て、instance数とpool sizeの積を予算内にする。
5. sourceとmigrationから新環境を構築し、preview passwordをrotateして旧passwordが失敗することを確認する。

この試験で、DBを理解しているのか、特権URLが誤りを隠しているだけか分かります。

本番アクセスは狭いゲートを通す

通常の開発でagentを本番へ直結しません。除染済みbranchまたはsnapshotを渡し、レビュー済みcodeとmigrationを既存deployment経路で送ります。

ゲートには4確認が必要です。人がSQLと権限をレビューし、自動testがmigrationから空DBを作り、releaseが専用資格情報で移行してversionを記録し、monitoringが接続飽和、slow query、lock wait、application errorを見ます。

rollbackはcode、schema、dataで別に考えます。codeはすぐ戻せても列削除は情報を失います。互換列を追加し、両状態対応codeを出し、batchでbackfillし、読み取りを切り替え、後のreleaseで旧形式を消すexpand and contractが安全です。builderは生成し、release processが時期を決めます。

Replit checkpointはcodeとmanaged DBを保存でき、Koder.aiもsnapshotとrollbackを提供します。開発には役立ちますが、外部PostgreSQLのnative backup、point in time recovery、検証済みrestoreを置き換えません。復旧責任はDB運用者にあります。

規制でデータ場所が限られるなら接続前に解決します。builder、app host、DB、log、backup、support accessは別の境界を越えます。地域内deploymentだけではDBやprompt contextが残った証明になりません。各systemと見えるdataを記録します。

制約を受け入れるbuilderを選ぶ

幅広い既存PostgreSQLにはReplitです。driver、ORM、migration framework、server process、検査commandを持ち込めます。その代わりdiffを読み資格情報を制限する担当者が必要です。

Vercel上のReactまたはNext.js、特にNeonやSupabaseならv0です。project変数、DB連携、repository import、server previewによりUI生成だけではないDB clientになります。環境scopeとserverless接続を早く検証します。

既存Supabaseが中心ならBoltまたはLovableです。auth、table、storage、functionの配線を減らせますが、任意PostgreSQLへ一般化できません。Boltの対応stackとLovableのSupabase依存により、単純に見える接続が手動backend作業になる場合があります。

2製品が合格したら生成速度ではなく保守性で選びます。誰がdeploy失敗を調べ、serverを直し、localでmigrationを実行し、codeを移せるか確認します。project複製がdataやsecretなしで設定を保つか、新担当者がrepositoryから再構築できるかも見ます。DBはfrontendの流行より長く残ります。元のchatとprompt作成者がいなくても理解できるアプリにします。

owner URL、記録されないDDL、row security無効化、client内資格情報、空DBの再構築失敗のどれかが必要なら不合格です。後で直す小さな問題ではなく、builderがDBの運用規則を受け入れていない証拠です。