Tursoとは？料金・使い方とlibSQL/Turso Database（Rust）の違いを実測解説【2026年10月】

Tursoという名前は、いま3つの別々のものを指しています。マネージドサービスのTurso Cloud、RustでSQLiteを書き直したTurso Database、そしてC言語のSQLiteフォークであるlibSQLです。この3つを混ぜて読むと、料金の話と並行書き込みの話と互換性の話がかみ合わなくなります。本記事では2026年10月2日時点の公式リポジトリ・ドキュメント・料金ページを一次情報に、3者の関係、エッジSQLiteという発想が注目される本質的な理由、料金と無料枠、導入手順、最大の差別化点である複数ライターの挙動を、ローカル実行の結果とあわせて整理します。

まとめ：2026年10月時点のTursoの要点とエッジSQLiteの現在地

• 本命はRust実装のTurso Database。公式リポジトリのREADMEは、Rustでの書き直しが「libSQLに代わる我々の方針になった」と明記しています。libSQLは保守は続きますが、新機能はTurso Databaseで開発されています。
• 2026年9月29日にv0.8.0が正式リリースされ、同日にv0.8.1も出ました。1.0には未到達ですが、READMEのFAQは本番利用に「Yes」と答えています。
• SQLite互換の基準はバージョン3.50.4。ローカルで実行したSELECT sqlite_version()が3.50.4を返し、tursodbが書いたDBファイルをOS標準のsqlite3（3.53.1）がそのまま読めることを確認しました。
• 複数ライターは条件付きで動く。PRAGMA journal_mode=mvccを先に実行しないとBEGIN CONCURRENTは拒否されます。逆に条件を満たせば、標準sqlite3ではdatabase is lockedになる同形のコードが通ります。Turso Cloudでも2026年8月3日からアーリープレビューとして使えます。
• Turso Cloudの無料枠はDB数100・ストレージ5GB・月間読み取り5億行。有料は月額4.99ドルから。
• もうエッジ35拠点ではありません。2025年3月にFly.ioからAWSへ移行済みで、現在の提供リージョンは東京を含むAWSの6拠点です。「エッジSQLite」の価値は、拠点数ではなくDBをアプリ側へ置く設計に移っています。
• 2026年7月にPostgresフロントエンドが始動。ただし公開パッケージはまだ無く、ソースからのビルドが前提の実験段階です。

エッジSQLite採用が注目される本質的理由はDBをアプリの隣に置く発想

Tursoが話題になるとき、決まって「エッジSQLite」という言葉がついてきます。ここで押さえるべきは、注目の理由が「世界中の拠点にDBを置けるから」ではなくなった点です。後述のとおりTurso Cloudの提供拠点はAWSの6リージョンに集約されました。それでも採用検討が続いているのは、SQLiteというプロセス内で動く1ファイルのデータベースを、サーバー・ブラウザ・端末のどこにでも置き、必要なときだけクラウドと同期するという構成が、従来のクライアントサーバー型DBでは取りにくい選択肢を開くからです。理由は3つに分けられます。

読み取りのネットワーク往復を消すin-process実行の性質

PostgreSQLやMySQLは、アプリからネットワーク越しにDBサーバーへ問い合わせます。1回のクエリに必ず往復の遅延が乗り、1画面で数十回のクエリを投げる処理ではその合計が体感速度を決めます。SQLiteとTurso Databaseはアプリと同じプロセスの中で動くため、読み取りはローカルのファイルアクセスで完結する仕組みです。READMEも冒頭でTursoを「Rustで書かれたin-processのSQLデータベース」と定義しています。遅延を下げる手段が「DBを近くの拠点に置く」から「DBのコピーをアプリの手元に置く」へ移ったことが、エッジSQLiteの本質です。Cloudflare Workersとは？エッジコンピューティングの基本解説で扱ったエッジ実行基盤と組み合わせる場合も、効くのは拠点の近さより読み取りをローカルで閉じられるかどうかです。

テナントごとに1データベースを持つ設計の費用とデータ分離の利点

