SQLiteだけでRAGは作れるか？——sqlite-vecとエッジデータベースが拓くローカルファーストAI検索の現在

はじめに：なぜSQLiteでRAGが再び注目されているのか

RAG（Retrieval-Augmented Generation）を構築すると聞いて、多くの人がまず思い浮かべるのはベクトルデータベースの選定でしょう。Embeddingを保存し、近傍検索を走らせるために、QdrantやChromaといった専用DBを立てるか、Postgresにpgvectorを載せたサーバを別途用意する——ここ数年、それが標準構成とされてきました。しかし、この構成には避けられない運用コストがつきまといます。コンテナの起動、インデックスの管理、監視。そして何より「そもそも、その規模感でサーバを立てる必要があるのか？」という根本的な問いです。個人用のナレッジベース、エッジデバイス上の検索、オフラインで動かしたいAIエージェント——こうしたワークロードの多くは、実は「Postgres+pgvectorを立てるほどでもない」ケースに少なくなく相当すると考えられます。

この問いに答える形で、SQLiteをデータ基盤として再評価する潮流が続いています。背景にあるのは2つのマクロトレンドです。1つはエッジへのコンピュート移動。もう一つはローカルファーストUXの台頭です。興味深いのは、この2つが一見別々の現象でありながら、どちらも同じ結論に帰着することです。すなわち「ネットワーク往復をなくす」。計算をデータの近くで、あるいはデータをコードのそばに置いて実行する——この要件を最も素直に満たすのが、四半世紀以上運用され続けてきた単一ファイルのデータベース、SQLiteなのです。

そしてこの潮流は、ベクトル検索の世界にも届いています。sqlite-vecという拡張を使えば、SQLiteファイル1個にベクトルを保存してKNN検索ができる。2026年1月には「SQLite of Vector Databases」を掲げる新興エンジンのZvecが登場し、Turso/libSQLやCloudflare D1といった「SQLite的な」エッジデータベースも着実に成熟しつつあります。モデルや依存パッケージを事前に取得した環境であれば、外部通信なしに動作するRAGを構成することも現実的です。

本記事では、「SQLiteだけでRAGは作れるのか？」という問いに正面から答えます。sqlite-vecの実力と限界、新興のZvec/Turso/D1の位置づけ、Ollamaと組み合わせたオフラインRAGの構築ステップ（※事前取得環境での利用を前提）、そしてpgvectorや専用ベクトルDBとの使い分けの基準まで、順を追って見ていきましょう。

【主要概念①】sqlite-vecとは？——SQLiteにベクトル検索を足す拡張の仕組み

RAGの要となる「ベクトルの保存と近傍検索」を、SQLiteにそのまま足すのが sqlite-vec です。開発者はAlex Garcia氏（asg017）で、旧拡張 sqlite-vss の後継 として開発されています〔参考文献1, 3〕。最大の特長は 純C言語・依存関係ゼロ で書かれている点です。「SQLiteが動くところならどこでも動く」を掲げ、Linux/macOS/Windowsはもちろん、ブラウザ上のWASMやRaspberry Piでの動作も明示されています〔参考文献1〕。Mozilla Buildersプロジェクトをはじめ、Fly.io・Turso・SQLite Cloud・Shinkaiなどがスポンサーとして支援しています〔参考文献4〕。

vec0仮想テーブルとKNNクエリの書き方

sqlite-vecの中核は vec0 仮想テーブルです。float / int8 / binary（ビット） の3種類のベクトルを保存でき、ベクトル以外の値はmetadata・auxiliary・partition key列に置けます〔参考文献1〕。Pythonなら pip install sqlite-vec 一発で導入できます。

import sqlite3
import sqlite_vec  # pip install sqlite-vec

db = sqlite3.connect("local_rag.db")
db.enable_load_extension(True)
sqlite_vec.load(db)
db.enable_load_extension(False)

