SupabaseはTurso買収で何が変わる？

SupabaseのTurso買収で何が変わる？

現時点で確定しているのは、TursoのチームがSupabaseに加わり、両社がデータベースの選択肢を広げることです。SupabaseはPostgresを中心とする開発基盤を続け、TursoもSQLiteを中心とするサービスとオープンソース開発を継続すると説明しています。既存アプリのデータベースが自動的に移行されるわけではありません。[1][2]

確認項目	2026年10月3日時点	実務上の意味
Supabaseの中核	Postgresを継続	既存プロジェクトを急いで変える必要はない
Tursoの中核	SQLiteとlibSQLを継続	エッジや分離DBの用途を引き続き試せる
両者の統合	将来構想として提示	本番採用は提供日とSLAの確認後が安全
買収条件	金額は非公表	財務条件を推測しない

独立報道では、Supabaseが同日に1億5000万ドルを調達し、Tursoを買収すると伝えられました。ただし、買収額は明らかにされていません。資金調達の大きさは開発余力の参考にはなりますが、個別機能の完成時期を保証するものではありません。[3]

なぜ「1エージェント1DB」が必要なのか？

従来の業務アプリでは、複数ユーザーや機能が一つの大きなデータベースを共有する設計が一般的でした。AIエージェントでは、長時間動く処理が独自の履歴、作業途中の状態、取得した資料を持ちます。全エージェントを同じ領域に入れると、権限の境界や削除範囲が複雑になります。

Tursoは、エージェントごとに独立したデータベースを割り当てる「database-per-agent」を提案しています。分離単位が明確なら、あるエージェントのデータを削除しても別のエージェントへ波及しにくく、検証環境の複製もしやすくなります。Tursoは週100万件を超えるデータベースが作成されていると説明しており、この大量分離が買収の技術的な背景です。[1][4]

導入効果を読む際は、事例の出どころにも注意が必要です。Tursoが公開したCTO.newの事例では、数万のAIエージェントを調整し、5万人の利用者に対してデータベース費用を月500ドル程度に抑えたとされています。これはベンダー掲載事例であり、すべての構成で同じ費用削減が再現される証拠ではありません。アクセス量、保存容量、書き込み頻度を自社条件で試算する必要があります。[5]

SQLiteとPostgresはどう使い分ける？

買収後も「どちらか一方へ統一する」という説明ではありません。SQLiteはアプリやエージェントの近くに小さく配置しやすく、Postgresは複数機能をまたぐ検索、権限、分析、業務データの集約に向きます。Supabase自身も、TursoのSQLiteとSupabaseのPostgresを異なる規模で使い分ける構想を示しています。[1]

判断軸	Turso／SQLiteを試しやすい場面	Supabase／Postgresを維持しやすい場面
データの単位	エージェント、顧客、端末ごとに分離	組織横断で同じデータを参照
配置	利用者や処理の近くで低遅延を狙う	一元管理と複雑な問い合わせを優先
権限	DBそのものを境界にする	行レベル権限や認証と組み合わせる
運用	小さなDBを大量に作成・破棄	監査、バックアップ、分析を集約

注意点は、SQLiteからPostgresへ成長させる自動移行の仕様がまだ公開されていないことです。Turso側は将来、SupabaseやMultigresへの道筋を示していますが、スキーマ変換、型の差、トランザクション、停止時間の条件は未確定です。最初から「あとで無停止移行できる」と想定せず、検証用データで移行手順を作っておくのが安全です。[2]

既存のSupabase導入方法を確認したい場合は、Supabase初心者ガイドも参考になります。AIエージェントから外部ツールへ接続する設計では、データベースの分離だけでなく、MCPのセキュリティ設計も併せて確認してください。

料金と提供条件はどうなる？

統合後の料金は未発表です。比較できるのは、それぞれが現在公開しているプランだけです。Tursoの月額表示ではFreeが0ドルで最大100データベース、Developerが5.99ドルでデータベース数無制限、Scalerが29ドルでデータベース数無制限です。読み書きや保存容量の上限はプランごとに異なります。[6]