SQLiteのDBは1ファイルなので、作成も削除もバックアップも軽量です。Turso CloudはこれをDB数の上限として料金に反映しており、無料枠で100個、Developer（月額4.99ドル）以上ではDB数が無制限になります。顧客ごとにDBを分ける構成は、行レベルでテナントIDを付けて1つのDBに混在させる構成より分離が強く、特定テナントだけの復元や削除も単純です。共有DBと専用DBのどちらで分離するかの設計論はシングルテナントとマルチテナントの違い｜比較表・選定基準とテナント分離の実装で整理しています。Tursoは「専用DB方式」のコストを大きく下げる部品として位置づけると判断しやすくなります。

オフライン前提のローカルファーストとAIエージェントの作業用DB用途

3つ目は、端末側にDBを持ち、オフラインでも読み書きして後から同期するローカルファーストの需要です。モバイルではRealmが担ってきた領域ですが、Device Syncの提供終了で移行先を探す動きがあり、その比較はRealm（モバイルDB）とは？SQLiteとの違いとDevice Sync終了後の採用判断を解説で扱っています。Turso側は後述のTurso Syncでサーバー・ブラウザ・モバイルの双方向同期を掲げており、ブラウザ内で動作するのはWebAssembly版です。加えて、AIエージェントごとに作業用のDBを1つずつ払い出すといった「使い捨ての小さなDBを大量に持つ」用途とも、1ファイルで作成と破棄が軽いという性質がそのまま噛み合います。

Tursoの3実体とlibSQLからRust製Turso Databaseへの移行

Turso Cloud・Turso Database・libSQLの役割分担

公式ドキュメントは3つを別々に定義しています。Turso Cloudは「TursoおよびlibSQLデータベースのためのフルマネージドプラットフォーム」で、ブランチ・分析・バックアップを備えたサービス層です。Turso Databaseは「どこへでも持ち運べる組み込みデータベースエンジン」で、オフライン・ブラウザ・デバイス上での動作を想定しています。libSQLはTurso Cloudが管理できるデータベース種別のひとつという位置づけです。2026年8月3日の公式ブログも、Tursoはエンジン、Turso Cloudはホスティング基盤、Turso, Incは会社と、同じ名前が3つを指すことをわざわざ断っています。

料金の話ならTurso Cloud、並行書き込みやRustの話ならTurso Database、埋め込みレプリカの話ならlibSQLが主語です。日本語の解説記事の多くは2025年前半までのlibSQL前提で書かれているため、前提のずれに注意してください。

libSQLの新機能開発が止まりRust実装が主線になった経緯

libSQLリポジトリのREADME冒頭は、libSQLがフォークゆえに単一ライターモデルというSQLiteの制約を受け継ぐのに対し、Turso Databaseは完全な新規実装で並行書き込みとオフライン対応の双方向同期まで踏み込むと対比したうえで、新規プロジェクトならTursoを見るべきで、libSQLは保守されるが新機能はTursoで開発されていると明記しています。方針転換の経緯は公式ブログの「We will rewrite SQLite. And we are going all-in」にまとまっています。

数字も方向を裏づけています。2026年9月6日にGitHub APIで取得した実測値では、tursodatabase/tursoがスター24,186・フォーク1,310・コントリビューター296名、tursodatabase/libsqlがスター17,194・コントリビューター108名でした。libsql-serverの正式リリースは2025年2月14日のv0.24.32が最後で、その後1年半以上更新されていません。対してTurso Databaseは2026年9月に入ってもプレリリースを重ね、9月29日にv0.8.0とv0.8.1を正式リリースしています。v0.8.0のリリースノートにはPostgresフロントエンド（tursopg）の改善や.NETバインディングの埋め込みレプリカ対応が並んでおり、開発の重心の移動は明確です。

本番投入の可否について、READMEのFAQは「本番で使えるか」という問いに「Yes」と答え、Turso Cloud・Kin AIアシスタント・Spice.aiなど複数組織で本番稼働していると説明しています。一方で1.0には未到達で、一部機能は実験的という位置づけも同じFAQにあります。目標水準は「SQLiteと同等の信頼性」で、1.0宣言までは独立したバックアップを持つ運用規律を推奨する立場です。よく見る「BETAだから本番では使えない」という単純化は、現在の公式説明とは一致しません。

