Netlify Databaseとは?AIエージェント時代の統合Postgresを解説

Netlifyが2026年4月、正式版の「Netlify Database」を発表しました。約1年間続いた「Netlify DB」ベータの後継にあたる機能ですが、単なる「Postgresを置けるようになった」という話ではありません。

結論から言うと、Netlify Databaseの本質は「デプロイのたびに使い捨てのデータベース環境が自動でできる」という点にあります。コードのDeploy Previewと同じ感覚で、データベースも安全に試せるようになった、というのが一番のポイントです。

Netlify Databaseとは

Netlify DatabaseはNetlifyプラットフォームに組み込まれた、フルマネージドのPostgresデータベースです。内部的にはサーバーレスPostgresを提供するNeonの技術基盤を使っていますが、プロビジョニングやマイグレーション、ブランチ管理まですべてNetlify側が面倒を見てくれるため、利用者がNeonのダッシュボードを直接操作する必要はありません。

利用できる実行環境は幅広く、Netlify Functions、Edge Functions、ビルド処理、そして後述するAgent Runnersからアクセスできます。つまり、サーバーサイドの処理だけでなく、AIエージェントによる開発フローの中にもデータベースが自然に組み込まれている、というのが特徴です。

Netlify DB(ベータ)からの変更点

ベータ期間中は、あくまで「データベースを手早く用意できるショートカット」という位置づけでした。作成したデータベースを7日間を超えて使い続けたい場合、利用者自身のNeonアカウントに移管する必要がありました。

正式版では、この「移管が必要」という制約がなくなり、Netlifyが最初から最後までデータベースの面倒を見る形に変わっています。ベータ期間中には40万件を超えるデータベースが作成されたそうで、その実績を踏まえたうえで「単に用意するだけ」から「一つのワークフローとして提供する」方向に舵を切った、という経緯です。

何が課題を解決するのか:DBブランチという発想

AIエージェントを使ったアプリ開発では、コード側はDeploy Previewのおかげで安全に検証できるようになっていました。一方でデータベースは、多くのサービスで「本番」と「開発用」の2環境程度しか用意されておらず、次のような問題が残っていました。

• 複数の機能を同時に試したいとき、DBの変更がぶつかり合う
• チームで共有しているステージングDBが、誰かの変更でいつの間にか壊れている
• DBのロールバックはコードのロールバックよりずっと面倒

Netlify Databaseは、この課題に対して「DeployPreviewごとに専用のDBブランチを割り当てる」という形で応えています。各ブランチは作成時点の本番データを引き継ぎつつ、そのブランチ内で行ったスキーマ変更やデータの追加・削除は、他のブランチや本番環境には一切影響しません。

実際のワークフロー:AIエージェントはどう使うのか

公式に説明されているワークフローを整理すると、次のような流れになります。

1. Netlifyの Agent Runners で Claude Code、Codex、Geminiなどのエージェントを起動する
2. エージェントがそのプロジェクトにデータベースが必要かどうかを判断し、必要であれば自動でプロビジョニングする
3. 実行ごとに専用のDBブランチが作られ、本番データをベースにしつつ変更内容はそのブランチ内に閉じる
4. エージェントがコードを生成する過程で、必要なスキーマ変更をマイグレーションファイルとして出力する
5. Deploy Previewをビルドする際、そのマイグレーションが自動的に該当ブランチへ適用される(本番環境は変更されない)
6. Previewを実際に触って動作確認ができる。ここで行ったデータの追加・削除・変更もブランチ内だけで完結する
7. 内容を確認し、本番へ反映すると判断した場合のみ、そのマイグレーションが本番データベースに適用される

ポイントは、エージェント自身が本番データベースを書き換えられる権限を持っていない、という設計です。「レビューして初めて本番に反映される」という順序が、仕組みとして強制されています。

開発者向けの使い方(Git連携・Drizzle ORM)

AIエージェント任せにせず、自分でコードを書く開発者向けの導線も用意されています。@netlify/database というnpmパッケージを依存関係に加えてデプロイすると、Netlifyが自動的にそれを検知してデータベースを用意します。このパッケージは実行環境に応じて最適な接続方法を自動選択するドライバーの役割も兼ねています。

