Milvus Liteとは？3.x系の対応索引・同時実行の制約・Standalone移行手順

Milvus Liteはpymilvusへ同梱されるPythonライブラリで、ファイル名を1つ渡すだけでローカルにベクトル検索の器ができる仕組みです。ただし日本語で読める解説の多くは2.4系を前提にしており、「FLAT索引しか使えない」「パーティションが無い」といった記述は現在の実装と不一致です。パッケージは2026年5月の3.0系で純Python実装へ書き換わり、8月6日公開の3.2.0ではHNSWや疎ベクトル索引まで通ります。この記事は、3.x系の内部構造、公式ドキュメントの制限表と実装が食い違う3点の確かめ方、本番運用へ置けない理由、そしてStandaloneへ移すときのdump手順と断絶点を実装視点で整理した内容です。Milvus本体そのものの採用判断はMilvusの4層構造とインデックス選定をまとめた記事で扱っています。

まとめ：Milvus Liteを選ぶ3条件と本番運用へ置けない技術的な理由

Milvus Liteを選ぶ条件は3つに絞れます。1つ目は、将来Milvus本体（StandaloneまたはDistributed）へ寄せる前提があること。クライアントAPIが共通なので、検証で書いたコードは接続先の文字列を差し替えるだけで持ち上がります。2つ目は、DockerもKubernetesも介さずにPythonプロセスの中で完結させたいこと。3つ目は、扱うベクトルが数百万件までで、書き手が実質1プロセスに収まること。この3つが揃うなら、ノートブックでもCIのテストでも同じ器が使えます。

本番へ置けない理由は、規模ではなく2点の構造にあります。第一に、データディレクトリあたり1プロセスというファイルロック。gRPCサーバモードを立てても、同一コレクションへの書き込みは直列化され、並行writerは安全に扱えません。第二に、認証・ユーザ・ロール・RBAC・TLSをいずれも持たないこと。逆に言えば、この2点に触れない範囲なら3.2.0の機能面はかなり広く、パーティションもBM25全文検索もハイブリッド検索も通ります。判断で迷ったら、扱う件数ではなく「同時に書くプロセスが2つ以上あるか」「外部から接続を受けるか」の2問で切り分けてください。

Milvus Liteの実体と3.x系で純Python実装へ切り替わった内部構造

まず、何をインストールして何が動いているのかを押さえます。ここを2.4系の記憶のまま進めると、対応索引の判断からずれます。

pymilvusへ同梱されるPythonライブラリという位置づけと導入手順

Milvus Liteはサーバ製品ではなく、アプリケーションへ組み込むPythonパッケージ。導入は2通りで、pip install -U milvus-lite で単体を入れるか、pip install -U "pymilvus[milvus-lite]" でクライアントごと入れます。要求Python版は3.10以上。配布物は py3-none-any の単一ホイールで、プラットフォーム別のビルド済みバイナリを選ぶ必要がありません。

この配布形態の差は大きい。2.4系はC++コアをラップしたネイティブ拡張で、対応OSがホイールの有無に縛られていました。3.x系が純Pythonになったことで、CIの検証範囲はLinuxとmacOSがPython 3.10から3.13、Windowsが3.10へ広がっています。

LSM構造とWAL・Parquetセグメントで組まれた3.x系の内部構成

3.2.0のREADMEは内部構成を明示しています。書き込みはWALへ落ちたうえでインメモリのmemtableへ積まれ、一定量でフラッシュされて不変のParquetセグメントになります。索引はセグメント単位でFAISSが担い、その上にスカラーフィルタとBM25の全文検索、そしてMilvus互換のgRPCアダプタが載る構成です。LSM構造を採るため、追記が続く場面でも書き込みが索引再構築で止まりません。

ここから導ける性質が2つあります。1つは、プロセスが落ちてもWALから復旧できること。3.2.0ではWAL復旧の検証が入りました。もう1つは、セグメントが不変であるがゆえにBM25のIDF統計がセグメントローカルで計算される点です。全セグメントを横断した大域統計ではないため、キーワード検索のスコアは本番のMilvusと一致しません。順位の再現性を確かめたい場合、この差は先に認識しておく必要があります。

2.5系から3.0系への書き換えで前提が変わった時期と版の見分け方

版の履歴を並べると断絶がはっきりします。2.4.1が2024年5月8日、2.5.1が2025年6月30日、2.5.2rc1が2026年2月22日。そして3.0が2026年5月13日に出て、ここで純Python実装への書き換えが行われました。以降は3.1.0が7月15日でTIMESTAMPTZとGEOMETRY型・スカラー転置索引・複数データベースの分離を追加、3.1.1が7月27日、3.2.0が8月6日です。

