Turso 完全ガイド【2026年版】— libSQL ベースのエッジSQLiteを業務でどう使うか（マルチテナントSaaS・RAG・モバイルAI視点で整理）

Turso は、libSQL（SQLite のオープンソース・コミュニティ拡張可能なフォーク）をベースにした エッジ配信型のサーバレスデータベース です。SQLite 互換でありながら、世界各リージョンへのレプリカ配置、アプリケーションプロセス内に SQLite ファイルを同期する "Embedded Replicas"、ネイティブのベクトル検索などを 1 つの製品としてまとめて提供しています。運営は2021年創業の Turso 社（旧 ChiselStrike）で、CEO は Glauber Costa（元 ScyllaDB）。ヘッドクォーターは米デラウェア州 Claymont、開発拠点はアイスランド・レイキャビクにあります。

Turso が他の選択肢（Neon、Supabase、PlanetScale、Cloudflare D1 等）と最も違う点を3つに整理します。 - "DB を増やすコスト" がほぼゼロ: SQLite 1 ファイル＝1 DB のため、テナントごとに DB を分ける "database-per-tenant" 構成が現実的なコスト感で組める - エッジ + 組込レプリカの "二段構え": クラウド側のリージョンレプリカ（ms 級レイテンシ）に加え、アプリケーション側にローカル SQLite を同期する Embedded Replicas（μs 級の読み込みレイテンシ）が標準 - ベクトル検索が "標準同梱": 別の VectorDB を立てなくても、リレーショナル列と一緒にベクトル列を扱える。大規模では DiskANN ベースの ANN を提供

libSQL（SQLite フォーク） SQLite と完全後方互換でありつつ、同時書き込みの改善・クラウドネイティブなアクセス・レプリケーション拡張などを取り込んだ OSS フォーク。Turso のクラウドサービスは libSQL の「公式運用版」と理解すると掴みやすい。OSS なので最終的にセルフホストへ逃げる経路も残ります。 Embedded Replicas（組込レプリカ） アプリケーションプロセス（VM / VPS / コンテナ / デスクトップアプリ）内にローカル SQLite ファイルを置き、Turso クラウドと同期。読み取りはローカルで完結するためマイクロ秒級レイテンシ、書き込みはクラウド経由で整合性を保つ。VPS・コンテナ・デスクトップアプリのように「常駐プロセスがあって SQLite ファイルを保持できる」環境で本領発揮します。 ネイティブベクトル検索 拡張機能を入れずに `vector` 型相当を扱える設計。小〜中規模はインデックスなしの線形スキャン、大規模では DiskANN ベースの近似最近傍探索（ANN）。RAG（検索拡張生成）構築でリレーショナルデータと埋め込みを同じ DB に持てるので、データ移送・整合性の悩みが減る。 マルチプラットフォーム SDK Node.js / Bun / Deno / Cloudflare Workers / Python 等のサーバ側に加え、iOS / Android のネイティブ SDK も提供。モバイル端末上で SQLite を持ちつつクラウドと同期する "sync-once-then-offline" 型のアプリが現実的に組めます。

公開料金（公式ページ・本記事執筆時点の概要）:

特徴 - Free 枠でも 100 DB / 月 5 億行読取と、PoC 〜 軽量本番が乗る量 - Developer プランで「DB 無制限」になる点が特徴的（テナントごとに DB を切りたい SaaS にハマる） - Scaler プランの "monthly active databases" 概念で、同時稼働中のDB数で課金される設計 - 必要に応じて Overage（追加課金）で柔軟に伸ばせる。ピーク対応のために上位プランへ常時張り付かせる必要がない 価格は変動するため、本番採用前に必ず公式料金ページで最新値を確認してください。

本記事を書いていて改めて衝撃なのは、月額 $4.99 の Developer プランで「データベース数が無制限」になる点です。これは過去の RDB / マネージド DB の常識からすると相当に異質で、設計の選択肢を根本から広げます。 なぜ衝撃なのか — 従来の常識との対比

DB の "単価" がゼロに近づくと、「DB を分ける／分けない」が技術判断ではなく純粋に設計判断になるのが大きい点です。