テーブル作成とKNN（近傍）検索は、通常のSQLとほぼ同じ書き味で書けます。

-- 8次元のfloatベクトルを保存するvec0仮想テーブル
CREATE VIRTUAL TABLE vec_docs USING vec0(
  doc_embedding float[8]
);

INSERT INTO vec_docs(rowid, doc_embedding)
VALUES (1, '[0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8]');

-- クエリベクトルに距離が近い順に5件を取得するKNN検索
SELECT rowid, distance
FROM vec_docs
WHERE doc_embedding MATCH '[0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.9]'
ORDER BY distance
LIMIT 5;

WHERE <列> MATCH '<クエリベクトル>' ＋ ORDER BY distance ＋ LIMIT k——この1文がKNN検索のすべてです〔参考文献1〕。

⚠️ コード利用時の注意点 上記のコード例は、執筆時点（2026年8月）の公式READMEおよび関連ドキュメントに基づく参考例です。sqlite-vecはpre-v1（v1.0未満）であり、バージョンによってAPIや構文が変更される可能性があります〔参考文献1〕。実際に導入する際は公式リポジトリの最新情報をご確認ください。

brute-force＋量子化という割り切り

性能面は割り切った設計だと理解しておく必要があります。sqlite-vecの基本は brute-force（全件走査） であり、pgvectorのHNSWのようなANN（近似最近傍）インデックスを標準では持ちません〔参考文献2, 17〕。代わりにベクトルをint8/bitへ量子化して計算量を抑えるのが定石です。リポジトリにはIVFやDiskANNを含むKNNベンチマーク基盤（benchmarks-ann）が存在し、ANN系構成の実験は進められていますにすぎず〔参考文献2〕、現時点では「実験的な構成」と捉えるのが安全です。件数の増加に対して線形に遅くなるため、大規模コーパスでは後述の比較で見る専用ベクトルDBやpgvectorが選択肢に入ります。また、sqlite-vecは pre-v1 であり、破壊的変更が入り得る点も公式に明記されています〔参考文献1〕。

embedding生成までSQLの世界で閉じる

同じ開発者の関連拡張として、OpenAI・Nomic・OllamaなどのリモートAPIからテキストembeddingを生成する sqlite-rembed（※テストやSQLスクリプト向け）と、.gguf形式のローカルembeddingモデルから生成する sqlite-lembed が公開されています。これらを併用すれば、「embedding生成 → vec0テーブルへの保存 → KNN検索」までをSQLの世界だけで完結できます。RAGに必要な部品がすべて1つのSQLiteファイルに収まる——これが「SQLiteだけでRAGを作れる」と言われる技術的な根拠です。

【主要概念②】「SQLite的な」ベクトルDB・エッジDBはどう進化している？——Zvec、Turso/libSQL、Cloudflare D1

2026年現在、SQLiteのエコシステムは単なる単一ファイルの枠を超え、エッジコンピューティングやローカルファーストの潮流に合わせて「SQLite的な」思想を持つ多様なベクトル・エッジデータベースへと進化しています。ここでは、その代表格である Zvec、Turso/libSQL、Cloudflare D1 の3つのアプローチを取り上げ、それぞれの特徴と位置づけを見ていきます。

Zvec：エッジ向けに設計された組み込みベクトルエンジン

Zvec は、2026年1月にAlibabaのTongyi Lab（通義実験室）がオープンソース化した（ライセンス: Apache 2.0）、エッジ・ローカル向けの組み込みベクトルエンジンです〔参考文献5, 6〕。ここで重要なのは、ZvecはSQLiteの拡張ではなく、独立した組み込みベクトルエンジンであるという点です。名称や「SQLiteのように簡単に組み込める」というコンセプトからSQLiteの派生と誤解されがちですが、内部構造やアーキテクチャは異なります。

