1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

SurrealDB・ArangoDB・ArcadeDB比較で学ぶマルチモデルDB選定ガイド

1
Last updated at Posted at 2026-06-16

SurrealDB・ArangoDB・ArcadeDB比較で学ぶマルチモデルDB選定ガイド

この記事でわかること

  • マルチモデルデータベースの5つのアーキテクチャ分類と、それぞれの設計思想の違い
  • SurrealDB 3.0・ArangoDB 3.12・ArcadeDBの機能・性能・ライセンスの具体的な比較
  • AIエージェント時代に求められるvector＋graph＋relationalの統合データ基盤の設計方針
  • ユースケース別（RAG、ナレッジグラフ、リアルタイム推薦）のDB選定フローチャート
  • ポリグロットパーシステンスからマルチモデルDBへ移行する際の判断基準と注意点

対象読者

  • 想定読者: MLエンジニアでデータ基盤の設計・選定に関わる方
  • 必要な前提知識:
    • SQLの基礎文法（SELECT、JOIN、WHERE程度）
    • NoSQLデータベース（MongoDB、Redisなど）の基本概念
    • ベクトル検索の基礎（embedding、cosine similarity）— PyTorchやSentence Transformersを使った経験があると理解しやすい
    • グラフデータベースの概念（ノード、エッジ、トラバーサル）— 未経験でも本記事内で解説

結論・成果

マルチモデルデータベースを導入すると、従来5つのデータベースで構成していたMLパイプライン（RDB＋ドキュメントDB＋KVS＋検索エンジン＋グラフDB）を1つに統合できます。SurrealDB 3.xの公式ベンチマークでは、fsync有効下でPostgreSQLに対しWrite性能が約1.5倍、Neo4jに対しCRUD全体で2〜3.5倍の性能が報告されています。一方で、各データモデルの専門性は特化型DBに劣る場合があり、「万能だが浅い」というトレードオフは理解しておく必要があります。

本記事では、2026年時点で注目される3つのマルチモデルDB（SurrealDB 3.0、ArangoDB 3.12、ArcadeDB 26.x）を機能・性能・ライセンス・AIエージェント対応の4軸で比較し、MLエンジニアがプロジェクトに合ったDBを選定するための実践的な指針を提示します。

マルチモデルデータベースの分類を理解する

「マルチモデルデータベース」は一括りにされがちですが、実装アプローチは大きく5つに分類されます。この分類を理解しておくと、各製品の強みと弱みを正確に評価できます。

5つのアーキテクチャ分類

マルチモデルDBの実装方式は、MLフレームワークに例えると理解しやすくなります。

分類 説明 ML類推 代表例
Extension-driven 既存RDBに拡張機能を追加 PyTorchに各種ライブラリをpip install PostgreSQL + pgvector + Apache AGE
Native Engine 1つのエンジンで複数モデルをネイティブ対応 JAX（1つのフレームワークでGPU/TPU/CPU） ArangoDB
Unified Developer Story 統一されたDXを重視した設計 Keras（使いやすさ優先のAPI設計） SurrealDB
Document-Platform ドキュメントDBを拡張して他モデル対応 Hugging Faceのpipeline（タスク特化API） Couchbase
API-level 複数DB互換のAPIレイヤーを提供 ONNX Runtime（複数バックエンド抽象化） Azure Cosmos DB

この分類はDEV Communityの比較分析で提唱されたもので、製品を評価する際の重要なフレームワークです。

なぜ分類が重要なのか

Extension-drivenのPostgreSQLは本番実績が豊富ですが、pgvector・Apache AGE・PostGISなど個別の拡張をバラバラに管理する必要があります。Native EngineのArangoDBは一貫したクエリ言語で操作できますが、対応モデル数がやや狭い。Unified Developer StoryのSurrealDBは広い対応モデルを持ちますが、各モデルの深さは専用DBに劣ると指摘されています。

注意: 「マルチモデル対応」を謳っている製品でも、内部実装はまったく異なります。ベクトル検索一つとっても、ネイティブ実装（SurrealDB、ArcadeDB）と外部ライブラリ統合（ArangoDB→FAISS）では、運用特性が大きく変わります。

SurrealDB・ArangoDB・ArcadeDBを比較する

ここからは、2026年時点で注目される3つのマルチモデルDBを具体的に比較していきます。それぞれの特徴を機能・性能・ライセンス・AIエージェント対応で評価します。

基本スペック比較