サービス	現在確認できる課金単位	買収後に未確定の点
Turso	プラン別の保存量、読み書き、機能	Supabase契約との統合、超過単価の変更
Supabase	組織のプランとプロジェクト、従量利用	Turso DBがプロジェクト枠に入るか
移行	現時点では個別設計	移行支援、データ転送、停止時間

Supabaseは組織単位でプランを管理し、コンピュートやストレージなどの利用量に応じて料金が加わる仕組みです。したがって「Tursoが月5.99ドルだから、Supabase内でも同額で使える」とは判断できません。正式な統合プランが出るまでは、両サービスを別契約として見積もるのが妥当です。[7]

Supabase Selectの新機能とどうつながる？

買収発表の前後に、Supabaseはローカル開発、データベース基盤、エージェント接続に関する複数機能を公開しました。これらはすべて同じ提供段階ではありません。正式提供の機能と、試験提供中の機能を分けて読む必要があります。

機能	提供段階	買収との関係
Dockerなしのローカル開発	Alpha、既定では無効	軽量な開発体験という方向性が近い
Declarative Schemas 2.0	発表済み	スキーマ管理をコード化しやすくする
Supabase Compute	Private Alpha	Postgresの実行基盤を再設計する試み
Multigres	Private Alpha	Postgresを横に拡張する将来構想
OrioleDB	Public Beta	Postgres互換の新しいストレージ方式を検証

SupabaseはDockerを使わないローカル開発をAlphaとして公開し、既定では無効にしています。さらに、MultigresはPrivate Alpha、OrioleDBはPublic Betaです。ベンチマーク値もSupabase自身による測定なので、自社のクエリで再確認すべきです。Turso買収はこの流れを補強しますが、各機能が一つの製品として連動済みという意味ではありません。[8][9]

導入前に確かめたい4項目

発表直後に本番構成を変えるより、用途を小さく切って比較する方が安全です。特にAIエージェントでは、処理数よりもデータの寿命と権限境界が設計を左右します。

1. 分離単位：エージェント、顧客、案件のどれごとにDBを分けるか決める。
2. データ寿命：作業終了後に削除する一時データと、監査のため残す記録を分ける。
3. 移行条件：SQLiteからPostgresへ移す容量、同時利用者数、必要なSQL機能を先に定義する。
4. 運用費：保存量だけでなく、読み書き回数、バックアップ、監視、障害対応を含めて試算する。

今すでにSupabaseで安定運用しているなら、買収だけを理由に移行する必要はありません。新しいエージェント機能を作る場合は、機密性の低い検証データでTursoを試し、権限分離と削除の簡単さを測る価値があります。統合機能を待つ場合は、正式提供、料金、移行手順、SLAの4点がそろった時点で再評価すると判断を誤りにくくなります。

まとめ

• 今回の買収は、SupabaseがPostgresを捨てる話ではなく、AIエージェントごとに小さなSQLite DBを持たせる選択肢を加える動きです。
• 既存利用者への即時変更はなく、統合日、統合料金、自動移行の仕様は未公表です。発表だけで本番構成を変える段階ではありません。
• 導入判断では、DBの分離単位、データ寿命、Postgresへ移る条件、読み書きを含む総費用を小規模検証で確かめることが重要です。

出典・参考

1. Supabase「Supabase is acquiring Turso」2026年10月2日
2. Turso「Turso is joining Supabase」2026年10月2日
3. SiliconANGLE「Database startup Supabase raises $150M and acquires Turso」2026年10月2日
4. Turso「A complete guide to database-per-agent architecture」2026年9月29日
5. Turso「CTO.new coordinates tens of thousands of AI agents」2026年9月24日
6. Turso「Pricing」2026年10月3日確認
7. Supabase Docs「Billing on Supabase」2026年10月3日確認
8. Supabase「Select 2026: Build anything」2026年9月30日
9. Supabase「Select 2026: Scale without limits」2026年10月1日