Zvecの最大の特徴は、モバイル端末やデスクトップアプリなどのリソースが限られた環境でも動作するよう、高度なメモリ制御が施されている点です。基盤にはAlibaba開発のベクトルエンジン「Proxima」を採用しており、公式ブログ（VectorDBBenchを用いた自家ベンチマーク）の主張では、同等ハードウェア・同等条件において8,000 QPSを超えるスループットを記録し、当時のリーダーボード上位の2倍以上の性能を発揮するとされています〔参考文献5〕（※この数値はベンダーによる自家ベンチマークに基づくものであり、執筆時点で第三者機関による検証は確認できていません）。

また、メモリ管理機能として「64MBチャンクのストリーミング書き込み」「mmapによるオンデマンドロード（総データがRAMを超過してもOOMを回避する機構）」「実験的なプロセスレベルのメモリ上限設定（memory_limit_mb）」を備えています〔参考文献5〕。さらに、ビルトインのリランカー（RRF等）やスカラー・ベクトルハイブリッド検索も内蔵しています〔参考文献5〕。

Turso / libSQL：read-local / write-remoteの分散モデル

Turso は、SQLiteのオープンソースフォークである libSQL をベースにした、エージェント時代に向けた分散・マネージドデータベースプラットフォームです〔参考文献8, 9〕。「millions of agents」を掲げるTursoエコシステムは、ローカルファースト開発に選択肢を提供しています〔参考文献7〕。

Tursoの核心にあるのが Embedded Replicas（組み込みレプリカ） モデルです。アプリケーションはローカル環境にSQLiteファイル（レプリカ）を直接保持するため、データの読み取りはローカルファイルに対してマイクロ秒単位で高速に実行されます。一方、データの書き込みはリモートのプライマリデータベースへ送信され、プライマリから変更分（WALフレーム）がバックグラウンドでローカルに非同期同期されます〔参考文献8, 9〕。

これにより、「ネットワーク往復の遅延を減らしたいローカル処理」と「複数クライアント間でのデータ共有」を両立させています〔参考文献8, 9〕。データベースのブランチング機能や、1ユーザーにつき1つのデータベースを割り当てるper-tenantモデルなども提供されています〔参考文献7〕。

Cloudflare D1：Workersと完全統合されたエッジ分散SQLite

Cloudflare D1 は、Cloudflare Workersのインフラ上で動作する、サーバーレスなエッジ分散SQLiteデータベースです。

D1が力を発揮するのは、グローバルに分散するエッジワーカーとの統合にあります。Global read replication 機能を有効にすることで、世界各地のロケーションに読み取り専用レプリカが自動配置され、ユーザーの地理的により近い場所からデータを取得できるようになります〔参考文献10〕。

運用上の注意点として、レプリカを活用するためには D1 Sessions API の利用が必須となります。Sessions APIを使用することで、セッション内のクエリに対して逐次一貫性（sequential consistency）が保証されますが、レプリケーション自体は非同期で行われるためレプリカラグの考慮が必要です〔参考文献10〕。また、書き込みは常にプライマリ側に転送され、容量上限等の制限はプランや仕様に依存するため、エッジ関数を活用した軽量なAPIバックエンドや個別テナント向けの状態管理に適した設計となっています〔参考文献10〕。

このように、SQLite的な思想を受け継ぎながらも、組み込み特化（Zvec）、ローカル・リモート同期（Turso/libSQL）、エッジマネージド（Cloudflare D1）へと進化するデータベース群が出揃ったことで、開発者はユースケースに応じた軽量データ基盤を選べるようになっています。

独自比較表：sqlite-vec / Zvec / Turso / D1 / pgvector / Qdrant / Chroma はどう使い分ける？

ここまでの検討で、SQLiteエコシステムやエッジ、そして従来の専用ベクトルDBに至るまで、多様な選択肢が出揃いました。それぞれの技術的特徴や強みを俯瞰するために、主要なベクトル検索・エッジDBソリューションを7つの軸で比較してみましょう。

