SupabaseがTursoを買収、エージェントはタスクごとにデータベースを必要とするため

Supabaseは10月2日、1億5000万ドルを調達し、SQLiteベースのデータベース企業Tursoを買収すると発表した。ラウンドはシンガポールのGICが主導し、Alphabetの成長ファンドCapitalG、IronArc、SquarePegが参加した。買収価格は非公開であり、資金調達の発表を買収価格と解釈すべきではない。

この取引の根底にあるアーキテクチャ上の賭けが興味深い部分だ。Supabaseは、単一の一貫したストアを共有するアプリケーション向けに設計されたリレーショナルシステムであるPostgresを中心に事業を築いてきた。TursoはSQLiteをゼロから書き直して単一ライター制約を取り除き、書き込み前ログをS3に置くディスクレスアーキテクチャで提供した。その結果、エージェントごとにオンデマンドでプロビジョニングでき、1台ずつマシンを起動するコストのほんの一部で済むデータベースが生まれた。

Supabaseが挙げる数字

Supabaseによると、現在は毎月100万人以上のユーザーと約400万個のデータベースを追加している。プラットフォーム上の新規データベースの約70％はエージェントまたはAI駆動ツールによって作成されていると報告している。6月にはデータベース数が前年比600％増加したと報告し、新規デプロイの大半はすでにエージェントによるものだと述べた。同社は1300万人以上の開発者がプラットフォームを利用しているとしている。

これらは企業が報告した導入指標であり、データベース作成は売上や継続率と同じ指標ではない。エージェントがタスクのために立ち上げ、1時間後に放棄したデータベースも、その月間合計には依然として含まれる。これらの数字が示しているのは需要曲線の形だ。作成されるデータベースの量は、それを作成する人間の数よりも速く増えており、これはまさにアプリケーションごとのデータベースモデルがひずみを迎えているシグナルである。

エージェントごとに1つのデータベースが従来の算術を壊す理由

インフラストラクチャの単位が変わりつつある。人間の開発者がアプリケーションを構築する場合、1つのデータベースが多くのユーザーにサービスを提供し、そのプロビジョニングコストは長期間存続するプロジェクト全体に償却される。エージェントがタスクを実行する場合、状態、メモリ、中間結果のための専用のスクラッチストアが必要になることがあり、しかもそれを数分間だけ必要とするかもしれない。

従来のマネージドデータベースモデルでエージェントごとにインスタンスをプロビジョニングすることは、その規模では機能しない。サーバーを割り当て、設定し、課金するオーバーヘッドは、その中で実行される小さなワークロードの価値をはるかに上回る。Tursoの売りは、データベースの作成コストとアイドル状態の維持コストをほぼゼロにし、100万個を起動することが会計上のイベントではなく通常の操作になるべきだという点にある。

SupabaseがTursoの顧客リストとして挙げているのは、Superhuman、CTO.new、Sauna.ai、Mastraなどだ。Tursoの創業者Glauber Costaは、共同創業者のPekka Enbergと他のチームメンバーとともに、SupabaseにAgentic Services責任者として加わる。

すでにTursoを利用している人には、注目すべき細部が1つある。同社の初期のlibSQLフォークと新しいRustエンジンは異なる実装であり、両者の機能セットは同じではない。Tursoは2025年1月の書き直し発表でこの移行を説明した。チームは、マーケティングページに記載された機能が本番環境で利用可能だと想定する前に、自身のデプロイがどのエンジンで動作しているかを確認すべきだ。

これが狙う競争相手

この買収は、Supabaseが何と競合しているかも明確にする。有料提供には認証、ストレージ、エッジ関数、リアルタイムサブスクリプション、ベクトル検索が含まれ、単一のデータベースベンダーではなく、マネージドバックエンド市場でFirebase、MongoDB Atlas、AWS Auroraと競合する位置づけになる。

これらはそれぞれ、エージェント層で異なる弱点を抱えている。Firebaseは開発者をドキュメントモデルとGoogleのクラウドに縛り付ける。MongoDB Atlasはデータを柔軟にモデル化するが、エージェント作業の単位ではなくクラスターに対して課金する。Auroraは強力だが小規模では高価で、数分間だけ存在するタスクには合わないプロビジョニングを伴う。

Tursoの貢献は、可能な限り最小のストレージ単位だ。同時書き込み、ネイティブのベクトル検索、ブラウザ内実行に加え、デバイスとクラウド間の組み込みレプリケーションを提供する。最後の機能は、ユーザーのマシン上で部分的に動作するクラスのアプリケーションにとって重要であり、クラウドデータベースへの往復はその問題にとって適切な形ではない。

卒業パスが商業的メカニズムだ。1つのSQLiteデータベースとして始まり、本格的なアプリケーションへと成長したプロジェクトはPostgresへ移行し、それとともに有料プランへ移る。Supabaseの主張は、エージェントがプロジェクトを作成した瞬間に獲得する方が、後から開発者を獲得するよりも安くつくというものだ。

資金調達の歴史そのものがシグナル

このラウンドは、Supabaseが2026年6月に5億ドルのシリーズFを完了した4か月後に実施された。そのラウンドはポストマネーで105億ドルの評価額をつけ、同じくGICが主導した。その前には2025年10月に50億ドル評価で1億ドルのシリーズEがあった。調達総額は現在10億ドルを超えている。

これほど早く再び調達したことは、同社が資本か話題のどちらかを求めていたことを示唆しており、発表によればラウンドの一部は従業員の流動性を提供する。この段階で従業員向けのセカンダリー要素があるのは普通であり、企業が実際に投入する運転資金とは分けて考える価値がある。

戦略的な論理は財務的な論理よりも明確だ。Supabaseは、プロジェクトにバックエンドが必要になったとき、開発者やエージェントが最初に頼る場所になりたいと考えている。そのプロジェクトの最初期バージョンがエージェントによって作成された小さなSQLiteデータベースであるなら、作成の瞬間を所有することは、競合他社がそのプロジェクトを目にする前に関係を所有することを意味する。そこからSupabaseは、アプリケーションが軽量層を超えて成長したときに標準Postgresへの卒業パスを提供する。Tursoはプラットフォームとして稼働を続け、そのコードベースはオープンソースのままとなる。

統合のパターン

Supabaseだけがこの動きをしているわけではない。Restateは今月、長時間実行されるエージェントワークフローがタスク途中で失敗しないようにする耐久性インフラのために、Singularが主導する2000万ドルのシリーズAを調達した。LlamaIndexはエージェントのデータパイプライン向けに、スキーマベースの文書抽出ツールを出荷した。これらの取引に共通するテーマは、エージェントの下にある配管がカテゴリーになりつつあり、以前は後回しにされていた部分に今や資金が集まっているということだ。

開発者にとって実用的な疑問は、何が変わるのかということだ。既存のSupabaseユーザーには違いは見えないと伝えられており、これは現在1つの屋根の下で2つのエンジンを動かすプラットフォームにとって正しい答えだ。より重大な変化はデフォルトにある。PostgresとSQLiteの両方が同じエコシステム内に存在するなら、両者の選択はベンダーではなくワークロードの形に関する決定になり、安価な選択肢は調達サイクルを経た後ではなく、エージェントが必要とした瞬間に利用可能になる。

未解決なのは、経済性が成り立つかどうかだ。エージェントごとのデータベースモデルは、ストレージ、プロビジョニング、サポートのコストが顧客の支払う価格を下回り、かつそれらのデータベースの十分な数が有料の本番ワークロードへと成長する場合にのみ成立する。Supabaseは、答えはイエスであり、保持する価値のあるプロジェクトは小さく始まるという賭けに出ている。