「DB を惜しまずに増やせる」状態で生まれる、現実的な使い方を5つ整理します。 1. テナント完全分離型 SaaS（database-per-tenant） - 1 テナント = 1 DB ファイル。テナント間のデータ漏洩リスクが構造的にゼロ - テナント削除＝ DB ファイル削除でクリーン（GDPR / 個人情報保護法の "忘れられる権利" にシンプル対応） - ノイジーネイバー問題が発生しない（テナント A の重いクエリが他テナントに波及しない） - 規制業種（医療・金融・公共）で「同一 DB 内同居の説明責任」がそもそも発生しない 2. ユーザー単位 DB（database-per-user / agent-per-DB） - AI チャットやパーソナルエージェント向けに、ユーザーごとの会話履歴・ベクトル埋込・メモリを別 DB に持つ - ユーザー単位のエクスポート・削除・凍結が瞬時 - 学習データの混線がなく、プライバシー説明が容易 - モバイル SDK と組み合わせれば「そのユーザーの DB だけ端末に同期」が現実的 3. 環境別 DB（dev / staging / preview / prod） - ブランチごとにプレビュー DB を立てて Vercel / Cloudflare のプレビュー URL に紐付け - マイグレーション検証を本番影響ゼロで安全に試せる - E2E テスト環境を CI ジョブごとに新規 DB 作成 → 終了時に破棄、という "使い捨て DB" 運用ができる 4. 機能別 / 特性別の DB 分離 - 監査ログ・通知履歴・分析イベント等、書き込みパターンが独特なテーブル群を別 DB に切り出す - 巨大化しがちな履歴系を本体 DB から分離してバックアップ戦略を変える - リードレプリカの配置リージョンを機能ごとに別最適化 5. 地域別 / 言語別 / 法域別 DB - EU 居住ユーザーのデータを EU リージョンの DB に隔離（データレジデンシー要件） - 言語圏ごとの全文検索辞書最適化を、別 DB に分けて干渉を避ける - 法域別のデータ保持期間ルールを DB 単位の運用ポリシーで切り出す

技術設計の選択肢が増えるだけでなく、業務側のオペレーションにも具体的な効果が出ます。 - "テナント単位削除" が一発: 退会・契約終了でその DB ごと消すだけ。残骸が他テナントの DB に混じらない - 大口顧客向けのカスタムスキーマが現実的: 標準スキーマと別 DB を用意できるので、"このお客様だけ独自カラム" が技術負債にならない - コンプラ監査が分かりやすい: "このテナントのデータはこの DB ファイルだけ" と1対1で説明できる - インシデント影響範囲を最小化: テナント A の DB に問題が起きても他テナントは無傷。ロールバックも DB 単位 - 無料トライアルを大量に許容できる: 試用ユーザーが増えても DB 単価が乗らないため、フリープラン拡大が痛くない - PoC・社内ハッカソンが活性化: "とりあえず DB を切って試す" が無料同然なので、新機能検証の速度が上がる

良いことばかりではありません。"分けやすい" は "管理対象が増える" と表裏一体です。 - マイグレーションの一括適用: 全テナント DB へのスキーマ更新を、CI から一括実行する仕組みを最初から作る（fan-out 失敗時のリトライ・ロールバック設計含む） - モニタリングのスケール戦略: 監視対象が DB 数だけ増えるため、テナント横断のメトリクス集約・異常検知の自動化が前提 - Scaler プランの "monthly active databases" 概念: Developer プランは無制限でも、上位の Scaler では "同時アクティブ DB 数" が課金軸。テナント数が "アクティブ" 単位で増える設計だと予算が読みづらくなる場合あり - クロステナント分析の難しさ: テナント横断の集計（全テナントの月間アクティブ・人気機能ランキング 等）はアプリ層で集約パイプラインを別途持つ必要あり - 接続プールの設計変更: 1 アプリプロセスから多数の DB を扱うため、接続キャッシュ・タイムアウト・リトライの戦略が "単一 DB" 時代と違う - バックアップ戦略: DB 数が増えるとバックアップ実行・検証もスケールアウト要。"全 DB の整合スナップショット" は概念上存在しない（テナントごとの整合性で考える） これらをカバーする運用設計（テナント管理基盤・マイグレーションランナー・観測基盤）を、データベース選定と同時に設計するのがハマらないコツです。