※表は執筆時点（2026-08-16）の公式ドキュメント・リポジトリおよび参考文献に基づく筆者整理。仕様や数値は変更され得る場合があります。「未確認」は公式情報での確認が取れなかった項目を示します。

この比較表をもとに、実際のプロジェクトでどのデータ基盤を選ぶべきか、以下の3つの判断軸で整理することができます。

1. 既存のPostgreSQL資産・運用の有無 すでに本番環境でPostgreSQLを運用しており、チームに管理ノウハウがある場合は、新規に別システムを立てるよりも pgvector を採用するのが堅実です。HNSWインデックスなどの成熟したANN検索やトランザクション処理の恩恵をそのまま受けられます。
2. データ規模とリコール・パフォーマンス要件 コーパスが数千〜数万件程度の小規模、またはオンデバイスやエッジ環境であれば、依存関係が最小限である sqlite-vec が有力な候補になります（実際の適否は埋め込み次元やハードウェア要件次第です）。一方、モバイルやCLIなどのエッジ環境でより厳密なリソース制限や高スループットを求める場合は、Alibaba発の組み込みエンジンである Zvec が選択肢に入ります〔参考文献5〕。コーパスが大きく、高負荷なワークロードでは、要件次第で Qdrant など専用ベクトルDBの検討に進むのが現実的です。
3. オフライン・エッジ・ネットワーク分離の必須要件 インターネット接続に依存しない環境や、Raspberry Piなどのローカルサーバ、クライアント端末単体で完結させたい場合は、ファイル1個で動く sqlite-vec や Zvec が有力な選択肢となります〔参考文献1, 5〕。逆に、クラウドエッジ全体でのグローバルな読み取り同期やリアルタイムなデータ配信が必要な場合は、Cloudflare D1 や Turso（embedded replicasモデル）の分散SQLiteアーキテクチャが力を発揮します〔参考文献8, 10〕。

【実践】sqlite-vec + OllamaでオフラインRAGは作れる？——ステップバイステップ

選択肢の全体像は見えてきました。ここからはいよいよ実践です。sqlite-vecとOllamaの2つだけで、どこまで本格的なRAGが作れるのか、実際に試してみましょう。

graph TD;
    subgraph offline["🌐 ネットワーク境界をまたがない構成（モデル事前取得後）"]
        A["📄 ドキュメント群"] --> B["✂️ チャンキング（分割）"]
        B -->|チャンク本文| C["🧮 Ollama：ローカル埋め込み"]
        C -->|ベクトル挿入| D[("🗄️ SQLiteファイル<br>vec0テーブル＋FTS5インデックス")]
        B -->|原文挿入| D
        Q["❓ ユーザーの質問"] -->|質問本文| C
        Q -->|クエリ本文| D
        D -->|① KNNベクトル検索| R["🔀 RRF（ランキング融合）"]
        D -->|② FTS5全文検索| R
        R -->|上位k件のチャンク| G["💬 Ollama：ローカルLLM生成"]
        G --> ANS["✅ 根拠付き回答"]
    end

上の図が目指す構成です。必要なモデルと依存パッケージを事前に取得済みの環境では、実行時に外部ネットワーク境界をまたぐ経路がなく、外部APIキーの管理やクラウド課金も不要で済みます（初回のモデル取得・pipインストール時を除く）。以下、5ステップで組み立てます。

ステップ①：sqlite-vecのインストールとロード

Pythonならpip install sqlite-vecだけで導入でき、Node.js・Ruby・Goなどの公式バインディングも揃っています〔参考文献1〕。拡張のロードは1呼び出しです。

pip install sqlite-vec ollama

import sqlite_vec
from sqlite3 import connect

db = connect("rag.db")
db.enable_load_extension(True)
sqlite_vec.load(db)  # vec0拡張をロード

ステップ②：vec0仮想テーブルを作成する