紛らわしいのは、Milvus本体にもv3.0.0があり、こちらは2026年7月29日のリリースだという点。パッケージと本体は別系列で番号が進むため、「3.0」と書かれた情報がどちらを指すかを毎回確かめてください。手元の版は pip show milvus-lite で分かります。

公式ドキュメントの制限表と3.2.0の実装が食い違う3つの箇所

Milvus Liteで最も事故になりやすいのが、公式ドキュメントのページと実際に入るパッケージの記述差です。2026年8月12日時点で確認したところ、3点が明確にずれていました。

FLAT索引のみという記載と3.2.0の実装が持つ索引一覧の落差

公式ドキュメントのmilvus_lite.mdは制限表で「FLAT索引のみ対応」と書いています。ところが3.2.0のREADMEが列挙する対応索引は、HNSW・HNSW_SQ・IVF_FLAT・IVF_SQ8・FLAT・BRUTE_FORCE・AUTOINDEXに加え、疎ベクトルのSPARSE_INVERTED_INDEXとスカラーのINVERTEDまで並びます。全件走査しかできない、という前提は現行版には当てはまりません。

この差は検証設計に直結します。HNSWのefConstructionやIVF_FLATのnlistを振って再現率の当たりを付ける作業が、Liteの段階でできるかどうかが変わるからです。ただしPQ系（Product Quantization）の索引は3.2.0でも非対応で、量子化でメモリを削る検証は行えません。ベクトル型もFLOAT_VECTORとSPARSE_FLOAT_VECTORの2つに限られ、binary・float16・bfloat16・int8のフィールドを持てない点は変わっていません。

パーティション・全文検索・対応OSの3点で生じている記載のずれ

2点目はパーティション。公式ドキュメントは非対応と書きますが、3.2.0のREADMEはパーティション・エイリアス・イテレータ・group-by検索を対応機能として挙げます。テナントごとにパーティションを切る設計の素振りは、現行版のLite上でも一応できます。

3点目は対応OSで、ドキュメント側は「Ubuntu 20.04以上」「macOS 11.0以上」と限定していますが、READMEの記載はPython依存が満たせるmacOS・Linux・Windowsです。加えて全文検索も、BM25とJieba解析器のオプションまで記載があります。下表に、確認できた3点の差をまとめます。

疎ベクトルとBM25を密ベクトルと束ねる検索の考え方はRRFで統合するハイブリッド検索の実装手順で整理しています。Lite上でも同じAPIで組めます。

手元にインストールした版で対応範囲を確かめるための2つの参照先

どちらを信じるかには、はっきり答えが出せます。手元で動くのはインストールされたパッケージなので、参照先はパッケージ側です。見る場所は2つ。1つはPyPIのプロジェクトページに載る当該版のREADMEで、対応索引・データ型・制約が版ごとに列挙されています。もう1つはGitHubリポジトリのリリースノートで、どの版で何が入ったかが追えます。

要件定義の段階で対応可否を表に落とし、根拠として参照した版番号と確認日を並記しておいてください。「Milvus Liteはパーティション非対応」という一文だけが独り歩きすると、実装フェーズで前提を作り直すことになりかねません。

本番運用へ置けない理由が同時実行とセキュリティへ集約される構造

「小規模向けだから本番には使わない」で終わらせると、どこまでなら踏み込めるかが決められません。制約の中身を分解すると、規模ではない2つの軸が残ります。

データディレクトリ単位で1プロセスに絞られるファイルロックの制約

3.2.0のREADMEが最初に挙げる制約が、data_dirあたり1プロセスという条件。ローカルストレージを守るためにファイルロックを取る実装なので、同じ.dbファイルへ2つ目のプロセスがぶら下がれません。効いてくる場面は具体的です。

• Webアプリをgunicornなどでワーカー複数に分けて起動する構成
• 投入バッチを動かしながら別プロセスで検索APIを提供する構成
• CIで複数のテストジョブが同じデータディレクトリを共有する構成

いずれもロック競合で落ちます。単一プロセスの中で完結する試作か、後述のサーバモードへ切り替えるかの二択。テスト並列化でつまずく場合は、ジョブごとにデータディレクトリを分けるのが最も手数の少ない回避策です。

gRPCサーバモードで並行読みは通るが書き込みが直列化される境界

サーバモードを立てれば複数プロセスから接続できますが、制約が消えるわけではありません。READMEの記述は「並行読みは対応、同一コレクションへの書き込みは直列化が必要で、並行writerは安全に扱えない」。読み中心のワークロードなら複数プロセスから引けます。

裏を返すと、投入が継続的に走る構成はサーバモードでも成立しません。RAGの文書取り込みが日次バッチで、検索は読みだけ、という切り分けならLiteでも回せます。取り込みがリアルタイムに近い頻度で走るなら、その時点でStandaloneへ移す判断になります。書き込み経路が1本に絞れるかどうかが分岐点です。