Iku-Tursoに由来する社名と日本語の読み方・表記の扱い

社名の由来は公式のAboutページに書かれています。Iku-Tursoはフィンランド神話の海の怪物で、自然の根源的な力を表す存在だと説明されています。創業者はCEOのGlauber Costa氏（ScyllaDB・Datadogを経てRustの非同期実行基盤Glommioの作者）とCTOのPekka Enberg氏（ScyllaDBの初期メンバーで元Linuxカーネルのメンテナ）です。日本語のカタカナ表記について公式の指定は見当たらないため、本記事では原綴りのTursoで統一します。

SQLite互換の到達点と2026年7月に始まったPostgresフロントエンドという分岐

SQLite 3.50.4を基準とする互換性とバージョン取得の実測

リポジトリのCOMPAT.mdは、TursoがSQLiteのバージョン3.50.4を追跡対象とし、それがsqlite_version()およびsqlite3_libversion()の返す値であり、差分テストに使うバージョンでもあると定めています。さらに、明示的にオプトイン拡張として文書化されていないSQLiteとの挙動差はすべてバグ扱いだと宣言しています。2026年10月2日に再確認した時点でも、追跡対象は3.50.4のままでした。

実際にmacOS上でtursodb 0.7.2を動かして確認しました。

$ printf "CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
INSERT INTO users VALUES (1, 'alice'), (2, 'bob');
SELECT * FROM users ORDER BY id;
SELECT sqlite_version();
" | tursodb -q -m list demo.db
1|alice
2|bob
3.50.4

COMPAT.mdの記述どおり3.50.4が返りました。Pythonバインディングのpyturso 0.7.2でも同じ値を確認しています。検証は2026年9月の0.7.2で行ったもので、0.8系での再実行はしていません。

tursodbで書いたファイルを標準sqlite3が読める実測

ファイルフォーマット互換は、移行コストを見積もるうえで最も効く性質です。上のセッションが作ったdemo.dbを、OS標準のsqlite3コマンド（SQLite 3.53.1）でそのまま開きました。

$ file demo.db
demo.db: SQLite 3.x database, last written using SQLite version 3047000, ...
$ /usr/bin/sqlite3 demo.db "select * from users order by id;"
1|alice
2|bob

変換もエクスポートも挟まずに読めています。既存のSQLiteファイルをそのまま持ち込め、やめても手元にはただのSQLiteファイルが残る、という双方向の可搬性がここで担保されます。ロックイン懸念を評価軸に置くなら、この一点が他のマネージドDBに対する明確な優位です。

2026年7月に始まったPostgresフロントエンドの現在地

2026年7月16日、TursoはRustでモダンなPostgresを作ると発表しました。掲げているのは「データベース版のLLVM」という構想です。SQLiteと同じくSQLをVDBEというバーチャルマシンのバイトコードにコンパイルして実行する設計を活かし、ひとつのコアの上に複数のSQLフロントエンドを載せる。SQLiteが最初のフロントエンドで、Postgresは独自の方言とワイヤプロトコルを持つ2つ目のフロントエンドという整理です。ストレージ・並行制御・クエリコンパイラ・VMは共通です。

ただし現状は限定的です。公式発表自体が「完成品ではなく基盤である」と述べており、公開パッケージは存在せず、ソースからビルドして動かす段階にあります。リポジトリの機能一覧でもPostgres互換は実験的機能に分類されています。v0.8.0ではWITHIN GROUP集計への対応など改善が続いていますが、2026年10月時点でPostgres互換を業務要件に組み込む判断は時期尚早で、SQLite側の成熟度とは別物として評価すべきです。PostgreSQL互換をうたう新興DBの比較軸はPlanetScaleとは？無料枠終了後の料金・Vitess/Postgres/Nekiの違いを解説【2026年版】も参考になります。

BEGIN CONCURRENTの複数ライター条件とTurso Cloudの提供状況