ベクトルの保存先は通常のテーブルではなく、vec0仮想テーブルです。次元数は埋め込みモデルの出力に合わせてください〔参考文献1〕。

CREATE VIRTUAL TABLE chunks USING vec0(
  chunk_id INTEGER PRIMARY KEY,
  embedding float[768]  -- 次元はモデル依存
);

floatのほかint8・binary（ビット）ベクトルも指定でき、量子化による省メモリ化が定石です〔参考文献1, 17〕。

ステップ③：Ollamaでembeddingを生成して挿入する

埋め込み生成はローカルLLM実行環境のOllamaに任せます。事前にollama pull nomic-embed-textでモデルを取得しておけば、以後の通信は発生しません。あとはチャンクごとにembedを呼んで挿入するだけです。

import ollama
from sqlite_vec import serialize_float32

for cid, text in chunks:
    vec = ollama.embed(model="nomic-embed-text", input=text)["embeddings"][0]
    db.execute(
        "INSERT INTO chunks(chunk_id, embedding) VALUES (?, ?)",
        (cid, serialize_float32(vec)),
    )

ステップ④：MATCH構文でKNN検索する

検索時も質問文を同じモデルで埋め込み、MATCH構文に渡します。ORDER BY distance LIMIT kで距離順の近傍が返る、SQLらしい直感的な書き味です〔参考文献1〕。

qvec = ollama.embed(model="nomic-embed-text", input=question)["embeddings"][0]

rows = db.execute(
    """
    SELECT chunk_id, distance
    FROM chunks
    WHERE embedding MATCH ?
    ORDER BY distance
    LIMIT 5
    """,
    (serialize_float32(qvec),),
).fetchall()

ステップ⑤：FTS5ハイブリッド＋RRFで仕上げる

sqlite-vecの検索はbrute-force（全件走査）のため、キーワード一致に強いFTS5全文検索と併用するのが定石です〔参考文献2, 17〕。順位ベースで複数のランキングを統合するRRF（Reciprocal Rank Fusion）なら、実装は十数行で済みます。

CREATE VIRTUAL TABLE chunks_fts USING fts5(content);

def rrf(rankings, k=60):  # k=60はRRF元論文の定番値
    scores = {}
    for ranking in rankings:  # [KNNの順位リスト, FTS5の順位リスト]
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

融合して上位のチャンクをプロンプトに詰め、Ollamaの生成モデルに渡せば回答が返ります。ここまでの部品は「SQLite・Ollama・Python」で構成可能です。

動く実例はすでに出揃っている

「本当に動くのか？」への答えもいくつか存在します。1つ目はsqlite-ollama-ragで、SQLite＋Ollamaによる映画レコメンドRAGのデモとしてインフラレスの構成を示しています〔参考文献14〕。2つ目のsqlite-rag-mcpは、まさにステップ⑤の「sqlite-vec＋FTS5＋RRF＋ローカルOllama埋め込み」構成をうたうMCPサーバで、Claude等のMCPクライアントから検索できるようにした実例です〔参考文献15〕。3つ目はdanicat.devの記事による、Google ADK＋Ollama＋SQLiteによりOsqueryのスキーマを引けるオフラインエージェントを構築するチュートリアルです〔参考文献16〕。

なお、sqlite-vecがpre-v1（v1.0未満）で破壊的変更があり得る点、コーパスの増加に対してbrute-force検索が線形に遅くなる点は留意してください〔参考文献1, 2, 17〕。個人ナレッジベースやRaspberry Piでの小規模運用には有力な候補になりますが、大規模になるなら量子化の併用か、ANNを持つベクトルDBへの移行を検討してください。

【ケーススタディ】SQLiteルネサンスの文脈で読む——LiteFSの状況、mvSQLite、そして「単一ノード+Litestream」

sqlite-vecを正しく位置づけるには、近年の「分散SQLite」の試行錯誤史を押さえておくと見通しが良くなります。