まず全体像を把握しましょう。

項目 SurrealDB 3.0 ArangoDB 3.12 ArcadeDB 26.x
初回リリース 2022年 2012年 2021年（OrientDBフォーク）
実装言語 Rust C++ Java
クエリ言語 SurrealQL（SQL-like） AQL（SQL-like） SQL、Cypher、Gremlin、GraphQL、MQL
データモデル 8種（Doc, Graph, KV, Vector, TimeSeries, Search, Geospatial, Relational） 4種（Doc, Graph, KV, Vector） 6種（Doc, Graph, KV, Vector, TimeSeries, Search）
ライセンス BSL 1.1（4年後Apache 2.0） BSL 1.1 Apache 2.0
ACID準拠 はい はい はい
埋め込みモード あり（Rust/WASM） なし あり（JVM）
SDKs Rust, JS, Python, Go, Java, .NET JS, Java, Python, Go, PHP Java, REST API

SurrealDB 3.0の特徴

SurrealDB 3.0は2026年2月にGA（General Availability）を迎えました。Rustで実装されており、8つのデータモデルを1つのSurrealQLクエリ言語で操作できます。

SurrealDBの特徴的な機能はレコードリンクです。これはPyTorchのnn.Module間の参照に似ていて、テーブル間の関係を->構文で直感的にトラバースできます。

-- SurrealQL: ユーザーが書いた記事とそのタグを1クエリで取得
-- PyTorchで例えると model.encoder.attention のようなチェーンアクセス
SELECT
    name,
    ->wrote->article.title AS articles,
    ->wrote->article->tagged->tag.name AS tags
FROM user:alice;

ベクトル検索もSurrealQL内でネイティブに実行できます。

-- HNSW（Hierarchical Navigable Small World）インデックスを定義
DEFINE INDEX idx_embedding ON article
    FIELDS embedding
    HNSW DIMENSION 768
    DIST COSINE;

-- cosine類似度でtop-5の近傍ベクトルを検索
-- <|5|> はk-NNのkを指定する構文
LET $query_vec = [0.12, -0.34, 0.56, ...];
SELECT title, content
FROM article
WHERE embedding <|5|> $query_vec;

SurrealDB 3.0で追加されたComputed Fieldsは、スキーマレベルで計算ロジックを定義できる機能です。

-- スキーマ定義時に計算フィールドを宣言
-- Pythonの @property デコレータに相当
DEFINE FIELD relevance_score ON article
    COMPUTED (views * 0.3) + (likes * 0.7);

-- クエリ時に自動計算される
SELECT title, relevance_score FROM article ORDER BY relevance_score DESC;

なぜSurrealDBが注目されるか:

  • Rust実装による高いメモリ安全性と性能
  • 1つのクエリ言語で8データモデルを操作可能なDX
  • AIエージェントのメモリ層としての設計思想（v3.0〜）

注意点:

SurrealDBは2022年リリースと比較的新しく、本番環境での大規模運用実績は限定的です。DEV Communityの分析では、Production Confidenceが4/10と評価されています。PoC（概念実証）からスタートし、段階的に本番移行する戦略が推奨されます。

ArangoDB 3.12の特徴

ArangoDBは2012年リリースの実績あるマルチモデルDBです。C++で実装され、ドキュメント・グラフ・KVをネイティブにサポートします。バージョン3.12からFAISS統合によるベクトル検索が正式機能になりました。

ArangoDBの強みはAQL（ArangoDB Query Language）の一貫性です。グラフトラバーサルとドキュメントクエリを1つの言語で自然に組み合わせられます。

-- AQL: 2ホップのグラフトラバーサル + フィルタリング
-- ノードから2ホップ以内の関連ドキュメントを取得
FOR v, e, p IN 1..2 OUTBOUND 'users/alice' GRAPH 'social'
    FILTER v.active == true
    RETURN {
        user: v.name,
        relation: e.type,
        depth: LENGTH(p.edges)
    }

バージョン3.12で追加されたベクトル検索機能は、FAISSライブラリを内部に統合しています。

-- AQL: ベクトル検索（FAISS統合、cosine距離）
-- APPROX_NEAR_COSINE で近似最近傍検索を実行
FOR doc IN articles
    LET similarity = APPROX_NEAR_COSINE(doc.embedding, @query_vector, 5)
    SORT similarity DESC
    LIMIT 10
    RETURN {
        title: doc.title,
        score: similarity
    }