1. マルチテナントSaaS（テナントごとにDB） テナント増加 = データベース増加（1テナント1ファイル）。1 つの巨大な共有 DB にテナントID列で混ぜる伝統的な設計と比べて、完全分離できる。SaaSの代表的な悩み「ノイジーネイバー」「テナント単位のバックアップ・削除」「データ分離の説明責任（GDPR / 業界規制）」がシンプルに解ける。 2. RAG / AI 機能組込のWebアプリ 埋め込みベクトルを別 VectorDB に出さずに済むため、データ整合性とインフラ簡素化の両方で利点。文書本体・メタデータ・ベクトルが同じトランザクションで扱える。 3. ローカルファーストアプリ・モバイルAIアプリ iOS / Android SDK で端末側に SQLite を置きつつクラウドと同期。「オフラインでも動く」「起動が速い」「ユーザー単位のデータが端末ローカルにあるのでプライバシー説明が単純」のようなメリットが得られます。Turso の multitenant DB と組み合わせると「ユーザーごとの DB だけがその端末に同期される」構成も組める。 4. エッジ配信のWebアプリ・APIバックエンド Cloudflare Workers / Vercel Edge から Turso のリージョンレプリカへ接続することで、世界中のユーザーに低レイテンシで応答できる。Hono / Next.js Edge ルートと相性が良い。

- SQLite 互換 = 学習コストがほぼゼロ: 既存の SQLite 知識・SQL・ツール群（Drizzle ORM、Prisma、ベター SQLite GUI 等）がそのまま使える - DB 増殖コストの低さ: テナント単位で DB を切る運用が現実的になる - エッジ + Embedded の二段構え: クラウドだけのレプリカでは届かないマイクロ秒級レイテンシを実現 - ベクトル検索が標準: pgvector / Pinecone 等の追加スタックが不要 - OSS（libSQL）への退路: 最悪 Turso 社のサービスを離れても、libSQL でセルフホスト可能 - モバイル SDK: iOS / Android のオンデバイス DB として現実的に使える - コスト透明性: Free / Developer / Scaler の3階層で予測しやすい

- 書き込み集中ワークロードは要検討: SQLite 系の特性上、単一 DB に対する高頻度書き込みは Postgres より弱い。書き込みヘビーな分析系は別構成（Postgres / Cassandra / OLAP）と組合せ - 巨大単一 DB は不向き: 強みは「DB を増やす」設計。1 DB を 1 TB 級に育てる構成は本来の使い方ではない - Postgres 系の機能網羅性とは別物: 高度な拡張機能（pg_trgm / PostGIS / 強力な partial index 等）を前提とした設計は移植困難な場合あり - 会社規模・調達額の不確実性: 公開情報ベースでは2022年7月のシード $7M、社員約 22 名（2025年時点）。Neon / Supabase 比で組織規模は小さく、SLA・本番運用の観点で慎重評価が必要 - libSQL fork の OSS コミュニティ的位置づけ: SQLite 本家とは別系統のフォーク。本家への将来統合や離脱の可能性は完全には読めない - マルチテナント時の運用設計が必要: DB 数が増えるとマイグレーションの一括適用・モニタリングのスケール戦略が別途必要

「サーバレス・スケーラブルなDB」の主要選択肢を実務観点で並べると：

Turso は "DBをたくさん持ちたい" "組込レプリカを使いたい" "ベクトル検索も同居させたい" の3条件のいずれかが効く案件で、他にない位置を取ります。逆に、これらに当てはまらない一般的なPostgres案件はNeon / Supabaseが素直です。

判断材料を3点： - 資金・組織規模: 公開情報では2022年7月のシード $7M、社員約 22 名（2025 年時点）。フロンティア領域の小規模スタートアップという位置づけ - 製品の独自性: libSQL は OSS、Embedded Replicas・ベクトル検索の組み合わせは他にない実装。短期で代替不能なポジションを作っている - 退路の確保（重要）: libSQL が OSS なので、最悪 Turso 社のクラウドが終了しても、libSQL でセルフホスト or 他社サービスに移行する経路は理論上残る。商用 DB の典型的なロックインリスクは比較的低い 本格的な本番採用を検討する場合は、マイグレーション手順を初期から整備しておく（libSQL のセルフホスト or Postgres 移行手順を社内ドキュメント化）ことで、サービス側の不確実性をヘッジできます。本記事の同シリーズ6サービス比較・持続可能性で扱った AI ビルダーと同様、ロックイン最小化の意識が重要です。

