はじめに
生成AIやAIエージェントの活用には、AIが参照するデータをどう持つかという、データベース側の話が一緒についてきます。
リレーショナル、ドキュメント、ベクトルと形の違うデータを、それぞれ得意な専用データベースに分けて持つのか、1つのデータベースにまとめて持つのか。
この記事で扱うコンバージドデータベース（converged database） は、この「まとめて持つ」アプローチを指す用語です。
この記事は、Oracle Developersブログの What Is a Converged Database? Definition, Five Tests, and AI Use Cases（Rick Houlihan氏、2026年6月）を土台に、この用語「コンバージドデータベース（converged database）」が何を指すのか、そしてなぜRAGやAIエージェントの話とセットで語られるのかを整理したものです。
本記事の位置づけ：本記事は上記のOracleブログの内容を元に、自分なりの解釈も含めて再構成・補足したものです。Oracle公式の見解ではありません。
コンバージドデータベースとは
データベースが扱うデータには、表のような構造のものだけでなく、いくつもの「形（データ型・モデル）」があります。
AI活用の文脈でなぜこの言葉が出てくるのか、例から見ていきます。
小さなECサイトを考えてみます。
AI向けの特別な要件がないサイトでも、業務のデータとAI活用を考えていくと、一般的なユースケースでも形の違うデータが意外と出てきます。
- 注文・明細 — 金額や在庫を厳密な構造・制約で扱う、表（リレーショナル）
- 顧客プロフィール — 人によって持つ項目が違う、入れ子のJSON（ドキュメント）
- 不正検出 — 「同じデバイスを使い回す複数アカウント」のような、関係をたどるグラフ
- 問い合わせの類似検索 — 「この問い合わせと似た過去チケット」を意味の近さで探す、ベクトル
- 近くの店舗 — 緯度経度で計算する、空間（Spatial）
こうしたデータの持ち方には、モデルごとに代表的な専用データベースがあります。
例えば、ドキュメントならMongoDB、グラフならNeo4j、ベクトルならPineconeといったように、それぞれに特化したサービス・ストアとして分けて持つ構成です。
これに対して、1つのデータベースエンジンにまとめて持つ、という考え方がコンバージドです。
ブログ原文の定義を訳すと、次のようになります。
リレーショナル、ドキュメント（JSON）、グラフ、ベクトル、空間、テキストといった複数のデータモデルを、単一のデータベースエンジンがネイティブにサポートし、それらが1つのオプティマイザ、1つのトランザクション境界、1つの一貫性モデル、1つのセキュリティ・ガバナンス領域の下で動き、SQL・ドキュメントAPI・RESTといった開発者が期待するアクセス面から使えること。
長い定義ですが、原文自身が「大事なのはモデルの一覧ではなく、その後ろに続く部分だ」と述べています。
ただ、この定義だけではよくわからないので、言葉の成り立ちから順に、もう少し詳しく見ていきます。
用語が生まれた経緯
コンバージドデータベース（Converged Database） は、Oracleが2020年頃に使い始めた言葉です。
当初の定義は、Maria Colgan氏による「単一のエンジンで、すべての現代的なデータ型と開発パラダイムをネイティブにサポートすること」でした。（M. Colgan, “What is a Converged Database?,” 2020）
つまり、複数のシステムをより少ない（1つ）システムにまとめれば、ライセンスの数もバックアップの数も、システム間を連携させる手間も少なくて済む、というあくまで利便性の話です。このときの「converged」は、主にconsolidation（統合） の意味で説明されていました。
それに対し、その後、次の3つの変化を経て、この言葉の意味合いは変わっていきます。
「1つにまとめると便利」という利便性の話から、1つにまとまっているかどうかが、できること・できないことを決める「構造的な性質」の話になってきていると、ブログ原文で論じられています。順に見ていきます。
変化1：SQL標準の進化
まず挙げられるのは、SQL標準の進化です。
以前は「JSONならMongoDB、グラフならNeo4j」のようにモデルに特化した専用DBを利用して処理を行う必要がありました。
この状況を変えたのが、SQL標準の進化で、それぞれの扱いを得意とする専用のDBが「専売特許」だった機能を、普通のSQL構文として扱えるようになりました。
- SQL:2016 — JSON演算子が言語に入った
- SQL:2023 — ネイティブのJSON型が追加され、新しいパート（ISO/IEC 9075-16、SQL/PGQ）としてグラフのパターンマッチングが標準SQLに入った1
またグラフを使って関係性を辿る処理（グラフ探索）は、独立したデータベースカテゴリだけの能力ではなく、FROM句に書ける1つの構文になりました。
標準SQLの1機能として使えるなら、そのためだけにDBを分ける技術的理由は薄れます。
変化2：AIワークロードの登場
次に、AIワークロードの登場により、同期の待ち時間・ズレが許容されなくなった点が挙げられます。
RAGやAIエージェントは、回答のたびにデータベースからデータを取り出してLLMに渡します。その検索には「鮮度・権限・絞り込み」という性質が同時に必要で、専用DBを同期でつなぐ構成では、この3つがそれぞれアプリ側の作り込みになり実装負担が大きくなります。
この変化については、次の章で詳しく見ます。
変化3：独立した学術的な裏付けの登場
先述の通り、「コンバージド（converged）」は元々Oracle発の言葉です。
ただ、この統合の方向性そのものは、ベンダーと独立した学術文献でも論じられるようになりました。
リレーショナル分野で著名な研究者であるMichael Stonebraker氏（PostgreSQLの前身にあたるPostgresを作った研究者）とAndrew Pavlo氏（カーネギーメロン大学のデータベース研究者）は、2024年のSIGMOD Record論文 What Goes Around Comes Around… And Around… で20年分のデータモデルの変遷を検証し、次のように結論づけています。
- ドキュメントDBはRDBMSと「衝突する軌道」にあり、両者の違いは時間とともに縮まり、将来はほぼ見分けがつかなくなる
- ベクトルDBは本質的に「特殊なインデックス（ANN）を付けたドキュメント指向DBMS」であり、インデックスは「新しいシステムアーキテクチャの基盤ではなく、1つの機能」にすぎない。つまり、新しいデータベース製品カテゴリを立ち上げる根拠にはならない
- 全文検索についても、RDBMS側の検索まわり（SQLへの統合）が良くなり、別製品を立てなくて済むようになれば有益
元々の用語はベンダー発のものでも、それが指すアーキテクチャの起動は独立した論文でも論じられているという整理になります。
コンバージドデータベースとAIの関係
ここからは、コンバージドデータベースとAIの関係を見ていきます。
前の章で述べたとおり、RAGやAIエージェントの検索には「鮮度・権限・絞り込み」が同時に必要です。専用DBを組み合わせる構成でこの3つを満たそうとすると「同期のズレ」が課題となりやすく、コンバージドデータベースはこのズレへの答えとして提示されています。
まず、ズレがどのように生じるのかから確認します。
冒頭に出した例として、注文データはリレーショナルDBやDynamoDB、検索はOpenSearchのような検索エンジン、埋め込みはPineconeのようなベクトルストア、などのように用途ごとに得意な専用データベースを組み合わせ、その間を同期パイプライン（CDCやバッチ）でつなぐ構成を考えます。
この構成では、同じデータのコピーが複数の場所に置かれ、コピーが届くまでの間、検索側には更新前のデータが残っています。このズレは構成の欠陥ではなく、コピーを配る方式に織り込まれた性質で、AIが登場する前から存在していた指摘です。
ただ使い手が人間である間は、許容できる問題でもありました。
例えばECサイトの検索に新商品の反映が数分遅れても許容できたりもします。もしおかしな結果が出ても、画面を見ている人間の目が入る余地があります。
一方で、RAGやAIエージェントは、回答のたびにデータベースから情報を取り出してLLMに渡すので、検索の質がそのまま回答の質になります。
その検索には、次の3つの性質が同時に必要です。
- 鮮度 — たった今更新した内容が、すぐ検索結果に反映されること。別立てのベクトルDBでは、同期ラグの間、AIは古いデータを参照する
- 権限 — 「このユーザーが見てよいデータか」のチェックが、検索の内側で効くこと。DBが1つなら1回の定義で済むところ、データストアが分かれていると、SQL・API・ベクトル検索とアクセス経路ごとにアプリ側で権限を再実装することになり、そこが情報漏えいの穴になり得る
- 絞り込み — 「この顧客の、未解決チケットの中で、似た問い合わせ」のような条件付き検索ができること。ベクトル類似検索とリレーショナルな絞り込みの掛け合わせが必要になる
専用ストアの組み合わせでは、この3つがそれぞれ、同期パイプラインやコードの作り込みの対象になります。
インデックスと実データがズレたとき、LLMは「自信がなさそうに」なりません。
古い事実に基づいて、確信を持って間違えます。
原文はこの状態を State Vector Dissonance（確信を持って幻覚を見ている状態）と名付けています2。
回答するだけのチャットボットなら人間が気づけますが、発注や返金まで自動実行するAIエージェントが相手だと、このラグは直接ビジネスリスクになります。
原文はこの転換を、次の一文にまとめています。
AI did not create the multi-store consistency problem. It removed the tolerance for it.
（AIがマルチストアの整合性問題を生んだのではない。その問題への許容をなくした）
— What Is a Converged Database?
検索側に古いデータが残る問題への対処としては、同期パイプラインを速くする方向もあります。ただ、コピーを送り届ける仕組みである限り、どれだけ速くしても、届くまでの時間はゼロにはなりません。
コンバージドデータベースが取るのは、この方向ではありません。1つのエンジンにまとめて持つことで、同期パイプラインそのものを無くす、という方向です。コピーを作らなければ、届くのを待つ時間も発生しません。
では、どこまで統合されていれば「パイプラインが存在しない」と言えるのか。
それを判定する基準が、次の章の5つのテストです。
「コンバージド」と呼べるかを判定する5つのテスト
「複数のモデルを保存できる」は、製品のストレージ層の性質です。
コンバージドは、その上に載る保証の性質です。
原文はこの2つを分ける基準として、検証可能な5つのテストを挙げています。
| テスト | 満たすとき | 満たさないとき |
|---|---|---|
| 1. トランザクション境界が1つ | リレーショナル挿入・ドキュメント書き込み・ベクトル更新を1つのACIDトランザクションで実行でき、ロールバックも一括で戻る | 途中で失敗すると「1つだけ更新済み」の中途半端な状態が残る |
|
2. オプティマイザが1つ オプティマイザとは「このクエリをどの順番・方法で実行すれば最速か」を考えるDBの頭脳 |
グラフ＋JSON＋ベクトル＋リレーショナルを含む1文に、コスト評価済みの実行計画が1つ作られる | ストアが分かれていると、「まずグラフDBに聞く→結果をループしながらベクトルDBに聞く」という手順をアプリのコードに固定で書くことになる。つまり実行順を考える頭脳が不在で、「結合順序がアプリにハードコードされた分散システム」になる |
| 3. 一貫性モデルが1つ | どのAPI経由でも「書いた直後に読める」が成立する | モデル間の同期パイプラインの分だけ、読める内容が遅れる |
| 4. ガバナンス領域が1つ | 同じ権限・行レベルポリシー・監査ログが、全アクセス経路に適用される | SQL・ドキュメントAPI・ベクトル検索・グラフなど経路ごとにアプリ側で権限を再実装し、監査ログも分散する |
| 5. アクセス面の共有 | SQL・MongoDB互換API・RESTが、同一エンジンの「投影」として同じデータを操作する | ゲートウェイの裏に複数エンジンが並び、入口が1つでも中のトランザクション・一貫性・権限の保証はバラバラのまま |
このうち1と2は、具体例で見るとイメージしやすくなります。
テスト1：4種類の書き込みを1つのトランザクションで
原文の検証リポジトリで最初に示されるのが、次の4つの書き込みを1つのトランザクションにまとめる例です（抜粋）。
INSERT INTO orders ...; -- リレーショナルな注文
INSERT INTO order_items ...; -- その明細
INSERT INTO events (data) VALUES (JSON('{"type":"order_placed"}')); -- JSONドキュメント
UPDATE support_tickets SET embedding = TO_VECTOR('[...]', 8, FLOAT32) WHERE ticket_id = 1; -- ベクトル更新
この4つは、まとめてコミットされるか、まとめて無かったことになるかの2択です。
同じ4つの書き込みを複数の専用ストアに分散させると、各システムの原子性はそれぞれの境界で止まり、全体をまたぐトランザクションAPIはありません。
（例えばPineconeの公式ドキュメントには、インデックス更新が結果整合で、書いたデータがすぐには見えないことを明記されています。）
ロールバックは、失敗パターンごとにアプリ側で書いて保守する補償処理になります。
テスト2：1つのオプティマイザ、1本の実行計画
オプティマイザは、「このクエリをどの順番・どの方法で実行すれば速いか」を統計情報から判断する、データベースの頭脳です。
データベースが分かれていると、この頭脳はまたがるクエリに使えず、「まずグラフDBに問い合わせ、結果をループしながらベクトルDBに問い合わせる」という実行順をアプリのコードに固定で書くことになります。
原文はこの状態を「結合順序がアプリケーションロジックにハードコードされた分散システム」と表現しています。
コンバージド側では、グラフ・JSON・ベクトル・リレーショナルを含む1文にEXPLAIN PLANをかけると、4つのモデルすべてが1本の実行計画に現れます。
グラフを扱うGRAPH_TABLE演算子も内部で通常のSQLに変換され、他と同じオプティマイザでコスト評価されるためです。
テスト3〜5：一貫性・ガバナンス・アクセス面
- 一貫性モデルが1つ — モデル間に同期パイプラインがないため、どのAPIから書いても「書いた直後に読める」が成立する
- ガバナンス領域が1つ — 権限・行レベルポリシー・監査ログを1回定義すれば、どの入口（SQL・ドキュメントAPI・ベクトル検索・グラフ）にも同じルールが効き、監査ログも1本にまとまる
- アクセス面の共有 — SQLもMongoDB互換APIもRESTも、同一エンジンの投影として同じデータを操作する。ゲートウェイの裏に複数エンジンを並べる形だと、入口が1つになるだけで中の保証は分かれたまま
✓ ここまでの整理：複数のモデルを保存できることは、前提にすぎません。保存したモデルの間で、保証（トランザクション・オプティマイザ・一貫性・ガバナンス・アクセス面）が1つにまたがっているか。この5つのテストをすべて同時に通すかどうかが、コンバージドと呼べるかの分かれ目です。
（「複数のモデルを保存できる」タイプのデータベースはマルチモデルデータベースと呼ばれます。コンバージドとの比較はブログ原文では説明されていますが、本記事ではボリュームが大きくなるので踏み込みません。）
なぜドキュメントDBはリレーショナルDBから分かれたのか
まとめて持つ/ コンバージドの方向性（convergence）について話をしてきましたが、分岐（divergence）の流れについても触れていきます。
この分岐の理由には、立場によって異なる説明があります。
リレーショナルDBの側からは、NoSQLの流行はマーケティングが先行した回り道だった、と説明されることがあります。
先ほどのStonebrakerとPavloの論文は、この分岐を主にインピーダンスミスマッチへの不満として説明しています。
プログラムの中では「顧客の中に注文、注文の中に明細」という入れ子の形でデータを扱うのに、リレーショナルDBへは複数の表に分解して保存し、読むときはJOINで組み立て直すことになります。
このアプリとDBの形の食い違いがインピーダンスミスマッチで、オブジェクトをそのままJSONとして保存できるドキュメントDBは、この不満の受け皿になった、という説明です。
一方、原文の著者Rick Houlihan氏は、AWSでDynamoDBのシングルテーブル設計を築き、教えてきた「分かれた側」の当事者で、この分岐をワークロードの実測にもとづく設計判断だったと説明します。
根拠として挙げるのが、Werner Vogels氏（Amazon CTO）が公表した、Amazonがリレーショナルから移行した当時のワークロード分析です。
- リレーショナル操作の約70%は、キーを指定して1行を取るだけのアクセスだった
- さらに約20%は、1つのテーブルから複数行を返すだけだった
つまり9割の操作に、リレーショナルDBの持ち味である結合（JOIN）は不要でした。
この規模でアクセスパターンが決まりきっているなら、結合のコストをリクエストのたびに払うより、あらかじめ答えの形に合わせてデータを持っておく（非正規化する）方が速くなります。
ドキュメントDBへの分岐は、理論への反発ではなく、読み取りを速くするための設計判断だった、という説明です。
ただ、この設計判断が持ち込む非正規化、つまり「コピー」を持つこと / 同じデータの重複はリレーショナル理論が正規化によって取り除こうとしてきた冗長性です。
読み取りのためとはいえ、理論が排除してきたものを設計に戻してよいのか。
リレーショナル理論は冗長性を禁止していたのか
原文はここで、リレーショナルモデルの提唱者であるE. F. Codd（コッド）の論文まで遡ります。
コッド自身は、冗長性を「禁止」ではなく、ワークロード次第のトレードオフとして扱っていました。
- 1969年の研究レポート — 「クエリの負荷が他の操作に比べて重い環境でのみ、強い冗長性は正当化される」[3]
- 1970年の論文 — 冗長性は「追加のストレージと更新時間」を払って「クエリ時間の改善」を得る取引だ、と値付けしている
読み取りが多いなら重複を持ってよく、書き込みが多いなら正規化に寄せる。
冗長性は、読み書きの比率に合わせて回すダイヤルとして、最初から理論の中に含まれていました。
ドキュメントDBの設計者が回してきたのも、この同じダイヤルだった、というのが原文の見方です。
同じ1969年のレポートで、コッドはもう1つの区別も置いていました。
データの「論理的な形」と「物理的な置き方」の分離です。
論理と物理の分離を作り直す仕組み
コッドの区別では、論理モデル（正規化された関係の集合）は正規化されたまま保ち、格納表現（物理的にどう置くか）はワークロードに合わせて選びます。
論理の設計は崩さず、置き方だけを読み書きに合わせて変える、という考え方です。
ドキュメントDBでは、この2つが一体になっています。
保存されるドキュメントの形が、そのまま「読みたい答えの形」だからです。
必要なデータが1か所にまとまっているので読むのは速くなりますが、アクセスパターンを変えたくなったときは、保存されているデータの形ごと作り直すことになります。
原文が「この分離を現代の仕組みで作り直すもの」として紹介するのが、JSON Relational Duality View です。
標準SQLに入っている機能ではなく、Oracle固有の機能です。2023年のOracle Database 23cで登場し、現時点（2026年8月）の最新バージョンOracle AI Database 26aiにも引き継がれています。
Duality Viewは、「customers・orders・order_itemsの表を、次のような入れ子のJSONドキュメントとして見せる」という定義を、ビュー（CREATE JSON RELATIONAL DUALITY VIEW）として書いておく仕組みです。
以後、MongoDB互換のドキュメントAPIからはドキュメントとして読み書きでき、その実体は正規化された表の行です。
JSONのコピーを別に保存しているのではなく、「ドキュメントであり、同時にその行たちである」1つのデータです。
{
"_id": 42,
"_metadata": { "etag": "E9BA8572B721D85E653B49930B83D911" },
"email": "customer42@example.com",
"fullName": "Customer 42",
"segment": "standard",
"orders": [
{ "orderId": 90, "status": "delivered", "total": 273.96,
"items": [ { "line": 1, "productId": 32, "qty": 3, "unitPrice": 273.96 } ] }
]
}
原文の検証スクリプトでは、ドキュメントAPI経由で顧客の属性を更新し、同じ変更をSQLで読み返せることを確認しています。
// ドキュメントAPIで更新して…
col.updateOne({ _id: 42 }, { $set: { segment: 'vip' } });
// …同じエンジンのSQLで読み返す（同期パイプラインなし）
db.aggregate([{ $sql: 'SELECT segment FROM customers WHERE customer_id = 42' }]);
同時に更新がぶつかったときは、ドキュメントに付くetag（変更検知用のタグ）で検知して制御します。
ドキュメントの世界にはドキュメントAPIらしい使い勝手を、リレーショナルの世界には制約・統計・結合を、同じ1つのデータの上で提供する形です。
原文はこの章の考え方を「ドメインをモデリングし、アクセスを投影せよ（Model the domain. Project the access.）」と要約しています。
（データの本体は正規化した表として設計し、アプリから見える形はその投影＝ビューとして宣言する、という意味です。）
関連データをドキュメントの中に埋め込むか、別に持って参照するかといった、ドキュメント設計の判断に一般的な正解はなく、読み書きの比率やアクセスパターンといった要件で決まります。
それはコンバージドでも変わりません。変わるのは、後から選び直すときのコストです。
ドキュメントが正規化された行の投影であれば、アクセスパターンの変更は「データの移行」ではなく「投影の定義の変更」で済みます。
小さなECサイトを1つのエンジンで組む例
最初の章で挙げた、小さなECサイトの例に戻ります。
上記で話した内容が、実際にOracle Databaseでどのように実装されるのかを確認します。
原文はこの例を検証リポジトリ上に実装していて（顧客200人、注文1,000件、埋め込み付きのサポートチケット300件、紹介とデバイスのグラフ、店舗の位置情報）、記事中のコード例はすべてそこで実際に動く形で検証されています。
5つの形のデータに対して5つのデータベースを立てるのではなく、保存されるのは正規化された表だけです。
1つのデータを、コピーも同期パイプラインも作らずに、5つのモデルから扱う形です。
各モデルは、表の上に「見せ方の定義」を足すか、表に「列」を足すかで実現されます。どちらの場合も保存の実体は表のままで、新しい保存場所は増えません。
| モデル | 実現方法 |
|---|---|
| 表（リレーショナル） | 正規化された表をそのまま使う。これが保存の実体 |
| JSON（ドキュメント） | 表の上に、入れ子のJSONとして見せるビューを定義する（CREATE JSON RELATIONAL DUALITY VIEW＝前章のDuality View）JSONのビューを定義した後は、ドキュメントAPIの読み書きをDBが表との間で自動変換します。 |
| グラフ | 表の上に、ノードとエッジの定義を追加する（CREATE PROPERTY GRAPH） |
| ベクトル | 表にVECTOR型の列を足す |
| 空間 | 表に位置情報用の空間型の列を足す |
この土台の上で、モデルをまたぐクエリが1文で書けます。
ある顧客を起点に紹介グラフを1〜4ホップたどり、たどり着いた顧客たちの未解決チケットをベクトル類似度でランキングし、リレーショナルに結合する例です（抜粋）。
WITH ring AS (
SELECT DISTINCT cid FROM GRAPH_TABLE (customer_graph
MATCH (a IS customers) -[IS referrals]->{1,4} (b IS customers)
WHERE a.customer_id = 10
COLUMNS (b.customer_id AS cid))
)
SELECT c.customer_id
FROM ring r
JOIN customers c ON c.customer_id = r.cid
JOIN support_tickets st ON st.customer_id = c.customer_id
WHERE st.status IN ('open','pending')
ORDER BY VECTOR_DISTANCE(st.embedding, :query_vector, COSINE)
FETCH FIRST 10 ROWS ONLY;
なお、原文のこうした主張（「4種類の書き込みが1つのトランザクションでできる」「実行計画が1本になる」「書いた直後に読める」など）はすべて、公開リポジトリ converged-database-lab のスクリプトとして実際に実行されています。
5本の検証スクリプトと20個のアサーションが実際に検証環境で自動実行されており実行状況が公開されています。
まとめ
「コンバージドデータベース」は、複数のデータモデルを保存できることではなく、トランザクション・オプティマイザ・一貫性・ガバナンス・アクセス面という保証がモデルをまたいで1つであることを指す言葉として定義し直されています。
この記事で整理した内容です。
- 定義 — コンバージドデータベースは、複数のデータモデルを保存できること（マルチモデル）ではなく、トランザクション・オプティマイザ・一貫性・ガバナンス・アクセス面という保証がモデルをまたいで1つであることを指す。その判定基準が「5つのテスト」
- AIとの関係 — RAGやAIエージェントの検索には「鮮度・権限・絞り込み」が同時に必要で、専用ストアを同期でつなぐ構成では、この3つがそれぞれアプリ側の作り込みになる。コンバージドの答えは「速い同期」ではなく**「同期パイプラインの不在」**
- 分岐の経緯とDuality View — ドキュメントDBへの分岐は、読み取りを速くするための設計判断だった。冗長性はリレーショナル理論でも当初から読み書きのトレードオフとして扱われており、Duality Viewは「論理は正規化のまま保ち、見せ方は投影として宣言する」という分離を作り直す仕組み
- 実装の形 — 保存されるのは正規化された表だけで、各モデルは表の上に定義を足すか、列を足すかで実現される。書き込みは1つのトランザクションに、モデルをまたぐクエリは1本の実行計画にまとまる
なお、原文が論じているのは構造の話で、性能の比較ではありません。
「コンバージドの方が速いのか」は原文でも本記事でも扱っていないので、切り分けてお読みください。
AI時代のデータ基盤を考える上で、少しでも参考になれば嬉しいです。
参考
- What Is a Converged Database? Definition, Five Tests, and AI Use Cases — Rick Houlihan, Oracle Developers Blog（本記事の土台）
- converged-database-lab（検証リポジトリ）
- M. Stonebraker, A. Pavlo, "What Goes Around Comes Around… And Around…"（SIGMOD Record, 2024）
- M. Colgan, "What is a Converged Database?"（2020）
- P. Eisentraut, "SQL:2023 is finished: Here is what's new"
- W. Vogels, "A Decade of Dynamo"（2017）
- E. F. Codd, "A Relational Model of Data for Large Shared Data Banks"（CACM, 1970）
- J. Lu, I. Holubová, "Multi-model Databases: A New Journey to Handle the Variety of Data"（ACM Computing Surveys, 2019）
- Oracle JSON-Relational Duality Developer's Guide
- Oracle Database API for MongoDB