SQLiteの単一ライター制約をMVCCで越える、というのがTurso Databaseの最大の売り文句です。MVCCそのものの仕組み（行ごとに複数の版を持ち、読み手と書き手を互いに待たせない方式）はMVCCとは？多版型同時実行制御の仕組みと過去版の回収を実装目線で解説で解説しています。ただし実際に手を動かすと、ドキュメントの機能一覧からは読み取れない前提条件があるのです。ここは公開情報だけでは埋まらない部分なので、pyturso 0.7.2（Python 3.14.6）で実行した結果を示します。

PRAGMA journal_mode=mvccを省くと拒否される

まず、素直にBEGIN CONCURRENTを書いた場合です。

import turso

cur = turso.connect(":memory:").cursor()
cur.execute("CREATE TABLE t (id INTEGER PRIMARY KEY)")
cur.execute("BEGIN CONCURRENT")

これは次の例外で止まります。

turso.lib.DatabaseError: Transaction error: Concurrent transaction mode is only supported when MVCC is enabled

MVCCを有効にする経路はPRAGMA journal_mode=mvccです。SDKのexperimental_features引数にmvccを渡しても通りません。SDK層が受け付けるフィーチャー名はviews・encryption・attach・multiprocess_wal・mvcc_passive_checkpointなど11個で、素のmvccは列挙されていないからです。CLI側も--experimental-mvcc-passive-checkpointの説明文が「journal_mode=mvccを必要とする」と述べており、PRAGMA経由が正規ルートです。

PRAGMAを先に置くと、2本のコネクションが同時に書けます。

import turso

con = turso.connect("app.db")
cur = con.cursor()
print(cur.execute("PRAGMA journal_mode=mvcc").fetchall())
cur.execute("CREATE TABLE t (id INTEGER PRIMARY KEY, v TEXT)")

w1 = turso.connect("app.db").cursor()
w2 = turso.connect("app.db").cursor()
w1.execute("PRAGMA journal_mode=mvcc")
w2.execute("PRAGMA journal_mode=mvcc")
w1.execute("BEGIN CONCURRENT")
w2.execute("BEGIN CONCURRENT")
w1.execute("INSERT INTO t VALUES (1, 'writer-1')")
w2.execute("INSERT INTO t VALUES (2, 'writer-2')")
w1.execute("COMMIT")
w2.execute("COMMIT")
print(cur.execute("SELECT * FROM t ORDER BY id").fetchall())

実行結果です。

[('mvcc',)]
[(1, 'writer-1'), (2, 'writer-2')]

両方のトランザクションがコミットされ、2行とも残りました。

同じ形のコードがSQLiteではdatabase is lockedで落ちる

比較のため、標準ライブラリのsqlite3（SQLite 3.53.1）でWALモードにしたうえで、同じく2本の書き込みトランザクションを重ねます。

import sqlite3

sqlite3.connect("lite.db").execute("PRAGMA journal_mode=wal")
a = sqlite3.connect("lite.db", isolation_level=None)
b = sqlite3.connect("lite.db", isolation_level=None, timeout=0.5)
a.execute("CREATE TABLE t (id INTEGER PRIMARY KEY, v TEXT)")
a.execute("BEGIN IMMEDIATE")
a.execute("INSERT INTO t VALUES (1, 'writer-1')")
b.execute("BEGIN IMMEDIATE")
b.execute("INSERT INTO t VALUES (2, 'writer-2')")

sqlite3.OperationalError: database is locked

SQLite公式のWAL解説のとおり、WALは読み手と書き手の同時実行を可能にしますが、書き手同士は直列です。BEGIN IMMEDIATEの仕様は開始時点で書き込みロックを取りに行くため、2本目がタイムアウトして落ちます。書き込みが集中してSQLiteのロック待ちに悩んでいる、という一点だけがTurso Databaseへ移る動機になり得る局面です。逆に言えば、読み取り主体でロック競合が起きていないなら、この差分から得られるものはありません。

Turso Cloudでのアーリープレビューと行単位の衝突時の扱い