認証・ロール・TLSを持たない前提で構成が成立しなくなる場面

もう1つの軸がセキュリティで、こちらは回避策がありません。認証・ユーザ・ロール・RBAC・TLSのいずれも実装されておらず、READMEも信頼できないネットワークへローカルgRPCサーバを晒さないよう明記しています。ポートを開ける以上、接続元の制限はOSやネットワーク側で担保するほかありません。

結果として、次の要件が1つでもあるならLiteは検証環境からも外すべきです。テナントごとの権限分離を確かめたい、通信路の暗号化を含めて構成を検証したい、監査ログの出力を要件に含む。いずれもLiteでは素振りすらできず、その状態で作った検証コードは本番の構成を保証しません。

ローカルファイルとサーバモードを切り替えるときの具体的な書き換え点

実装面では、2つの起動方法の差はごく小さい。接続の1行だけが変わります。

MilvusClientへファイル名を渡すだけで起動する最小の実装

ローカルファイルモードは、MilvusClientの引数へパスを渡した時点で埋め込みエンジンが起動します。サーバの準備もコンテナも要りません。最小の流れは次の3行です。

• from pymilvus import MilvusClient でクライアントを取り込む
• client = MilvusClient("demo.db") でファイルを指定して起動する
• client.create_collection(collection_name="docs", dimension=1024) で器を作る

指定した.dbファイルにデータが残るため、プログラムを終了しても同じファイル名で開き直せば内容が戻ります。dimensionは埋め込みモデルの次元に合わせ、距離計算はmetric_typeでCOSINE・L2・IPから選択。索引を明示しないと既定の索引が張られるので、件数が数万を超える検証では索引型を指定してください。

複数プロセスから読むときにサーバモードへ切り替える判断の基準

サーバモードは milvus-lite server --data-dir data --port 19530 のようにデータディレクトリとポートを渡して起動します。接続側は MilvusClient の uri へ 127.0.0.1 の19530番を指定するだけで、コレクション操作のコードは1行も変わりません。ローカルの検証を複数プロセスへ広げたいときの切り替えコストは、ほぼゼロです。

ただしアダプタが実装するのはpymilvusのワークフローのうち対応済みの部分集合で、未対応のRPCはUNIMPLEMENTEDを返します。スキーマ変更とパーティション単位のロード・解放はgRPCアダプタ経由では扱えず、スナップショットも埋め込みAPI側でしか使えません。移行前にアプリケーションが叩くRPCを洗い出しておいてください。

Standaloneへ移すときのdump手順と設計上で断絶する箇所

Liteで作ったものを本番へ持ち上げる工程は、コードとデータで難易度が違います。コードはほぼ無傷、データは書き出しと取り込みを挟みます。

milvus-lite dumpで書き出しBulk Insertへ渡す移行の流れ

データ移行は付属コマンドで行います。milvus-lite dump -d demo.db -c docs -p dump の形式で、対象の.dbファイルとコレクション名、出力先ディレクトリを指定すると、BulkWriter形式のJSONが書き出されます。これをStandaloneまたはDistributed側のBulk Insertへ渡し、Zilliz Cloudの場合はData Importから取り込む流れです。

工程は3つ。Lite側で書き出し、出力を移行先から参照できる場所へ置き、取り込みジョブを投げます。ベクトルとスカラーフィールドの実体は移りますが、あくまでデータの移送であって、コレクションの構成が自動で再現されるわけではありません。移行先ではスキーマを定義したうえで取り込みます。

検証環境から本番へ移すときに作り直しになる索引と権限設定の扱い

持ち越せないものを先に挙げます。索引は移行先で作り直しです。Liteの索引はセグメント単位のFAISSで、Milvus本体の索引実装とは別物。Liteで試したHNSWのパラメータをそのまま持っていくのではなく、本番の件数とメモリ量に合わせて振り直す前提で計画してください。再現率の実測は移行後にもう一度必要になります。

権限まわりは、そもそもLite側に設定が存在しません。ユーザ・ロール・RBACは移行先での新規設計が必要です。パーティションはLite側で切れるものの、パーティション単位のロードと解放という運用操作はgRPCアダプタ経由では扱えず、運用手順も移行先で作ることになります。移行を「コピーすれば終わる工程」と見積もると、この3つで日程が伸びます。

検証の段階からStandaloneを立てたほうが早く済む案件の条件

ここは条件で言い切ります。次のいずれかに当てはまる案件は、Liteを飛ばしてDockerでStandaloneを立てたほうが総工数は少なくなります。1つ目、テナント分離や権限設計が要件に入っている案件。2つ目、投入と検索を別プロセスで並行させる構成が確定している案件。3つ目、量子化やPQ索引でメモリ費を詰める検証が必要な案件。いずれもLiteでは素振りができず、検証結果が本番へ引き継げません。