ArangoDB 3.12のベクトルインデックスはフィルタリング付き検索をサポートしており、メタデータでの絞り込みとベクトル検索を同時に実行できます。

-- フィルタリング付きベクトル検索（v3.12.6以降）
-- カテゴリで絞り込んだ上でベクトル類似検索
FOR doc IN articles
    FILTER doc.category == "machine-learning"
    LET score = APPROX_NEAR_COSINE(doc.embedding, @query_vector, 5)
    SORT score DESC
    LIMIT 5
    RETURN { title: doc.title, category: doc.category, score }

なぜArangoDBが堅実か:

  • 12年以上の本番運用実績とProduction Confidence 8/10の評価
  • AQLによる一貫したクエリ体験（グラフもドキュメントも同じ言語）
  • FAISS統合でベクトル検索も正式対応

注意点:

ArangoDBは2024年にライセンスをApache 2.0からBSL 1.1に変更しました。無料版は100GBの容量制限があり、Cypher・Gremlin・GraphQLなどの外部クエリ言語には対応していません。既存のNeo4j資産（Cypherクエリ）をそのまま移行することはできない点に注意が必要です。

ArcadeDBの特徴

ArcadeDBはOrientDBの思想を引き継ぎつつ、Javaでゼロから再実装されたマルチモデルDBです。Apache 2.0ライセンスで、Cypher・Gremlin・SQL・GraphQL・MQLと5つのクエリ言語をサポートします。

-- ArcadeDB: Cypherでグラフクエリ（Neo4j互換）
-- Neo4jからの移行が容易
MATCH (u:User {name: 'Alice'})-[:FOLLOWS]->(friend)-[:POSTED]->(post)
WHERE post.created_at > '2026-01-01'
RETURN friend.name, post.title, post.likes
ORDER BY post.likes DESC

ArcadeDBの際立った特徴は埋め込みモードの性能です。JVMプロセス内で直接動作させることで、ネットワークオーバーヘッドを排除し、公式ベンチマークでは2M+ inserts/secの性能が報告されています。

// ArcadeDB 埋め込みモード（JVM内で直接動作）
// PyTorchのin-process推論のようなイメージ
DatabaseFactory factory = new DatabaseFactory("./mydb");
Database db = factory.create();

db.transaction(() -> {
    // ドキュメント作成
    MutableDocument doc = db.newDocument("Article");
    doc.set("title", "Multi-Model DB Guide");
    doc.set("embedding", new float[]{0.12f, -0.34f, 0.56f});
    doc.save();

    // グラフエッジ作成
    Vertex alice = db.lookupByKey("User", "name", "Alice").asVertex();
    alice.newEdge("WROTE", doc, true);
});

2026年3月にはMCPサーバー（Model Context Protocol）が組み込まれ、Claude DesktopやChatGPTなどのAIクライアントからSQLやCypherで直接データベースを操作できるようになりました。

なぜArcadeDBが注目されるか:

  • Apache 2.0ライセンスで制限なく商用利用可能（3製品中唯一）
  • Cypher対応でNeo4jからの移行が容易
  • 埋め込みモードで2M+ inserts/secの高性能

注意点:

ArcadeDBはJava実装のため、JVM環境が必要です。Pythonエコシステムが中心のMLチームにとっては、REST API経由のアクセスが主な選択肢となり、SurrealDBやArangoDBほどPython SDKが充実していません。エコシステムの規模も他2製品より小さく、Stack Overflowやコミュニティでの情報量は限定的です。

ベンチマークで性能を比較する

理論的な特徴だけでなく、実際の性能を数値で比較しましょう。以下はSurrealDB公式がfsync有効（全DBで書き込み時にディスク同期）の条件下で実施したベンチマーク結果です。

CRUD操作のスループット比較

操作 SurrealDB 3.x PostgreSQL MongoDB Neo4j
Create 122k ops/s 83k ops/s 183k ops/s 42k ops/s
Read 254k ops/s 327k ops/s 200k ops/s 174k ops/s
Update 106k ops/s 81k ops/s 160k ops/s 50k ops/s
Delete 156k ops/s 86k ops/s 200k ops/s 44k ops/s

ベンチマーク結果の読み方

この数値を見ると、SurrealDBはWrite系操作でPostgreSQLとNeo4jを上回り、Read系ではPostgreSQLにやや劣る結果です。MongoDBは単純なCRUDでは依然として高いスループットを示しています。

