8月11日、Databricksが「Electric joins Databricks to bring WASM Postgres to AI agent sandboxes」と題した記事を公開した。DatabricksによるElectricチームの買収を発表するもので、WASM版PostgresをAIエージェントのサンドボックス環境に持ち込む新しいデータ基盤の構想が詳しく説明されている。
なぜ従来のDBがエージェントに合わないのか
従来のアプリケーションはクエリパターンが事前に決まっており、1つのマネージドPostgresで十分機能する。しかしAIエージェントは次の3点で従来とは異なる。
- 実行時にデータを自律的に決定する：エージェントは次の行動を秒単位で判断し、コンテキストを高頻度で更新する。内部ループはプロセスと同一場所にデータが欲しく、出力結果は耐久性のあるストアに書き込みたい。
- サンドボックス環境で動く：データベースはネットワーク経由でしか届かない隔離環境が前提になりつつある。
- 複数エージェントが協調する：高速なローカルコンテキストと、他エージェントの作業状況を共有する仕組みの両方が必要だ。重複作業や古い状態での判断、矛盾した結論を避けるためである。
PGlite——エージェントの中で動くPostgres
ElectricチームはこのギャップへのアンサーとしてPGliteを開発した。WebAssembly（WASM）を使ってPostgresをコンパクトなバイナリに収め、エージェントサンドボックス、ブラウザタブ、ユーザーデバイスの中で直接動作させる。別サーバーは不要だ。
PGliteの週間ダウンロード数は12ヶ月で100万から1300万に成長した（元記事公開時点の数字。起点・終点の具体的な日付は元記事を参照）。
なお、PGliteのWASM Postgres基盤はStas Kelvich（Neonの共同創業者）による先行研究をベースにしており、Electricチームがそれをプロダクションレベルのライブラリへと昇華させた。今回の買収でその2つの流れが合流する形になる。
Lakebase + PGlite + 同期エンジンの三層構造
DatabricksがElectricチームの買収と合わせて描くアーキテクチャは以下の三層だ。Electricが開発したPGliteとリアルタイム同期エンジンを、Databricksの**Lakebase**（マネージドPostgresサービス）と統合することで、AIエージェント向けのデータ基盤を構築するのが狙いである。
| 層 | 技術 | 役割 |
|---|---|---|
| クラウド中央 | Lakebase（マネージドPostgres） | 耐久性・ガバナンス・スケール |
| エージェント内 | PGlite（WASM Postgres） | 超低レイテンシなローカルコンテキスト |
| 同期 | Electricリアルタイム同期エンジン | 両者の一貫性を維持 |
ElectricのリアルタイムSync技術はGoogle DocsやFigma、Notionのような共同編集アプリで採用されているアーキテクチャと共通する。これをエージェント群の状態同期に転用するのが本構想の核心だ。
開発者にとっての実際のメリットは：
- 単一のPostgres標準でエージェントアプリを構築できる
- エージェントのサンドボックス内でPostgresを直接実行し、高速に動かせる
- エージェント間のコンテキスト共有が即時に行われ、制御はLakebase側に集中できる
背景：Neonとの関係
記事中で言及されているNeonは、サーバーレスPostgresとして知られるプロジェクトで、PGliteのWASM基盤の一部はNeon共同創業者Stas Kelvichの研究に由来する。Databricksは今回の発表に合わせてNeonブログでも関連記事を公開しており、ElectricとNeonの技術的なつながりも明確にしている。
AIエージェントを複数並列稼働させながらデータの一貫性を保つという課題は、業界全体でまだ解法が固まっていない領域だ。DatabricksがPostgresを「クラウド中央」から「エージェント内部」まで貫く一本の軸として位置づけようとしているのは、この記事から読み取れる最も重要なポイントだろう。
詳細はElectric joins Databricks to bring WASM Postgres to AI agent sandboxesを参照していただきたい。