ローカルのエンジンだけでなく、マネージド側でも並行書き込みが使えるようになりました。2026年8月3日の公式ブログによると、プライベートベータを経てTurso Cloud上でのBEGIN CONCURRENTがアーリープレビューとして誰でも試せる状態になっています。衝突はコミット時に行単位で検出され、異なる行を触るトランザクション同士は互いに干渉せずコミットされます。

裏返すと、同じ行を2本のトランザクションが更新した場合は、後からコミットした側が失敗します。アプリ側には「失敗したらトランザクションを最初からやり直す」処理が必要です。次は考え方を示す設計例で、例外クラス名やエラー文言は版によって変わり得るため、手元の版で実際のエラーを確認してから絞り込んでください（このコードは実行確認をしていません）。

import time
import turso

def run_with_retry(con, work, retries=5):
    # BEGIN CONCURRENT の衝突はコミット時に表面化するため、丸ごとやり直す
    for attempt in range(retries):
        cur = con.cursor()
        try:
            cur.execute("BEGIN CONCURRENT")
            work(cur)
            cur.execute("COMMIT")
            return
        except Exception:
            cur.execute("ROLLBACK")
            time.sleep(0.01 * (2 ** attempt))
    raise RuntimeError("retry limit exceeded")

カウンタや在庫数のように同じ行へ書き込みが集中するテーブルでは、MVCCにしても衝突とやり直しが増えるだけです。並行書き込みの恩恵が出るのは、ログ・イベント・注文明細のように書き込み先の行がばらけるワークロードだと考えておくと、期待値を外しません。

SQLite・libSQL・Turso Databaseの書き込み・同期・成熟度比較

ここまでの内容を、採用判断に効く軸で1枚にまとめます。いずれも2026年10月2日時点の公式情報と本記事の実行結果にもとづく整理です。

判断の起点は書き込みの形です。単一ライターで困っていないなら本家SQLiteで十分で、Tursoを入れる理由はマネージド運用やDB大量作成のほうにあります。既にlibSQLの埋め込みレプリカで動いているシステムは急いで移す必要はありませんが、新規に組むならTurso Databaseを選ぶのが公式の方針と一致します。

Turso Cloudの料金プラン4種と無料枠を最初に超える条件の見極め方

Turso Cloudの4プランにおけるDB数・容量・読み書きの数量制限

2026年10月2日時点で公式の料金ページに掲載されている月額課金の数値です。2026年9月6日の確認時から変更はありませんでした。

超過分は従量課金です。Developerではストレージ1GBあたり0.75ドル、読み取り10億行あたり1ドル、書き込み100万行あたり1ドル、同期1GBあたり0.35ドルが加算されます。上位ほど単価は下がり、Scalerではそれぞれ0.50ドル・0.80ドル・0.80ドル・0.25ドル、Proでは0.45ドル・0.75ドル・0.75ドル・0.15ドルです。さらに上に専有クラウドとBYOC（自社AWSアカウント上での運用）を含むEnterpriseプランがあり、こちらは個別見積もりです。

無料枠で足りる規模と書き込み行数・DB数の上限を超える利用条件

無料枠を最初に割るのは、たいていストレージでもDB数でもなく月間書き込み1,000万行です。1日あたりに直すと約33万行で、ログや監査証跡をアプリと同じDBへ書いている構成だと個人開発規模でも到達します。読み取り5億行は1日約1,700万行なので、キャッシュを挟んだWebアプリならまず余裕があります。

DB数100という枠は、テナントごとに1データベースを割り当てる設計を無料で試せる、という意味では実用的です。ただしその設計を本番に持っていくならDeveloper以上が前提になります。DB無制限になるのがDeveloper（月額4.99ドル）からで、ここがTursoの価格設計上の分岐点です。

tursodbとturso CLIを使い分けてローカルとクラウドにDBを作る導入手順

紛らわしいのですが、コマンドは2つあります。ローカルのエンジンを起動するtursodbと、Turso Cloudを操作するtursoです。前者はtursodatabase/tursoリポジトリ、後者はtursodatabase/turso-cliリポジトリ（2026年9月29日のv1.0.33が最新）と、配布元も別です。