まずはLiteFS（Fly.io）です。FUSEでSQLiteのWALを横取りし、アプリのコードを変えずにクラスタへレプリケーションする仕組みで注目を集めましたが、開発は2024年半ばに事実上停止し、2025年にはメンテナンスモードへ移行したと報じられています〔参考文献21〕。この試みが育てた「単一プライマリ+WALフレーム同期」という設計語彙は、libSQL（Turso）やCloudflare D1に継承されていると見られます〔参考文献8, 10, 21〕。

mvSQLiteはVFSレイヤーをFoundationDBに差し替え、直列化可能なトランザクションとマルチライタを実現した実験でした。本番採用は広くは広がらず、現在はアーカイブとして残る状態です〔参考文献12〕。

一方、現役で運用されているのがrqliteです。Raft合意の上にSQLiteを載せたCP型の分散構成で、小規模クラスタ（目安として3〜7台とされる）をHTTP APIで自己運用します〔参考文献21〕。IoTや産業ゲートウェイ向きの構成で、公式ドキュメントにはrqlited -extensions-path経由でsqlite-vecを組み込む言及もあります〔参考文献13〕。

こうした系譜を経て、「多くのケースは単一ノードSQLite+Litestreamで足りる」という経験則が一部の開発者コミュニティで共有されるようになっています（厳密な網羅的調査に基づくものではなく、経験則としての位置づけです）〔参考文献21〕。動向解説によれば、Litestreamの作者であるBen Johnson氏が分散の複雑さを経験した末にシンプルさに行き着いた経緯も伝えられています〔参考文献21〕。LitestreamはWALをS3等へほぼリアルタイムでストリーミングし、PITR（任意時点復元）を構成できます〔参考文献21〕。

ローカルファーストアプリの潮流も同じ方向を向いています。Ink and Switchのエッセイに始まる流れでは、ElectricSQL・Replicache・PowerSyncといった「クライアント側SQLiteとサーバを同期する」エンジン群が中心となり、データの一次的な居場所は手元へ移りました〔参考文献21〕。RAGはここから「語彙」を借りられます。ローカルの知識ベースをローカルで検索する——それはローカルファーストなRAGそのものです。

そして自宅サーバ勢にとって選択肢になるのが、sqlite-vecの動作環境にRaspberry Piが公式に明記されている点です〔参考文献1〕。Piに外付けSSDを繋ぎ、Ollamaでembeddingと生成を賄い、sqlite-vecで検索、Litestreamでバックアップ。この構成なら常時稼働でも消費電力を抑えやすく、家庭向けのプライベート検索基盤の候補として有力だと筆者は考えています。

よくある質問（FAQ）——SQLite RAGの疑問に答える

sqlite-vecは何万件のベクトルまで実用？

sqlite-vecの検索はbrute-force（全件走査）方式のため、ベクトル件数に比例して検索時間が伸びていきます〔参考文献2, 17〕。公式に示された具体的な実用限界件数は今回の調査では確認できていません。ただしint8やビット（binary）量子化と組み合わせてスキャンコストを抑えるのが、オンデバイスRAGの基本パターンとして紹介されています〔参考文献2, 17〕。コーパスが大きくなりレイテンシが許容できなくなったら、HNSW等のANNインデックスを持つpgvectorやQdrant、あるいはANNとリソース制御を備えるZvecへの移行を検討するのが現実的な線引きです〔参考文献2, 5, 17〕。

SQLiteでRAGは本番で使える？

結論は要件次第です。sqlite-vec自体はpre-v1（v1.0未満）であり破壊的変更があり得ると公式が明記しており、無条件の本番推奨はできません〔参考文献1〕。一方で、sqlite-vec+FTS5+RRF等を用いてオフラインRAGをMCPサーバ化するような実例は存在します〔参考文献15〕。オフライン性・データを端末外に出さないプライバシー要件・小規模コーパスが要件なら、検討に値する選択肢と言えます〔参考文献15〕。より本番準備を前面に出したい場合、「production-ready」をうたうZvecの検討価値もあるでしょう〔参考文献5〕。