ただし、このベンチマークにはいくつかの留意点があります。

  1. SurrealDB公式による測定であり、独立した第三者検証は発展途上
  2. 単純なCRUD操作であり、JOINやサブクエリを含む複雑なクエリは未測定
  3. 深いグラフトラバーサル（5ホップ以上）での性能比較がない
  4. クラスタ構成での分散性能は含まれていない

ポイント: ベンチマーク数値はあくまで参考値です。実際のワークロードではデータ分布、クエリパターン、同時接続数などで結果が大きく変わります。本番導入前には必ず自分のワークロードで検証してください。

ArcadeDBの埋め込みモード性能

ArcadeDBは公式ベンチマークで10M+ records/secの処理能力を謳っていますが、これは埋め込みモード（JVMプロセス内）での数値です。ネットワーク越しのクライアント・サーバー構成では当然この性能は出ません。

MLパイプラインでJavaアプリケーション内にDBを組み込む場合（たとえばSpark MLlibとの連携）には、このネットワークオーバーヘッド排除の恩恵を最大限に受けられます。

AIエージェント時代のDB選定基準を設計する

2026年現在、AIエージェントのメモリ基盤としてデータベースに求められる要件が急速に変化しています。従来の「CRUD＋検索」から、エピソード記憶（vector）＋ 意味記憶（graph）＋ 状態管理（relational） の3層を同時に扱える基盤が必要とされています。

AIエージェントメモリの3層アーキテクチャ

Mem0の2026年調査レポートによると、AIエージェントのメモリシステムは単純なベクトル類似度検索を超えて進化しており、グラフベースのエンティティ・関係検索との組み合わせが必要とされています。

3製品のAIエージェント対応比較

機能 SurrealDB 3.0 ArangoDB 3.12 ArcadeDB 26.x
ベクトル検索 ネイティブ（HNSW/MTREE） FAISS統合 ネイティブ（JVector）
グラフ探索 SurrealQL ->構文 AQL FOR...IN OUTBOUND Cypher/Gremlin
トランザクション マルチテーブルACID マルチコレクションACID マルチドキュメントACID
AI Agent Memory 公式機能（v3.0〜） コミュニティ対応 MCP Server内蔵
LangChain統合 コミュニティドライバ 公式langchain-arangodb REST API経由
GraphRAG対応 公式ブログで手法公開 HybridGraphRAG実装あり Cypher経由で実装可能

SurrealDBでのGraphRAGクエリ例

SurrealDBでは、ベクトル検索とグラフトラバーサルを1つのクエリで組み合わせられます。これはRAG（Retrieval-Augmented Generation）パイプラインで有用です。

-- SurrealQL: ベクトル検索 → グラフ展開の統合クエリ
-- Step 1: embeddingで類似ドキュメントを検索
-- Step 2: 検索結果からグラフを辿って関連エンティティを取得
LET $query_vec = <model.encode("Rustの非同期プログラミング")>;

SELECT
    title,
    content,
    embedding <|5|> $query_vec AS similarity,
    ->references->concept.name AS related_concepts,
    ->references->concept->used_in->project.name AS related_projects
FROM article
ORDER BY similarity DESC
LIMIT 10;

ArangoDBでのHybridGraphRAGクエリ例

ArangoDBでは、ベクトル検索の結果をグラフトラバーサルに接続するパターンが公式ブログで紹介されています。

-- AQL: ベクトル検索 + グラフトラバーサルの組み合わせ
-- Step 1: ベクトル検索で類似ドキュメントを特定
LET similar_docs = (
    FOR doc IN articles
        LET score = APPROX_NEAR_COSINE(doc.embedding, @query_vector, 10)
        SORT score DESC
        LIMIT 5
        RETURN { doc, score }
)
-- Step 2: 各ドキュメントからグラフを1〜2ホップ展開
FOR item IN similar_docs
    LET related = (
        FOR v IN 1..2 OUTBOUND item.doc GRAPH 'knowledge'
            RETURN v
    )
    RETURN {
        title: item.doc.title,
        similarity: item.score,
        related_entities: related[*].name
    }

ユースケース別の選定フローチャートを活用する

ここまでの比較を踏まえ、ユースケース別にどのDBを選ぶべきかのフローチャートを提示します。

典型的な選定パターン

パターン1: RAGパイプライン構築

  • 推奨: SurrealDB 3.0
  • 理由: ベクトル検索とグラフトラバーサルを1クエリで実行でき、AIエージェントメモリとしての設計思想がRAGのユースケースに合致
  • リスク: 本番運用実績が限定的。重要システムではPoCで性能検証を実施すること