ローカルエンジンtursodbの導入手順とバージョン確認の実測

公式のインストーラを実行すると$HOME/.turso配下にtursodbが入ります。

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/tursodatabase/turso/releases/latest/download/turso_cli-installer.sh | sh

2026年9月の検証環境（macOS・x86_64）ではdownloading turso_cli 0.7.2 x86_64-apple-darwinと表示され、tursodb --versionはTurso 0.7.2を返しました。インストーラはlatestのリリースを取りに行くため、2026年10月時点で実行すると0.8系が入る見込みです。引数なしで起動するとインメモリDBの対話シェルが立ち上がり、.openで永続ファイルへ切り替えます。Dockerならリポジトリ直下のmake docker-cli-buildとmake docker-cli-runが使えます。

Turso CloudのCLIとlibSQL/Turso Databaseの作り分け

クラウド側は別のCLIです。macOSならHomebrew、Linuxとwsl環境ではインストールスクリプトを使います。

brew install tursodatabase/tap/turso
curl -sSfL https://get.tur.so/install.sh | bash

turso auth signup
turso db create my-db --tursodb
turso db show my-db
turso db shell my-db

見落としやすいのが--tursodbフラグです。このフラグを付けるとRust実装のTurso Databaseが、付けないと従来のlibSQLがプロビジョニングされます。turso-cliのソースでも、db createコマンドがこのフラグの値をAPIのUseTursoDBへ渡す実装になっていることを確認しました。並行書き込みを期待して契約したのに既定のlibSQLを作っていた、という取り違えが起きやすい箇所なので、作成時に明示してください。既存のSQLiteファイルを持ち込む場合は、db createのドキュメントにある--from-fileでローカルのSQLite互換ファイルからDBを作れます。接続用のURLとトークンはturso db showから取得します。

稼働リージョンはAWS 6拠点に、同期方式は埋め込みレプリカからTurso Syncへ

エッジ35拠点からAWS 6リージョンへの移行と東京拠点の提供

Tursoを「世界35拠点以上のエッジにデータベースを置けるサービス」と説明する記事が今も多く残っていますが、これはFly.io時代の姿です。2025年3月17日にTurso CloudのAWS版が一般提供となり、S3を基盤に据えたアーキテクチャへ移りました。有料顧客は同年3月21日を境にFly上のDBを維持するか移行するかを選び、無料プランは同日から自動移行の対象になっています。

現在Cloud APIのロケーション一覧が返すのは次の6拠点です。

国内向けサービスにとっては東京リージョンがあることが実質的な要件を満たします。一方で、地理的分散そのものを目的にTursoを選ぶ理由は薄くなりました。数百拠点規模のエッジ実行基盤と同じ密度をTursoに期待すると、前提が合いません。低遅延を取りに行く手段は次項の埋め込みレプリカ側に移っています。

埋め込みレプリカとTurso Syncの同期方式・オフライン対応の違い

埋め込みレプリカはlibSQLの機能で、アプリのローカルファイルを読み取り用レプリカとして持つ仕組みです。読み取りは常にローカルのurlから、書き込みは既定でリモートのsyncUrlへ送り、成功後にローカルへ自動反映されます。同期はsyncIntervalによる定期実行か.sync()の明示呼び出しで、書き込みを出したレプリカが直後に自分の書き込みを読めることは保証されます。制約も公式に明記されており、同期中にローカルDBを開くと破損の危険があること、ファイルシステムを持たないサーバーレス環境では使えないこと、書き込みの最小単位が4kBのフレームであることの3点は前提として押さえてください。

これを置き換える位置づけで2025年10月8日にベータ公開されたのがTurso Syncです。ローカルの変更を論理的なミューテーションとしてpushし、リモートの変更を物理ページとしてpullするハイブリッド方式で、サーバー・ブラウザ・モバイル・オフラインのいずれでも双方向に同期します。オフライン中の書き込みを前提にできる点が埋め込みレプリカとの決定的な差です。v0.8.0では.NETバインディングでも埋め込みレプリカの接続文字列指定やバッチ実行が追加されており、言語ごとの同期対応は版ごとに差が縮まりつつあります。