概念的なフロー： 1. アカウント登録（GitHub 連携可） 2. CLI（`turso` コマンド）をインストール 3. データベース作成（リージョン指定） 4. 認証トークン取得 5. アプリケーションコードから libSQL クライアントで接続（Node / Bun / Deno / Workers / iOS / Android すべてで類似 API） Drizzle ORM や Prisma の Turso ドライバを使うと、SQL を直接書かない構成に乗せやすい。Cloudflare Workers + Hono + Drizzle + Turso の組み合わせは2026年に増えている定番スタックの1つです。詳しい接続コード・初期化手順はTurso 公式ドキュメントを参照してください。

オブライトでは、次のような案件で Turso を提案候補に入れています： - 業務系SaaS（テナントごとにデータを完全分離したい）: テナントごとに DB を切る運用がコスト的に成立 - RAG・社内ナレッジ検索: ベクトル検索同居で構成簡素化 - モバイル・タブレット業務アプリ: オンデバイス SQLite × クラウド同期 - エッジ配信のグローバルWebアプリ: Cloudflare Workers + Hono + Drizzle + Turso 本シリーズのHono + Inertia + React や DocDD 駆動の AI 開発 ともあわせて、設計→実装→デプロイまでワンストップでご相談いただけます。詳細はソフトウェア開発 / Web 開発 / AI 導入コンサルティング からどうぞ。

Q1: Postgres を使っていれば Turso は不要では？ A: 「巨大単一 DB を Postgres で運用」が現状で問題なく回っているなら無理に乗り換える必要はありません。Turso が刺さるのは「テナントごとにDBを切りたい」「エッジ＋組込レプリカでマイクロ秒級が要る」「ベクトル検索を同居させたい」という具体的なメリットがある場合です。 Q2: SQLite で本番運用は本当に大丈夫？ A: SQLite 自体は世界で最も多くデプロイされている DB（モバイル・デスクトップ・組込含む）。libSQL は同時書き込みの改善等で本番運用での弱点を埋めています。書き込み超集中型ワークロード以外ではほぼ問題ありません。 Q3: 障害時の復旧は？ A: Turso 側で複数リージョンレプリカ＋スナップショット運用。Embedded Replicas 環境では端末側にもデータがあるため、クラウド側障害でも読み取りは継続できる構成が組めます。SLAの最新値は公式を確認してください。 Q4: 料金が予期せず跳ね上がる懸念は？ A: Free → Developer → Scaler の階層が明示的で、Overage（追加課金）も明示的にオプトインする設計。突然の高額請求は起きにくい構造ですが、月間アクティブDB数の概念に慣れる必要があります。 Q5: 移行困難になりませんか？ A: libSQL は OSS のため、最悪セルフホストへ移行可能。実務上は "マイグレーション SQL を libSQL で再生できる状態を保つ" "スキーマと初期データを Git で管理" "バックアップを別ストレージに取る" の3点でロックインを下げられます。 Q6: ベクトル検索の精度・スケールは？ A: 小〜中規模は標準で十分（線形スキャン）、大規模では DiskANN ベースの ANN。Pinecone / Weaviate のような専用 VectorDB に対し "特化機能" では劣る場面があるが、リレーショナルデータと一体管理できるメリットが多くの案件で勝ります。

- Turso 公式 - Turso 料金ページ - Turso 公式ドキュメント - libSQL — Turso Docs - Turso brings Native Vector Search to SQLite（Turso Blog） - Introducing Embedded Replicas（Turso Blog） - Turso Goes Mobile With Official iOS & Android SDKs（Turso Blog） - Announcing ChiselStrike Turso（Turso Blog） - Turso 会社情報（Crunchbase） - Turso introduces Overages（Turso Blog）