pgvectorとどう違う？選ぶ基準は？

3つの軸で判断できます。①既存Postgres運用の有無——pgvectorはPostgresへの追加拡張なので、PG資産がすでにあるなら運用を一元化できます。②データ規模・recall要件——pgvectorはHNSW等のANNインデックスを持ち大規模コーパスに強い一方、sqlite-vecはbrute-forceのため件数に比例して遅くなります〔参考文献2, 17〕。③オフライン/エッジ要件——sqlite-vecは依存ゼロでWASMやRaspberry Piでも動きます〔参考文献1〕。この使い分けは前述の比較表にまとめてあります。

ANNインデックスは使えるの？

sqlite-vec本体が提供するのはbrute-force（全件走査）検索で、ANNインデックスは組み込まれていません〔参考文献2, 17〕。公式リポジトリにはbenchmarks-annというベンチマーク基盤があり、IVFやDiskANNなどのANN系構成の評価が行われていますが、現時点では実験的な位置づけと扱うのが安全です〔参考文献2〕。今すぐ確実に使えるのは、int8・ビット量子化によるスキャンコストの削減です〔参考文献2, 17〕。近似を許容できない高recall要件や大規模コーパスで本格的なANNが必要なら、pgvectorやZvecを選ぶのが現実的です〔参考文献2, 5, 17〕。

データのバックアップ・耐障害性は？

単一ファイルDBゆえの割り切りが必要な部分です。ただしSQLiteは標準でWAL（先行書き込みログ）を持つため、Litestreamを使えばWALをS3などへほぼリアルタイムでストリーミングし、ポイントインタイムリカバリ（PITR）が構成できます〔参考文献21〕。「単一ノードSQLite+Litestreamで十分」という姿勢は、LiteFSのメンテナンスモード移行後に一部の開発者コミュニティで共有されている経験則でもあります〔参考文献21〕。多地域レプリケーションなどのクラスタ耐障害性が必要な場合は、TursoやCloudflare D1の検討へ進んでください〔参考文献8, 10〕。

Zvecとsqlite-vec、どちらを選ぶ？

「SQLite上に載せたいか」が最初の分岐です。sqlite-vecはSQLite拡張なので、既存のSQLiteデータベースやSQL資産、FTS5とのハイブリッド検索をそのまま活かせます。対してZvecはSQLite拡張ではなく独立の組み込みベクトルエンジンであり、64MBチャンクのストリーミング書き込みやmmap、メモリ上限設定といったエッジ向けリソース制御、RRF内蔵のハイブリッド検索を備えます〔参考文献5〕（※性能数値はベンダー自家測定です〔参考文献5〕）。SQLの世界で完結させたいならsqlite-vec、検索性能とリソース制御を優先するならZvecが候補になります〔参考文献1, 5〕。

まとめ：RAGの「最小構成」はSQLiteで組み立てられる

冒頭の問い「SQLiteだけでRAGは作れるか？」への答えは、小規模・エッジ・オフライン用途なら条件付きでYesです。「RAGにはベクトルDBの別立てが不可欠」という常識は、要件によっては「SQLite系の選択肢」で置き換えられるケースが出てきた、と言えるでしょう。embedding生成からベクトル保存・検索までSQLの世界で閉じられる——RAGの「最小構成」をSQLiteファイル1個で組み立てられる時代になった、というのが本記事の到達点です。

選択フローも振り返っておきましょう。

• 単一ノードで足りる → sqlite-vec + Litestream（WALのS3ストリーミングでバックアップまで完結）〔参考文献21〕
• 複数端末・エージェント間で同期したい → Turso embedded replicas（読み取りはローカルでマイクロ秒、公式ドキュメントによる）〔参考文献8〕
• エッジ関数から呼びたい → Cloudflare D1（Workers統合のグローバル読み取り）〔参考文献10〕
• 大規模コーパス・既存Postgres資産がある → pgvectorやQdrantなど専用DBへ