言語バインディングの配布先とマネージドを使わないセルフホストの選択肢

Turso Databaseの言語別公式パッケージ配布先と接続方法

Turso Databaseの公式バインディングはGo・JavaScript・Java・.NET・Python・Rust・WebAssemblyです。パッケージの配布先はcrates.ioのturso、npmの@tursodatabase/database、PyPIのpyturso（2026年10月2日時点で0.8.1）、Maven Centralのtech.turso:tursoで、WebAssembly版はJavaScriptバインディングに同梱されます。ブラウザ内で動かす経路がここにあたります。

Rustから使う場合は非同期APIになります。turso = "0.7.2"とtokioを依存に追加して、次のコードがそのままビルドと実行を通ることを確認しました（2026年9月の検証。0.8系での再ビルドは未実施です）。

use turso::Builder;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let db = Builder::new_local("app.db").build().await?;
    let conn = db.connect()?;
    conn.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)", ()).await?;
    conn.execute("INSERT INTO users VALUES (1, 'alice')", ()).await?;

    let mut rows = conn.query("SELECT id, name FROM users ORDER BY id", ()).await?;
    while let Some(row) = rows.next().await? {
        println!("{} {}", row.get_value(0)?.as_integer().unwrap(), row.get_value(1)?.as_text().unwrap());
    }
    Ok(())
}

$ cargo run -q
1 alice

ORM経由で使う場合はSQLite互換がそのまま効き、Drizzle ORM（ドリズル）とは？使い方・Prismaとの比較・型安全な設計を解説【2026年版】で扱ったSQLite対応ORMは接続先を差し替えるだけで動きます。Rustでのマイグレーション運用はSQLx CLI（sqlx-cli）の使い方｜インストール・マイグレーション・オフラインモードをRustで実践の手順を応用できます。全文検索はTurso Database側がtantivyベースの実験的機能、libSQL側は本家のFTS5がそのまま使えるという違いがあるので、FTS5とは？SQLite全文検索の使い方と日本語対応・bm25を前提に選んでください。

RAG用途で気になるベクトル検索は、COMPAT.mdがlibSQLのネイティブベクトル検索と互換の拡張としてvector()、vector_distance_cos()、vector_distance_l2()などの実装済み関数を挙げており、tursodb 0.7.2で実際に距離計算が返ることを確認しました。ただし近似近傍探索のためのベクトルインデックスは実装済み機能ではなくロードマップ項目です。件数が増えると全件スキャンになるため、大規模なベクトル検索を前提にした採用はまだ避けるのが無難です。

PHPやDのコミュニティ提供ドライバはlibSQL側の一覧に載っているものです。Turso Databaseの公式バインディング一覧に無い言語からは、現時点ではlibSQL経由で接続するのが現実解になります。

セルフホストで取れるリモート接続と組み込みエンジンの構成・運用条件

マネージドを使わない選択肢は2つです。ひとつはlibSQL serverを自前で運用し、PostgreSQLやMySQLと同じようにリモートからSQLiteへアクセスさせる構成。ただしlibsql-serverの正式リリースは2025年2月で止まっているため、機能追加を期待せず現状維持で使うという判断が前提です。もうひとつはTurso Databaseを組み込みエンジンとしてプロセス内で動かす構成で、tursodb --sync-serverにより同期サーバーとして待ち受けさせることもできます。どちらもMITライセンスでソースからビルドでき、マネージドから離脱してもエンジンとデータファイルが手元に残ります。

Tursoを採用すべき場面と見送るべき場面を条件で言い切る判断基準

第一に見送るべきは、Postgres互換を要件に入れている案件。2026年7月に始まったばかりで公開パッケージが無く、リポジトリ上も実験的機能に分類されています。Postgresが必要ならPostgresを使ってください。

第二に、ファイルシステムを持たない実行環境で低遅延読み取りを狙う構成。Tursoの遅延面での強みは埋め込みレプリカとTurso Syncというローカルファイル前提の仕組みに寄っており、AWS 6リージョンというネットワーク距離だけを見るなら他のマネージドDBに対する優位は小さくなります。

