SupabaseがTursoを買収。Tursoとは何か、開発者は何を確認すべきか
2026年10月2日、Supabase が Turso の買収を発表しました。Turso は SQLite を Rust でフルリライトし、「1台のサーバーで数百万個の小さなデータベースを動かす」アーキテクチャを提供してきた会社です。両社の発表によれば既存ユーザーへの即時の変更はなく、Turso のプラットフォームは継続し、Turso Database はオープンソースのまま開発が続きます。一方で買収額・クローズ時期・将来の料金については両社とも言及していません。つまり「今すぐ移行を検討する話」ではなく、「料金と移行経路を確認しておく話」です。
何が発表されたのか
Supabase の発表は、エージェントが数百万個のデータベースを立ち上げている現状に対応するための買収だと説明しています。Supabase は自社で週100万個以上のデータベースが作られていると述べ、小さなワークロードごとに専用マシンを用意する前提では追いつかないとしています。
同日、Supabase は GIC がリードする1億5000万ドルの資金調達も公表しました。プレスリリースでは Alphabet の独立系成長ファンドである CapitalG、IronArc、SquarePeg も参加したとされています。買収額は開示されていません。
人員面では、Turso 創業者の Glauber Costa 氏が Head of Agentic Services として Supabase に加わり、共同創業者の Pekka Enberg 氏とチームも合流します。製品方針は「Supabase は Postgres、Turso は SQLite を引き続き開発する」という分担です。
Tursoとは何か。混同しやすい3つの名前
Turso について調べると名前が3つ出てきます。ここを区別しないと記事やドキュメントの内容がかみ合いません。
- libSQL: SQLite の C 言語ベースのフォーク。SQLite は「オープンソースだが外部からの貢献を受け付けない」ため、拡張できるフォークとして作られました。ファイル形式と API は SQLite と完全互換で、HTTP 経由のリモートアクセス、埋め込みレプリカ、ネイティブなベクトル検索を追加しています。リポジトリは MIT ライセンスです。
- Turso Database: SQLite を Rust でゼロから書き直した別実装（旧コード名 Limbo）。同時書き込みや非同期 I/O、データベース密度の高さを狙った設計です。SQLite の単一ライター制約を構造的に解消しようとしている点が libSQL との最大の違いです。
- Turso Cloud: 上記を動かすマネージドサービス。Turso の発表では、ディスクを持たず WAL を S3 に置くアーキテクチャにより、必要なときだけデータベースをロードし、使われていないときは停止させると説明されています。
公式ドキュメントは libSQL と Turso Database の両方を production-ready と位置づけ、「新規プロジェクトには Turso Database、今すぐ実績のある基盤が必要なミッションクリティカル用途には libSQL」と推奨を分けています。なお Turso の買収発表文に libSQL という語は出てきません。オープンソース継続の約束は Turso Database について述べられたものだと読むのが正確です。
なぜPostgresの会社がSQLiteを買ったのか
SQLite は1データベース＝1ファイルに近い構造のため、データベースを増やしても固定費がほとんど増えません。Supabase はこの性質を「エージェントがファイルを作るのと同じ感覚でデータベースを作れる」状態に使おうとしています。SQLite は小さくオンデマンドな用途に適し、スケールする段階では Postgres を使う、という役割分担です。
この考え方は料金表にも現れています。Turso Cloud の無料プランはデータベース100個・ストレージ5GB・月5億行の読み取りまで、Developer プランは月4.99ドル（年払い時）でデータベース数が無制限、ストレージ9GB・月25億行の読み取りを含みます。アイドル状態のデータベースはストレージ分しか課金されないため、ほとんど動いていない大量のデータベースを抱える設計が成立します。
ここから読み取れる実務的な論点は、課金軸が「インスタンス数」ではなく「読み取り行数・書き込み行数・ストレージ・同期量」だということです。テナントやエージェントごとにデータベースを分けてもコストは跳ねませんが、全件スキャンに近いクエリや N+1 は料金に直結します。インスタンス単位で考える Postgres のホスティングとは、コスト最適化の着眼点が変わります。
発表に書かれていないこと
判断に必要な情報のうち、公表されていない点を整理します。
- 買収額、クローズ時期、クロージング条件。発表文は「acquiring（買収する）」という現在進行の表現です。
- 統合後の料金。「今日と同じように動き続ける」は現時点の運用についての説明で、将来のプラン内容や無料枠を約束するものではありません。
- SQLite から Postgres への「graduation path（卒業経路）」の具体策。Supabase エコシステムを経て Multigres まで繋がると述べられていますが、移行ツールや互換性の一覧、提供時期は示されていません。
すでにTursoを使っているなら確認すべきこと
慌てて移行する理由は現時点ではありません。やるべきは退出路の確認です。
- データのエクスポート手順を一度実行して記録する。SQLite 互換のファイル形式であることが Turso の強みであり、そのまま自前のインフラで開けるかを実際に確かめます。
- libSQL を使っている場合は、MIT ライセンスでセルフホストできる構成を手順として残す。コードは取り上げられませんが、運用手順がなければ退出はできません。
- 料金の前提を洗い出す。読み取り行数や同期量が想定の何倍まで耐えられるかを試算し、現行プランに依存した設計になっていないか確認します。
- 長期契約の更新時は、料金・SLA・データ所在地が変わった場合の扱いを事前に確認する。今後数か月で Supabase との統合が進むと予告されているため、更新条件は現在の発表内容だけで判断しない方が安全です。
これから選ぶ場合の判断基準
Turso が向くのは、テナント・ユーザー・エージェント単位でデータベースを分離したい場合、読み取りが多く埋め込みレプリカでローカル読み取りの低遅延を取りたい場合、ベクトル検索を同じデータベース内で完結させたい場合です。いずれも「データベースの個数が増える」設計が前提になります。
逆に、1つの大きなデータベースに書き込みが集中する、複雑な結合や Postgres 拡張に依存する、認証やストレージ、Realtime まで含めて1つの基盤で揃えたい、といった要件なら Postgres 系（Supabase や他のマネージド Postgres）が素直です。買収後も両社は Postgres と SQLite の分担を続けると述べているため、この選択基準自体はすぐには変わりません。
新規採用で迷いやすいのは libSQL と Turso Database のどちらに乗るかです。公式の推奨は新規プロジェクトでは Turso Database ですが、実績の長さを重視するなら libSQL という整理になっています。採用時点でどちらを使っているのかを明示してドキュメント化しておくと、将来の移行判断がぶれません。
まとめると、この買収で今すぐ壊れるものはなく、確認すべきは「料金の前提」と「データを持ち出せること」の2点です。エージェントを含むアプリケーションのデータストア選定や、現行構成からの移行可否の見極めで判断材料が足りないときは、お問い合わせからご相談ください。要件に対してどのデータベース構成が妥当かを一緒に整理できます。
