この内容は、TORICO 技術勉強会 2025-08-08 のライトニングトークを記事にしたものです。
はじめに
AI(RAG)アプリケーションを開発する際、「ベクトル検索をどのように実装するか」という課題に直面します。
従来は専用のベクトルデータベース（Pinecone、Qdrant、Chromaなど）を検討することが多かったのですが、2025年現在、状況が大きく変わっています。
多くの定番RDBMSが本格的なベクトル検索機能を搭載し、専用ベクトルDBに匹敵する性能を提供するようになったのです。本記事では、各RDBMSのベクトル型対応状況を詳細に調査し、実際のベンチマーク結果と合わせて紹介します。
ところで、「Vector」って日本語でなんて読めばいいか悩みます。「ベクトル」or「ベクター」。他にも「Cursor」「TensorFlow」で同じ悩みがあります。
今回のモチベーション
最初は、「MySQL 9 の Vector フィールドを使って RAG を作る」という企画で進めようと考えていました。
しかし、MySQL 9は Vector フィールドは保存できるものの、近傍検索する関数が無くて実用的な使い方がわからず、断念しました。
そこで周辺知識を調査しました。
MySQL系統
MySQL 9
対応状況
✅ ベクトル型搭載、ただし制限あり
MySQL 9.0では待望のVECTOR型が標準搭載されましたが、実用性には大きな制約があります。最大の問題は、近傍検索に必要なDISTANCE関数が Oracle CloudのHeatWaveサービスでのみ利用可能 である点です。オンプレミス環境では基本的なベクトル型の保存は可能ですが、効率的な検索機能が制限されているため、本格的なベクトル検索用途には不向きと言えるでしょう。
技術仕様
- ベクトル型:
VECTOR(N)(最大16,383次元) - 距離関数:
DISTANCE()(COSINE、DOT、EUCLIDEAN) - 変換関数:
STRING_TO_VECTOR(),VECTOR_TO_STRING()
制限事項
- プライマリキー、外部キー使用不可
- JSON、XML、数値関数との併用不可
- DISTANCE関数は基本的にHeatWave (Oracle Cloud) でのみ利用可能
実用性
オンプレミスでの本格運用は困難
参考資料
MySQL 8
対応状況
❌ ベクトル型なし、JSON型で代用可能（ただし...）
MySQL 8.0 では、標準でベクトル対応はありません。しかし、「一応格納だけはできる」方法として、JSON型にfloat配列を保存することができます。
これは本当に「保存できるだけ」で、近傍検索をするには全データをアプリケーション側に取り出してから計算する必要があります。つまり、10万件のデータがあれば10万件全部をSELECTして、アプリで距離計算するという、なかなか厳しい現実が待っています😅
技術仕様
- ベクトル型: なし
- 代替手段:
JSONフィールドに[0.1, 0.2, 0.3, ...]形式で保存 - 検索方法:
SELECT * FROM tableしてアプリ側で距離計算 - 実用性: 小規模データ（数千件程度）のみ
使用例
-- 一応こんな感じで保存はできる
CREATE TABLE embeddings (
id INT PRIMARY KEY,
text TEXT,
vector JSON -- [0.1, 0.2, 0.3, ...] みたいに保存
);
-- でも検索はこうなる...
SELECT id, text, vector FROM embeddings;
-- ↑ 全件取得してアプリで距離計算するしかないPlanetScale
対応状況
✅ 2025年3月GA、MySQL互換で大規模対応
PlanetScaleは2025年3月に正式リリースされた、MySQL互換の分散データベースサービスです。最大の特徴は、SPANNアルゴリズムを採用した高性能なベクトル検索機能で、RAMの6倍サイズまでのインデックスをサポートします。従来のMySQLの制約を解決し、数十億規模のベクトル検索にも対応できるため、大企業の本格的なAIアプリケーション開発に最適なソリューションです。
技術的優位性
- SPANN アルゴリズム: Space-Partitioned Approximate Nearest Neighbors
- 巨大スケール: RAMの6倍サイズまでインデックス対応
- 最大16,383次元: L2、内積、コサイン距離をサポート
- トランザクション対応: ACID準拠
用途
大規模ベクトル検索が必要な企業向け
参考資料
追記
Planetscale は Postgres も使えるようになっていました。
Announcing PlanetScale for Postgres
MariaDB系統
MariaDB 11.8
対応状況
✅ 2025年6月リリース、企業向けLTS
MariaDBは、11.7以降で標準でベクトル型をサポートしています。
MariaDB 11.8 は、一部のベンチマークでpgvectorより高速な結果を示しており、MySQL の代替として有用なオープンソースソリューションです。
ベクトル型のサポートについて、MySQL9と互換性は無い点は注意が必要です。
技術仕様
- ベクトル型:
VECTOR(N) - 距離関数:
VEC_DISTANCE_EUCLIDEAN(),VEC_DISTANCE_COSINE(),VEC_DISTANCE() - 変換関数:
VEC_FromText(),VEC_ToText() - アルゴリズム: 修正HNSW（Hierarchical Navigable Small World）
パフォーマンス
- 一部環境でpgvectorより高速: Small Datum LLC のベンチマークでは、同期的ワークロードで優位性を示している
- インデックス構築の高速化: 大規模データでの優位性
- SIMD最適化: Intel AVX2/AVX512、ARM NEON対応
MySQL互換性
ベクトル対応においては、関数名が異なるため完全互換ではない（VEC_* vs STRING_TO_VECTOR）
SaaSサービス
SkySQL - AI駆動型サーバーレスDBaaS
参考資料
PostgreSQL + pgvector
pgvector 0.8.0
対応状況
✅ 最も成熟したエコシステム
pgvectorは現在最も成熟したRDBMS向けベクトル検索ソリューションで、PostgreSQLのエコシステムの豊富さを活かした多様なクラウドサービスで利用できます。2024年11月にリリースされたv0.8.0では、WHERE句でのフィルタリング性能が大幅に改善され、HNSW インデックスの最適化も図られています。
技術仕様
- ベクトル型:
vector(float32、最大16,000次元)- （注意）
halfvec、sparsevec、bitの詳細な対応状況については追加調査が必要 - 距離関数: L2（ユークリッド）、内積、コサイン、ハミング、ジャッカード距離
- インデックス: HNSW（高精度）、IVFFlat（メモリ効率）
v0.8.0の新機能
- フィルタリング大幅改善: WHERE句でのパフォーマンス向上
- 反復インデックススキャン: オーバーフィルタリング防止
- HNSW最適化: L1距離対応、並列構築改善
主要クラウドサービス
- AWS RDS PostgreSQL - Amazon RDS for PostgreSQL
- Supabase - 完全統合されたPostgreSQL + pgvectorプラットフォーム
- Neon - サーバーレスPostgreSQL
Supabase Vector
対応状況
✅ pgvector完全統合、プロダクション実績多数
Supabaseは「The best vector database is the database you already have」をスローガンに、PostgreSQL + pgvectorを基盤とした包括的なAI開発プラットフォームを提供しています。単なるpgvectorホスティングを超え、AI開発に必要なツールキット全体を統合した、現在最も注目すべきベクトル検索ソリューションの一つです。
Supabase Vectorの特徴
- 完全統合: PostgreSQL、pgvector、REST API、リアルタイムサブスクリプションが一体化
- AI開発特化: OpenAI、Hugging Face、LangChainとの公式統合
- ハイブリッド検索: 従来のSQL検索とベクトル検索の組み合わせが簡単
- スケール実績: 160万以上のembeddingを管理する本格運用事例
技術的優位性
- 自動生成REST API: ベクトル操作がHTTP APIで即利用可能
- ハイブリッド検索: tsvector（全文検索）+ pgvector（セマンティック検索）
- メタデータ統合: リレーショナルデータとベクトルを同一トランザクションで管理
- エッジ関数: JavaScript/TypeScriptでのembedding生成処理
実用例
-- Supabaseでのベクトル検索テーブル作成
create table documents (
id bigint primary key generated always as identity,
content text not null,
embedding vector(1536) not null
);
-- インデックス作成
create index on documents
using ivfflat (embedding vector_cosine_ops)
with (lists = 100);移行事例
- Mendable: Pinecone → Supabase移行で効率性・精度向上
- Berri AI: AWS RDS → Supabase移行で運用負荷大幅軽減
開発者体験
- ワンクリック有効化: ダッシュボードでpgvector extension即座に有効化
- 豊富なテンプレート: Next.js、Python、LangChainでの実装例
- 充実したドキュメント: セマンティック検索から本格RAGまで完全網羅
参考資料
SQLite系統
Turso (LibSQL)
対応状況
✅ ネイティブベクトル対応確認済み、モバイル最適化 (Local First)
TursoのLibSQLは、SQLiteをベースとしながらクラウドネイティブ機能を追加した革新的なデータベースです。DiskANNアルゴリズムを採用してメモリ使用量を最小限に抑えつつ、モバイルデバイスでも高性能なベクトル検索を実現します。
特にプライバシーを重視するアプリケーションや、オフライン機能が必要なモバイルアプリ開発において、ローカルでのベクトル検索を可能にするソリューションです。
技術仕様
- ベクトル型:
F32_BLOB(n),F16_BLOB(n),BF16_BLOB(n)など6種類 - インデックス:
libsql_vector_idx()with DiskANN - 距離関数: コサイン、L2（ユークリッド）、内積
- 圧縮: float8、1-bit量子化対応
特徴
- SQLite互換: 既存のSQLiteアプリと互換
- メモリ効率: DiskANNでメモリ使用量最小化
- モバイル特化: iOS/Android/React Native対応
- エクステンション不要: ネイティブベクトル検索機能
参考資料
sqlite-vec
対応状況
⚠️ v0.1.6、開発中だが有望
sqlite-vecは、Alex Garciaによって開発された純粋なC言語実装のSQLite拡張です。
依存関係ゼロの軽量設計により、WebAssembly、Raspberry Pi、モバイルデバイスまで幅広いプラットフォームで動作します。
現在は高速なブルートフォース検索に特化しており、中小規模データセットに対して良好な性能を発揮するようです。
特徴
- 純粋C実装: 依存関係ゼロ、軽量
- 全プラットフォーム対応: Linux/macOS/Windows/WASM/Raspberry Pi
- 高速ブルートフォース: 中小規模データに適している
- 量子化サポート: バイナリベクトル対応
現状
開発中、ANN（近似近傍探索）機能は今後追加予定
参考資料
ベンチマーク結果
MariaDB vs pgvector
出典
Small Datum LLCによる詳細なベンチマーク調査では、MariaDBとpgvectorの間で興味深い性能特性が確認されています。
結果
- 低・高並行性: MariaDBが優位な性能を示す
- 中並行性: 性能差は縮小するが、MariaDBがやや上回る
- インデックス構築時間: MariaDBが高速
- チューニングの容易さ: MariaDBは複雑なパラメータ設定が不要
MariaDB vs RediSearch
出典
MariaDB公式によるann-benchmarksを使用した包括的な比較調査では、MariaDBとRediSearchの競争関係が明らかになっています。
結果詳細
- 小規模データセット（MNIST、Fashion-MNIST）: MariaDBが最高QPS、RediSearchが2位
- 大規模データセット（GIST 100万ベクトル）: RediSearchがわずかにリード、MariaDBが僅差の2位
- インデックス構築時間: MariaDBがRediSearchより高速
- スケーラビリティ: MariaDBが並列接続で優秀な性能を発揮
選択指針
本番サービス
会員DBや商品DBなどと併用 (多用途)
-
AWS Postgres + pgvector
-
Supabase
-
Planetscale
単機能に特化・モバイル最適化
- Turso
社内ツール
-
MariaDB セルフホスト
-
Pgvector セルフホスト
避けるべき選択肢
- MySQL 9.0（オンプレミス）: HeatWave限定の制限により実用性に難
- MySQL 8.0以下: ベクトル検索機能なし（JSON型での代用は非現実的）
