SQLiteを「一つの巨大DB」にしない、Tursoのmany-database戦略

Tursoの出発点は、SQLiteを捨てることではなく、SQLiteを現代の分散アプリケーションで使い続ける方法を作ることだった。

Fly.ioの顧客事例では共同創業者Glauber CostaとPekka Enbergの取り組みが語られており、libSQLは2022年にGitHubで公開され、SQLiteをオープンコントリビューションで発展させるforkとして始まった。出典

SQLiteをクラウドの外へ連れ出す

Glauber CostaとPekka Enbergは、Fly.ioの顧客事例でTursoの共同創業者として紹介されている。

SQLiteの単純さは魅力だが、ユーザーの近くで読む、複数環境へ同期する、アプリケーションに組み込むという要求が増えると、そのままでは足りない。出典

Tursoは2023年にpublic betaを案内し、データをユーザーに近づける『data edge』を前面に出した。出典

重要なのはSQLite互換を入口にしたことだ。

新しいSQL方言や新規の運用モデルを覚えさせるより、既存の開発者が理解している道具を広げる選択をした。

小さなDBを大量に扱う転機

2024年にはScaler Plan、embedded replicas、branchingなどを順に打ち出した。出典

これは単一の大きなDBを高性能化する物語ではない。

小さなDBを用途ごとに持っても運用できるよう、料金、同期、復旧の部品を整える物語だった。

AIエージェントがDBを増やす

2026年、TursoはAIエージェントやマルチテナントアプリに向けてmany-database architectureを掲げた。

1回のユーザー操作が複数の自律タスクに分かれ、それぞれが隔離された状態を必要とするなら、DBを増やすこと自体が設計になる。出典

SQLiteを『小さなローカルDB』に閉じ込めず、状態を分けて近づける基盤へ言い換えたことがTursoの現在地だと言える。

AIエージェントやマルチテナントSaaSでは、利用者・セッションごとの状態を分離しつつ、SQLiteの扱いやすさを捨てたくない。

TursoはlibSQLと組み込みレプリカを軸に、単一の巨大DBへ寄せず小さなDBを多数運用する選択肢を出す。出典

無料枠からDB数・読み書き量を段階化しており、個人開発から利用量が伸びるチームまで同じSQLite互換の開発体験で入れる。

これはPostgres移行を前提にしたBaaSとは異なる刺さり方だと考えられる。出典

libSQLのOSS資産とSQLite互換という既存開発者の学習コストの低さが土台になる。出典

ただしコード公開だけでは防御力にならない。

クラウド同期、運用、SDK、導入事例を一体で積み上げられるかが継続的な参入障壁になる。

直接の利用者間ネットワーク効果は強くない。

一方でlibSQLのコントリビュータ、ORM・ホスティング連携、チュートリアルが増えるほど採用の不確実性は下がる。出典

このためTursoの効果はマーケットプレイス型ではなく、開発者エコシステム型の弱い正の循環として捉えるのが妥当だ。

SQLiteを既に知る個人開発者、edge/サーバレス環境のチーム、テナントやエージェント単位で状態を切りたいSaaSが中心になる。

巨大な単一DBで複雑な横断分析を最優先する組織より、データ局所性とアプリ側の分離を設計に取り込みたい開発者に向く。

SQLiteの互換性を入口にしつつ、libSQLをオープンコントリビューションのforkとして公開した点が採用摩擦を下げる。出典

さらにembedded replicas、branching、同期といった『SQLiteだけでは本番で不安な部分』へ順番に機能を足し、既存エコシステムを置き換えず拡張している。

many-database architectureは魅力的だが、監視・権限・バックアップ・課金管理まで分散するため、運用の複雑さを隠し切れなければ小規模DBを増やすだけになる。

SQLite互換を重視しない大規模分析や複雑な書き込み競合では、Postgres系や専用分散DBとの比較で不利になる可能性がある。

GitHub、公式ドキュメント、フレームワーク統合、Fly.ioのような導入事例を入口にしている。出典

AIエージェントとマルチテナントを『DBをたくさん作る理由』として再定義し、無料枠から利用量課金へ進ませる戦略は、従来のSQLiteユーザーと新しいagent buildersを同時に狙う設計だ。

主要チャネル: open_source, github, developer_documentation, integration_ecosystem, case_studies

既存の広く使われた規格を捨てずに、運用上の欠点だけを新しい体験で包むと導入の説得力が出る。

TursoはSQLiteを『古い組み込みDB』としてではなく、エッジとAIエージェントの状態管理へ再配置している。

プロダクトの訴求を機能一覧ではなく、顧客が採用するアーキテクチャの名前へ引き上げることも学びになる。

日本では店舗・拠点・顧客単位にデータを分けたいSaaSや、社内業務のAIエージェントで権限境界を明確にしたい企業に応用余地があると考えられる。

ただし『DBを増やせる』だけでは売れない。

監査、削除、バックアップ、請求までを運用画面で説明できることが国内導入の条件になる。