逆にLiteが効くのは、埋め込みモデルの選定やチャンク分割の当たりを付ける段階。検索精度の傾向はLiteでも見えるため、そこまではファイル1つで回し、構成の検証だけStandaloneへ移す進め方が合理的です。設計の当て方や既存文書の取り込み方から相談したい場合は、RAG構築支援で実装まで含めて対応しています。

Chroma・sqlite-vec・FAISSと並べたときにLiteを選ぶ基準

ローカルで動くベクトル検索の選択肢はLiteだけではありません。並べたときの判断軸は、性能値ではなく行き先です。

将来Milvus本体へ寄せる前提があるかどうかで決まる選定の分岐

Milvus Liteの他にない価値は、Milvus本体とクライアントAPIが共通である一点に尽きます。検証で書いたコレクション定義も検索呼び出しも、接続文字列を替えるだけでStandaloneやDistributedで動く。本番でMilvusを使う見込みがあるなら、ローカル検証もLiteへ揃えるのが素直な選択です。

逆に、本番の行き先が未定なら優先度は下がります。Chromaは組み込み用途の設計が素直で、FAISSは索引アルゴリズムの比較そのものが目的のときに向く。sqlite-vecはSQLiteの拡張として動くため、既にSQLiteでアプリのデータを持っているなら追加の依存が最小で済みます。行き先がMilvusでないなら、Lite特有の制約を引き受ける理由がありません。

Liteを選ばずにpgvectorへ寄せたほうが安く済む2つの場面

2つの場面では、ローカル用のベクトルDBを持ち込まないほうが総額が下がります。1つ目は、PostgreSQLを既に運用していて、ベクトルが数十万件規模に収まる場合。同じDBに収まればバックアップも権限管理も一元化でき、運用対象が増えません。構成の当て方はpgvectorでPostgreSQL上にベクトル検索を載せる方法にまとめています。

2つ目は、検証の目的が検索精度ではなくアプリケーション側の実装確認に寄っている場合。件数が数千件程度なら素の全件走査で十分な速度が出ます。件数と行き先の2つが見えるまでは、依存を増やさない判断が合理的でしょう。

よくある質問

Milvus Liteの導入と制約について、実装時に問い合わせの多い5点をまとめます。

Milvus Liteは無料で使えますか？

Milvus Liteはオープンソースのパッケージとして公開されており、利用料はかかりません。PyPIから pip install -U milvus-lite で導入でき、ローカルのファイルとして動くためサーバ費用も発生しません。課金が発生するのは、移行先としてZilliz Cloudなどのマネージド環境を選んだ場合です。

Milvus LiteはWindowsで動きますか？

3.x系は純Python実装で、配布物も py3-none-any の単一ホイールです。READMEはPython依存が満たせるmacOS・Linux・Windowsを対象としており、CIではWindowsのPython 3.10が検証対象に含まれます。ただし公式ドキュメントのページはUbuntuとmacOSのみと記載したままなので、記述の食い違いを承知したうえで、手元の版で実機確認してから採用を決めてください。

Milvus Liteは何件まで扱えますか？

公式は小規模な検索用途に限ると述べており、目安は数百万ベクトルまでです。ただし件数より先に制約になるのは同時実行で、data_dirあたり1プロセスというファイルロックがあります。件数が少なくても、書き込むプロセスが2つ以上必要な構成であれば、その時点でStandaloneへ移す判断になります。

Milvus Liteで作ったデータはそのまま本番へ移せますか？

付属の milvus-lite dump でBulkWriter形式のJSONへ書き出し、移行先のBulk Insertで取り込みます。移るのはデータの実体で、索引は移行先で作り直しになります。ユーザやロールの設定はLite側に存在しないため、権限設計は移行先で新規に行う前提で日程を組んでください。

Milvus LiteとStandaloneはどちらから始めるべきですか？

埋め込みモデルの選定やチャンク分割の検証が目的ならLiteで足ります。一方、テナント分離・権限設計・並行書き込み・PQ索引による量子化のいずれかが要件に入るなら、最初からDockerでStandaloneを立ててください。Liteでは素振りができない領域で、検証結果が本番へ引き継げません。

関連記事

• Milvusとは？v3.0の外部コレクション・インデックス選定・デプロイ形態：Milvus本体の4層構造と索引の費用設計、デプロイ形態の全体比較はこちらで扱っています
• ベクトル化とインデックス構造から理解するベクトルデータベースの仕組み：索引パラメータの意味から押さえたいときの前提知識です
• Pineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け：インフラ運用を持たない体制での選択肢として比較できます
• Weaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準：テナント分離が要件の中心にある案件での比較対象です
• ChromaDBとは？アーキテクチャ・使い方・pgvectorとの違いまで：ローカル用途で並べたときのもう一方の選択肢です