第三に、厳格な可用性SLAと長期の後方互換保証を先に要求される基幹系。公式FAQ自身が1.0未到達と独立バックアップの必要性を明言しているので、該当するなら1.0宣言まで待つのが妥当です。

第四に、同じ行への書き込みが集中するワークロードで並行書き込みに期待している構成。前述のとおり衝突は行単位で検出されるため、ホットな行を奪い合う処理はやり直しが増えるだけで、スループットは伸びません。

逆に、テナントごとに独立したDBを大量に持ちたい、書き込みロックで詰まっている（かつ書き込み先の行がばらける）、端末側にDBを置いてオフラインでも動かしたい、のいずれかなら無料枠で検証する価値は十分あります。列指向の集計性能を求めている場合は方向が違うので、DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを解説もあわせて比較してください。

既存のSQLiteやPostgreSQLからの移行可否、テナント分割の粒度、バックアップ設計まで含めて判断したい場合は、一創のデータベース設計・移行支援でご相談いただけます。現行DBの書き込み傾向を測ったうえで、Tursoを入れるべきか、本家SQLiteやPostgreSQLのままで足りるかを条件付きで整理します。

よくある質問

エッジSQLiteとは何で、なぜ注目されているのですか？

SQLiteのような1ファイルの組み込みDBを、サーバー・ブラウザ・端末などアプリの手元に置き、必要に応じてクラウドと同期する構成の総称です。注目の理由は拠点数ではなく、読み取りのネットワーク往復を消せること、テナントごとにDBを分ける設計が安く組めること、オフラインでも読み書きできることの3点にあります。Tursoはこの構成を、Rust実装のエンジンとマネージドの同期基盤の両方で提供しています。

TursoとlibSQLはどちらを使えばよいですか？

新規プロジェクトならTurso Databaseです。libSQLのREADME自身が、新規なら Turso を見るべきで、libSQLは保守は続くが新機能はTurso側で開発されていると述べています。既存のlibSQL構成が安定して動いているなら急いで移す理由はありませんが、libsql-serverのリリースが2025年2月で止まっている点は運用計画に織り込んでください。

Tursoは無料で使えますか？

Turso CloudにFreeプランがあり、月額0ドルでDB数100・ストレージ5GB・月間読み取り5億行・書き込み1,000万行・同期3GB・1日分のポイントインタイムリストアが使えます（2026年10月2日時点）。Turso Database本体とlibSQLはMITライセンスのオープンソースなので、自前で動かすぶんには費用はかかりません。

TursoをDockerで動かせますか？

できます。tursodatabase/tursoリポジトリの直下でmake docker-cli-buildを実行してイメージをビルドし、make docker-cli-runで対話シェルを起動する手順が公式READMEに用意されています。

TursoはPythonやLaravelから使えますか？

PythonはPyPIのpytursoが公式バインディングで、本記事の検証もこれを使っています。LaravelなどPHPからは、Turso Database側の公式バインディング一覧にPHPが無いため、libSQLのコミュニティドライバ経由での接続になります。公式サポートの範囲は言語ごとに差があるので、採用前にリポジトリのバインディング一覧を確認してください。

関連記事

• MVCCとは？多版型同時実行制御の仕組みと過去版の回収を実装目線で解説
• シングルテナントとマルチテナントの違い｜比較表・選定基準とテナント分離の実装
• Realm（モバイルDB）とは？SQLiteとの違いとDevice Sync終了後の採用判断を解説
• PlanetScaleとは？無料枠終了後の料金・Vitess/Postgres/Nekiの違いを解説【2026年版】
• FTS5とは？SQLite全文検索の使い方と日本語対応・bm25
• Drizzle ORM（ドリズル）とは？使い方・Prismaとの比較・型安全な設計を解説【2026年版】
• DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを解説
• Cloudflare Workersとは？エッジコンピューティングの基本解説
• SQLx CLI（sqlx-cli）の使い方｜インストール・マイグレーション・オフラインモードをRustで実践