パターン2: 既存Neo4j + Elasticsearchの統合

  • 推奨: ArcadeDB
  • 理由: CypherクエリがそのままNeo4jから移行でき、Apache 2.0で商用利用制限なし
  • リスク: Pythonエコシステムとの連携はREST API経由に限られる

パターン3: エンタープライズ本番システム

  • 推奨: ArangoDB 3.12
  • 理由: 12年以上の本番運用実績、エンタープライズサポート、Gartner Peer Insightsでの評価実績
  • リスク: BSL 1.1ライセンスでDBaaS提供に制限。ベクトル検索は比較的新しい機能

移行時のよくある問題と対策

マルチモデルDBへの移行を検討する際に、よくある問題と解決策をまとめました。

問題 原因 解決方法
クエリ性能が期待に届かない インデックス設計の不備 各データモデル固有のインデックス戦略を事前設計。特にベクトルインデックスはHNSWパラメータ（M, efConstruction）のチューニングが必要
グラフクエリが深いトラバーサルで遅くなる 5ホップ以上のトラバーサル 探索深度に上限を設け、必要に応じてマテリアライズドビューを検討。専用グラフDBが適切な場合もある
既存SQLクエリの移行コストが高い JOIN構文の非互換 SurrealDBはJOIN未対応のため、サブクエリやレコードリンクで書き換え。ArangoDBのAQLではFOR...INでJOIN相当を表現
ベクトル検索の精度が低い embeddingモデルとインデックスの不整合 embeddingの次元数とインデックス設定の整合を確認。cosine/euclidean/dot productの距離メトリクスを用途に応じて選択

ライセンスと運用コストを比較する

技術的な機能だけでなく、ライセンスと運用コストは選定の重要な要素です。特に2024年以降、ArangoDBのライセンス変更（Apache 2.0 → BSL 1.1）は業界に大きな影響を与えました。

ライセンス詳細比較

項目 SurrealDB ArangoDB ArcadeDB
ライセンス BSL 1.1 BSL 1.1 Apache 2.0
OSS変換 4年後にApache 2.0 明記なし 変換不要（最初からOSS）
DBaaS提供 要商用契約 要商用契約 自由
自社サーバー運用 無制限 無料版100GB制限 無制限
埋め込み利用 自由 N/A 自由
商用アプリ組込 自由 無料版100GB制限 自由

注意: BSL 1.1ライセンスは「ソースコードの閲覧・利用・改変は自由だが、同製品をDBaaSとして第三者に提供する場合は商用契約が必要」という制限です。自社システムに組み込んで使う分には制限はありません。MLパイプラインにDBを組み込む用途では通常問題になりません。

運用面の比較

観点 SurrealDB ArangoDB ArcadeDB
クラウドマネージド SurrealDB Cloud（GA） ArangoGraph（GA） なし（セルフホスト）
コミュニティ規模 GitHub 29k+ stars GitHub 13k+ stars GitHub 3k+ stars
公式ドキュメント 充実（日本語なし） 充実（日本語なし） 基本的（英語のみ）
日本語情報 Qiita記事・ブログ少数 Qiita記事・ブログ中程度 ほぼなし

まとめと次のステップ

まとめ:

  • マルチモデルDBは5つのアーキテクチャ分類に分けられ、「マルチモデル対応」の中身は製品ごとに大きく異なる
  • SurrealDB 3.0はAIエージェントメモリ基盤としての設計思想が特徴だが、Production Confidenceは発展途上（4/10）
  • ArangoDB 3.12は12年の本番実績とFAISS統合ベクトル検索で堅実な選択肢だが、BSL 1.1ライセンスと100GBの無料版制限に注意
  • ArcadeDBはApache 2.0ライセンスとCypher互換が強みだが、PythonエコシステムやSDKの充実度では他2製品に劣る
  • ベンチマーク数値は参考値。自分のワークロードでの検証が必須

次にやるべきこと:

  • 自チームのデータモデル要件を洗い出し、上記フローチャートで候補を絞る
  • 候補DBのDockerイメージを使って、実データの一部でPoCを実施する（SurrealDB: docker run surrealdb/surrealdb:v3、ArangoDB: docker run arangodb/arangodb:3.12）
  • ベクトル検索を使う場合は、embeddingモデルの次元数とインデックスパラメータのチューニングを忘れずに行う

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?