迷ったら、まず手元で動かしてみるのがおすすめです。実践セクションで紹介した最小構成なら、モデル取得済みの環境であれば、外部ネットワーク接続なしでRAGを手早く試せます。sqlite-vecはRaspberry Piでも公式に動作すると明記されているので〔参考文献1〕、自宅サーバの余っているPiにローカル知識ベースを積んでみるのも良い次の一歩です。まずは小さく始め、要件が育ったときに初めてスケール先を考える——それがSQLiteルネサンス流のRAG設計です。

参考文献・出典

本記事内の技術的事実・仕様・数値は、執筆時点（2026-08-16）に以下の情報源を確認して記述しています。

sqlite-vec関連（公式・一次情報）

1. sqlite-vec GitHub (asg017) — 基本仕様、vec0構文、対応プラットフォーム（Linux/macOS/Windows/WASM/Raspberry Pi）、pre-v1の注意事項
2. sqlite-vec KNNベンチマーク (benchmarks-ann) — brute-force設計およびANN系構成の実験的評価
3. Alex Garcia, "I'm writing a new vector search SQLite Extension" — 開発背景
4. Mozilla Builders, "Sponsoring sqlite-vec to Enable More Powerful Local AI Applications" — スポンサーシップ情報

Zvec関連（公式・一次情報）

5. Zvec Official Blog, "Zvec: The SQLite of Vector Databases"（2026-01-20） — 発表日、開発元（Alibaba Tongyi Lab）、Apache 2.0ライセンス、Proxima基盤、8,000QPS超の自家ベンチマーク主張、メモリ制御機能
6. Zvec GitHub (alibaba/zvec) — 公式リポジトリ

Turso / libSQL関連（公式・一次情報）

7. Turso 公式サイト — エージェント向けデータベース、ブランチング等
8. Turso Docs, "Embedded Replicas Introduction" — read-local / write-remoteモデル、マイクロ秒単位のローカル読み取り
9. libSQL Embedded Replication (DeepWiki) — 同期メカニズムの補足情報

Cloudflare D1関連（公式・一次情報）

10. Cloudflare D1 Docs, "Global read replication" — Global read replication機能、D1 Sessions APIの必須性、逐次一貫性、非同期レプリケーション

分散SQLite系譜・動向解説（二次情報・公式）

11. LiteFS GitHub (superfly/litefs) — LiteFSの仕組み
12. mvSQLite アーカイブ (V-Sekai-archive/mvsqlite-2026-07-22) — mvSQLiteの状態
13. rqlite 公式ドキュメント (Extensions) — sqlite-vec組み込みの言及
14. inferablehq/sqlite-ollama-rag — SQLite + Ollamaによる映画レコメンドRAGデモ
15. giuseppeferretti/sqlite-rag-mcp — 100%オフラインRAGをMCPサーバ化した実例
16. danicat.dev, "ADK、Ollama、SQLite を使用してオフライン Agent を構築する" — オフラインエージェント構築チュートリアル
17. Qiita (0h-n0), "sqlite-vec・ObjectBox・LanceDBで実装するオンデバイスRAG" — brute-force設計の解説
18. youngju.dev, "SQLite ルネサンス 2026 — 24歳の単一ファイルDBがなぜ最もホットなインフラになったのか" — マクロトレンド、LiteFS開発停止/メンテナンスモード移行、Litestreamの活用、rqliteクラスタ規模に関する動向解説

関連記事

• SQLite-Vectorが切り拓くエッジAIのベクターサーチ：組み込みデータベースで実現するプライバシーファーストなセマンティック検索
• 究極のGraphRAG環境を構築：LightRAGとMemgraphによる次世代情報検索基盤