Gitのブランチ・プルリクエストを作成すると、それに対応するDBブランチも自動的に作られます。マイグレーションファイルを使っていれば、PreviewのビルドやProductionへの反映のタイミングで自動的に適用されるため、特別なツールを別途動かす必要はありません。Drizzle ORMとそのマイグレーションツールである drizzle-kit も公式にサポートされており、TypeScriptでスキーマを管理したいプロジェクトとは相性が良さそうです。

料金体系

Netlify DatabaseはCredit-basedプラン全体で利用できます。レガシープランを契約している場合は、利用する前にプラン変更が必要です。

課金される項目は主に次の2つです。

契約しているプランによって、作成できるデータベース数、ブランチ数の上限、自動バックアップの保持期間などが変わります。並列でエージェントを多数走らせる運用を検討している場合は、ブランチ数の上限がボトルネックにならないか事前に確認しておくと安心です。

料金体系や上限は変更される可能性があるため、契約前には必ずNetlify公式の料金ページで最新情報を確認してください。

ベータ版データベースからの移行

ベータ期間中に作成したデータベースは、利用者自身のNeonアカウントに紐づいているため、Netlify側が勝手に変更することはできません。そのまま使い続けても問題なく動作し、強制的な移行や機能停止、追加課金が発生することもありません。

一方で、新規に作成するデータベースはすべて正式版のNetlify Databaseとして扱われます。ベータ版から正式版への切り替えを希望する場合は、公式の移行ガイドに沿って手動で切り替える必要があります。

メリット・デメリット

Netlify Databaseが向いている人・向いていない人

向いている人

• Claude CodeやCursorなどのAIエージェントで、フルスタックのアプリやプロトタイプを量産したい人
• すでにNetlifyでフロントエンドをホスティングしていて、バックエンドとDBもまとめて一元管理したい人
• 複数の機能案を同時に検証し、Preview URLを関係者に見せながら意思決定したいチーム

向いていない人

• すでにNeonや他のPostgresサービスで本番運用しており、移行コストをかけたくない人
• Netlify以外のホスティング環境をメインに使っていて、Netlify Database単体だけを導入したい人
• Neonの高度な機能(細かいロール設定など)を直接操作したいエンジニア

よくある質問(FAQ)

Netlify Databaseを使うのにコーディングの知識は必要ですか?

必須ではありません。AIコーディングツールやエージェントに要件を伝えると、データベースが必要かどうかをエージェント側が判断し、セットアップまで自動で行ってくれます。もちろん、Gitベースで自分でスキーマやマイグレーションを管理することもできます。

どんなアプリにデータベースが必要になりますか?

ECサイト、予約アプリ、顧客ポータル、社内ダッシュボード、健康管理アプリなど、何らかの情報を保存・呼び出しする必要があるアプリ全般が対象です。逆に、静的なコンテンツだけで完結するサイトであれば不要な場合もあります。

Netlify DatabaseはどのPostgresエンジンをベースにしていますか?

サーバーレスPostgresを提供するNeonの基盤を利用しています。ただし、セットアップから運用までをNetlifyが一貫して管理する形になっているため、Neon側を直接操作する必要はありません。

AIエージェントが本番データを壊してしまうことはありませんか?

各エージェントの実行は、それぞれ独立したDBブランチの中で行われます。人間が内容を確認し、本番への反映を承認するまでは、本番データベースに変更が及ぶことはない設計になっています。

ベータ版で作ったデータベースはどうなりますか?

そのまま利用を続けられます。強制的な移行や機能停止、追加課金は発生しません。正式版に切り替えたい場合のみ、公式の移行ガイドに沿って手動で作業する必要があります。

詳しい料金プランの比較についてはNetlify料金プラン完全ガイド、Claude CodeやCursorとの具体的な連携手順についてはNetlify × AIコーディングツール連携ガイドでそれぞれ解説しています。

まとめ

Netlify Databaseは、これまでコードにしか適用されてこなかった「Deploy Previewによる安全な実験環境」を、データベース層にまで広げた機能です。AIエージェントがスキーマ変更を含むフルスタックのコードを書く時代において、DBブランチが自動で分離される仕組みは、事故を防ぐうえで大きな意味を持ちます。

一方で、自動マイグレーションや本番反映の判断を完全にエージェント任せにしてよいわけではありません。破壊的な変更のレビューや、ブランチ数・コストの管理といった部分は、引き続き人間側の役割として残ります。「AIに自由に試させる範囲」と「人間が最終判断する範囲」を最初に線引きしておくことが、Netlify Databaseを事故なく活用するコツだと感じます。