【2026年10月版】
Alopex DB v0.8.16：他社製品との性能比較
公開日: 2026/10/27
読了時間: 約 9分
はじめに
私たちは Alopex DB を Rust で開発し、DataFrame、SQL、KV、ベクトル検索を一つのエンジンで扱えるようにしています。Python からも利用できる API を用意し、後発の DB 開発者として既存の製品やライブラリとの性能比較を重要な開発指標にしています。
概要と結論
Alopex DB v0.8.16 を、単一ホストの Python API を使った固定ケースで Polars、SQLite、PostgreSQL、DataFusion、LMDB、hnswlib、Faiss HNSW と比較しました。DataFrame の構築と embedded KV の永続書き込みは比較対象より速い一方、DataFrame の計算、SQL、KV の読み取り、HNSW 検索は比較対象より遅い結果でした。
比較の前提条件
| 項目 | 条件 |
|---|---|
| 対象バージョン | Python wheel alopex==0.8.16、alopex-server 0.8.16 |
| 実行環境 | AMD Ryzen 5 3500U、Linux x86_64 / WSL2、Python 3.11.11 |
| 測定方法 | 固定データを使い、各 trial の p50 を求め、3 trials の中央値で比較 |
| SQL の比較 | Alopex DB と PostgreSQL を同一ホストの server/client 構成で実行し、既存接続を再利用 |
| KV の比較 | Alopex DB と LMDB の embedded Python API を同一 CPU 上で実行 |
| cache | warm cache |
結果の適用範囲は単一の共有ホスト、固定データ、Python API です。Rust API、分散処理、並行負荷、cold disk I/O、メモリを超えるデータ規模は測定していません。
何を測ったか
| 比較対象 | API の種別 | 比較した操作 |
|---|---|---|
| Polars | DataFrame API | Python データからの構築、構築後の列計算、Python dict への変換、これらを含む複合操作 |
| Polars | Lazy・streaming API | CSV・Parquet の読み取り、列計算、collect、全 batch の取得 |
| SQLite | SQL API | SELECT、transaction、savepoint、prepared query、制約付き INSERT |
| PostgreSQL | SQL API | 集計、並べ替え、全結果取得、永続書き込み、point read、更新、削除 |
| DataFusion | SQL streaming API | 条件に一致する行の取得と全結果の消費 |
| LMDB | embedded KV API | 永続書き込み、point read、上書き、削除、範囲走査 |
| hnswlib・Faiss HNSW | HNSW 検索 API | 同じ検索精度を満たす条件での top-10 検索 |
DataFrame のランダムアクセスとファイルへの書き込み・出力は、今回も測定していません。
性能比較の結果
表の時間比は「Alopex DB の時間 ÷ 比較対象の時間」です。1 未満なら Alopex DB が速く、1 を超える場合は比較対象が速いことを示します。実測時間は各 trial の p50 を求め、3 trials の中央値を取った値です。処理結果が一致した測定のみを掲載しています。
DataFrame とファイル読み取り
| 比較対象 | 評価ケース | Alopex DB の時間 | 比較対象の時間 | 時間比 |
|---|---|---|---|---|
| Polars | Python データから DataFrame を構築 | 18.270 ms | 557.278 ms | 0.033 |
| Polars | 構築済み DataFrame の 12 列計算・collect | 5.405 ms | 3.286 ms | 1.645 |
| Polars | 計算済み 12 列を Python dict へ変換 | 9.975 ms | 10.111 ms | 0.987 |
| Polars | 構築＋中間結果・最終結果の具体化 | 214.644 ms | 775.785 ms | 0.277 |
| Polars | 旧複合操作（構築・計算・Python 変換を含む） | 171.293 ms | 1,264.226 ms | 0.135 |
| Polars | Lazy CSV・12 列計算→collect | 13.843 ms | 7.226 ms | 1.916 |
| Polars | Lazy CSV・12 列計算→全 batch 取得 | 15.149 ms | 7.790 ms | 1.945 |
| Polars | Lazy Parquet・数値等 11 列→collect | 2.916 ms | 3.559 ms | 0.819 |
| Polars | Lazy Parquet・数値等 11 列→全 batch 取得 | 3.648 ms | 4.257 ms | 0.857 |
| Polars | CSV streaming 全消費 | 16.798 ms | 7.299 ms | 2.301 |
| Polars | Parquet streaming 全消費 | 4.984 ms | 4.795 ms | 1.039 |
DataFrame の構築は Alopex DB が速く、構築後の計算は Polars が速い結果でした。複合操作には構築、計算、explode、concat、Python 変換が含まれるため、計算性能だけの比較ではありません。処理別の結果は表の各行で確認できます。
Python dict への変換は試行ごとの幅が重なっており、優劣を判断できません。ファイル読み取りでは、CSV は Polars が速く、今回測定できた Parquet の処理は Alopex DB が速い結果でした。
Polars と同名の select、Series の直接構築と加算、LazyFrame の直接構築、scan_csv、scan_parquet は v0.8.16 で未対応です。Alopex DB 独自の static scan では Lazy 比較を実行できましたが、Parquet の文字列連結を含む 12 列計算は Utf8 と LargeUtf8 の型不一致で失敗しました。私たちは、この 6 つの API・操作と Parquet の文字列計算について、Polars 互換を満たしたとは扱いません。
SQL
| 比較対象 | 評価ケース | Alopex DB の時間 | 比較対象の時間 | 時間比 |
|---|---|---|---|---|
| SQLite | SELECT・transaction・savepoint・prepared query・制約付き INSERT | 33.740 ms | 3.533 ms | 9.551 |
| PostgreSQL | COUNT | 72.274 ms | 5.353 ms | 13.501 |
| PostgreSQL | ORDER BY id LIMIT 16 | 36.333 ms | 1.339 ms | 27.132 |
| PostgreSQL | 17,125 行の全結果取得 | 242.455 ms | 42.426 ms | 5.715 |
| PostgreSQL | INSERT RETURNING＋rollback | 5.289 ms | 2.948 ms | 1.794 |
| PostgreSQL | 単件 INSERT＋commit | 9.302 ms | 4.336 ms | 2.145 |
| PostgreSQL | 100 行 INSERT＋commit | 20.754 ms | 6.200 ms | 3.347 |
| PostgreSQL | random get hit・100 回 | 294.737 ms | 119.212 ms | 2.472 |
| PostgreSQL | random get miss・100 回 | 283.025 ms | 107.088 ms | 2.643 |
| PostgreSQL | random UPDATE＋commit | 11.620 ms | 4.604 ms | 2.524 |
| PostgreSQL | random DELETE＋commit | 220.362 ms | 4.403 ms | 50.053 |
| DataFusion | SQL streaming 全消費 | 59.427 ms | 1.277 ms | 46.522 |
SQL は、今回測定したすべてのケースで比較対象より時間がかかりました。特に DataFusion と比較した連続読み取りと、PostgreSQL と比較した削除に大きな差があります。読み取りから書き込みまで、SQL 全体の改善が必要です。
DataFusion との比較では、Alopex DB は Python 行、DataFusion は Arrow batch を返します。表の値には SQL の実行だけでなく、結果形式への変換と Python 側での全結果消費も含まれます。
embedded KV と HNSW 検索
| 比較対象 | 評価ケース | Alopex DB の時間 | 比較対象の時間 | 時間比 |
|---|---|---|---|---|
| LMDB | 単件 PUT＋commit | 0.996 ms | 2.137 ms | 0.466 |
| LMDB | 順次 100 件 PUT＋commit | 4.529 ms | 5.818 ms | 0.778 |
| LMDB | 投入順 shuffle・100 件 PUT＋commit | 4.272 ms | 5.462 ms | 0.782 |
| LMDB | random get hit・100 回 | 1.257 ms | 0.188 ms | 6.700 |
| LMDB | random get miss・100 回 | 0.241 ms | 0.181 ms | 1.334 |
| LMDB | random overwrite＋commit | 1.061 ms | 2.560 ms | 0.415 |
| LMDB | random DELETE＋commit | 1.104 ms | 2.425 ms | 0.455 |
| LMDB | 範囲走査 1,000 件・全値取得 | 8.797 ms | 0.502 ms | 17.538 |
| hnswlib | HNSW 検索・recall 0.99 以上 | 152.374 µs | 50.534 µs | 3.015 |
| Faiss HNSW | HNSW 検索・recall 0.99 以上 | 152.374 µs | 56.790 µs | 2.683 |
embedded KV は永続書き込み、上書き、削除で LMDB より速い結果でした。今回の固定ケースでは Alopex DB v0.8.16 の強みです。一方、単件の読み取りと範囲走査は LMDB が速く、書き込みと読み取りで対照的な結果になっています。
HNSW はすべての製品が基準とした検索精度を満たしました。その条件では Alopex DB の検索時間が長く、精度を維持したまま高速化する必要があります。
今後の改善
次の開発では SQL streaming と random DELETE を優先して改善します。SQL の読取・書込全般、KV の point read と範囲走査、DataFrame の計算、Lazy CSV、Parquet の文字列計算、未対応の Polars 互換 API も改善対象です。HNSW は recall 0.99 以上を維持しながら検索時間を短縮します。
改善後も同じ入力と API 境界で測定し、数値を公開します。
まとめ
Alopex DB v0.8.16 は、DataFrame の構築と embedded KV の永続書き込みに強みがあります。DataFrame の計算、SQL、KV の読み取り、HNSW 検索には改善が必要です。Polars 互換 API にも未対応の操作があります。
私たちは今回の結果を基準値として改善を進め、変更後の性能も公開します。