DocumentDBは、PostgreSQLの拡張として実装されたMongoDB互換のドキュメント指向データベースです。Microsoftが2025年に公開したあと2025年8月25日にLinux Foundationへ移管され、いまはMITライセンスのベンダー中立プロジェクトとして開発が続いています。ややこしいのは同名のサービスが3つ(OSS版のDocumentDB、Azure DocumentDB、Amazon DocumentDB)あることです。2026年9月時点の一次情報をもとに、OSS版の中身・同名サービスとの線引き・本番採用の可否を整理します。
まとめ
- DocumentDBはMicrosoftの製品ではなくLinux Foundationのプロジェクト。2025年8月25日にMITライセンスで移管され、技術運営委員会(TSC)11名のうち4名はAmazon所属です。
- 実体はPostgreSQL拡張2本+ゲートウェイの三層。
pg_documentdb_coreがBSON型を、pg_documentdbがCRUD APIを、pg_documentdb_gwがMongoDBワイヤプロトコルの変換を担います。 - Azure DocumentDBは別物で、OSS版をエンジンに使うマネージドサービス。2025年11月18日にGAとなり、旧称は「仮想コアベースのAzure Cosmos DB for MongoDB」です。
- AWSのAmazon DocumentDBは名前が重なる別のサービス。AWS自身は2025年8月24日にOSSのDocumentDBプロジェクトへ参加しており、製品選定上の競合とOSS開発での協力は同時に成り立っています。
- 本番投入の前に更新手順の検証が要る。最新のv0.117-0でも「以前のリリースからのインプレースアップグレードは未サポート」と明記され、ネイティブパッケージの更新はクリーンホストへの新規インストールが案内されています。
本番採用の判断では、ライセンスだけでなく、導入構成ごとの更新・復旧手順を確認する必要があります。
DocumentDBの正体|Linux Foundation管理下のMIT実装とMicrosoftの立ち位置
DocumentDBの出自と2025年8月のLinux Foundation移管
Linux Foundationのプレスリリースは、このプロジェクトの出自を「DocumentDB project began in 2024 as a pair of PostgreSQL extensions designed by Microsoft」と説明しています。BSONのデータモデルとドキュメントクエリをPostgreSQLエコシステムへ持ち込む拡張が出発点で、GitHubのリポジトリ作成は2025年1月22日です。
そこから約7か月後の2025年8月25日、アムステルダムで開催されたOpen Source Summit EuropeでLinux Foundationへの参加が発表されました。同日付のMicrosoft公式ブログは、参加の狙いを「create an independent identity for DocumentDB and provide a conduit for any database provider to contribute to our mission」と書いています。プロジェクトの法人格は「DocumentDB a Series of LF Projects, LLC」で、リポジトリのGOVERNANCE.mdに置かれたTechnical Charterは「Adopted August 21, 2025」と日付を明記しています。
「MicrosoftのNoSQLデータベース」という説明は、2025年8月以降は正確ではありません。Microsoftは移管後も開発に参加していますが、プロジェクトはLinux Foundationの枠組みで運営されています。
MITライセンスとリポジトリの現在地
ライセンスはMITで、Microsoftのブログも「Under the MIT license, users have the utmost freedom to use the project as they please」と述べています。MITライセンスはサービス提供を認めていますが、ソフトウェアのコピーや重要部分には著作権表示と許諾表示の保持を求めます。リポジトリはgithub.com/documentdb/documentdbに移っており、旧microsoft/documentdbへのアクセスは現在そこへリダイレクトされます。スター数は2026年9月22日時点で3,446で、移管を発表した2025年8月時点のプレスにある「nearly 2,000 GitHub stars」からおよそ1.7倍に増えています。
ベンダー中立が形式だけでないことは、MAINTAINERS.mdに載るTSCの顔ぶれに表れています。11名の内訳はMicrosoft 4名、Amazon 4名、AB InBev・Rippling・YugabyteDBが各1名で、Chairを務めるAbinav Rameesh氏はMicrosoft所属です。Linux Foundationのプレスは支持企業として「Amazon Web Services (AWS), Cockroach Labs, Google, Microsoft, Rippling, SingleStore, Snowflake, Supabase, Ubicloud, and Yugabyte」を挙げており、クラウド大手3社が同じテーブルに着いています。
ドキュメント指向データベースとして提供される機能の範囲
READMEが挙げる守備範囲は、BSON型のネイティブサポート、CRUD、集約パイプライン、全文検索、地理空間クエリ、ベクトル検索です。プロジェクトサイトのdocumentdb.ioはさらに、単一フィールド・マルチキー・複合・テキスト・地理空間の各インデックスをネストしたフィールドにも張れること、ベクトル検索の実装がpgvectorであること、認証がSCRAMであることを示しています。
PostgreSQL側から見ると、これはJSONBとは別系統の選択肢です。BSONという独立した型を持ち込み、MongoDBのクエリ構文をそのまま受けます。JSON列の設計を標準機能で完結させたい場合はPostgreSQL JSONBの使い方|json型との格納差・GIN索引と正規化列の設計境界の整理が近く、そもそもRDBとNoSQLのどちらを選ぶかという段階ならデータベースとは?種類・DBMS・RDBとNoSQLの選び方を実装目線で解説が出発点になります。
アーキテクチャ|PostgreSQL拡張2本とゲートウェイの三層構成
pg_documentdb_core・pg_documentdb・pg_documentdb_gwの役割分担
READMEは「The project comprises of three components」として3つを挙げています。pg_documentdb_coreはBSONデータ型とその演算をPostgreSQLに導入する拡張、pg_documentdbはドキュメントに対するCRUD機能を提供する公開APIの面、pg_documentdb_gwはユーザーのMongoDB APIをPostgreSQLのクエリへ翻訳するゲートウェイ層です。
この分割により、ゲートウェイを立てずに拡張だけ入れてSQLからBSON列を操作する使い方も成立します。既存のMongoDBアプリをそのまま繋ぐならゲートウェイが必要で、その有無で要求されるPostgreSQLのバージョンも変わります。
v0.117-0で選ぶべきPostgreSQLのバージョンとパッケージ
2026年9月22日時点の最新リリースは、2026年9月10日公開のv0.117-0です。v0.111-0が2026年5月11日、v0.113-0が6月22日、v0.116-0が8月24日と、ほぼ月次で刻まれています。そのリリースノートは、パッケージとPostgreSQLの対応をこう定めています。documentdbメタパッケージはPostgreSQL 18を選択し、PostgreSQL 17を使うならdocumentdb-17を選んでメタパッケージを外す。ネイティブのゲートウェイ構成にはPostgreSQL 16以降が必要で、PostgreSQL 15向けのネイティブパッケージは拡張のみ(extension-only)の提供です。
同じリリースで挙動が変わった点がひとつあります。RUMインデックスライブラリの読み込み設定documentdb.rum_library_load_optionの既定値が、PostgreSQL 18以降限定から全サポート対象メジャーでrequire_documentdb_extended_rumになりました。拡張だけを手動で入れる構成ではdocumentdbに加えてdocumentdb_extended_rumも自分で作る必要があり、リリースノートは「CREATE EXTENSION documentdb CASCADE does not create it」と明記しています。CASCADEに任せていた手順書はここで止まります。
| 構成 | 必要なPostgreSQL | パッケージ |
|---|---|---|
| ゲートウェイあり(MongoDBドライバ接続) | 16以降 | documentdb(PG18)/documentdb-17 |
| 拡張のみ(SQLから利用) | 15以降 | extension-onlyパッケージ |
| 手動インストール時の追加拡張 | 全メジャー共通 | documentdb_extended_rumを個別作成 |
Dockerでの起動とpymongoからの接続手順
評価目的なら、公式が配布するローカル用イメージが最短です。
docker pull ghcr.io/documentdb/documentdb/documentdb-local:latest
docker tag ghcr.io/documentdb/documentdb/documentdb-local:latest documentdb
docker run -dt -p 127.0.0.1:10260:10260 --name documentdb-container documentdb \
--username YOUR_USERNAME --password YOUR_PASSWORD
latestではなくghcr.io/documentdb/documentdb/documentdb-local:pg17-0.117.0のようにPostgreSQLのメジャーとリリースを固定したタグも配布されているので、検証環境では版を固定してください。ユーザー名とパスワードはコンテナ作成時に渡します。あとから足せないため、認証が通らないときはまずこの引数を疑ってください。次のPython例ではPyMongoを使います。実行するPython環境に、あらかじめpython -m pip install pymongoでインストールしてください。
import pymongo
client = pymongo.MongoClient(
'mongodb://YOUR_USERNAME:YOUR_PASSWORD@localhost:10260/'
'?tls=true&tlsAllowInvalidCertificates=true'
)
db = client['quickStartDatabase']
col = db.create_collection('quickStartCollection')
col.insert_one({'name': 'John Doe', 'email': '[email protected]'})
print(col.find_one({'name': 'John Doe'}))
ポート10260と自己署名証明書でつまずく箇所
既定ポートはMongoDB標準の27017ではなく10260です。READMEはローカルの他のデータベースとの衝突を避けるための既定だと説明し、27017へ変える場合はdocker runのポート指定と接続文字列の両方を書き換えるよう注意しています。片方だけ直して繋がらない事故はここで起きます。
接続文字列のtlsAllowInvalidCertificates=trueは、ローカルイメージが自己署名証明書を使うためのものです。証明書の検証を無効にする指定なので、クイックスタートの文字列を本番や共有環境へそのままコピーしないでください。
Azure DocumentDBとの違い|OSSエンジンとマネージドサービスの線引き
旧称「仮想コアベースのAzure Cosmos DB for MongoDB」からの改称とGA
2025年11月18日、AzureのマネージドサービスとしてAzure DocumentDBが一般提供(GA)になりました。Azure Cosmos DB Blogの告知は「Azure DocumentDB, a fully managed MongoDB-compatible database service based on the open-source DocumentDB governed by the Linux Foundation, is now generally available. It was formerly known as vCore-based Azure Cosmos DB for MongoDB」と書いています。Azureの日本語製品ページも「Azure DocumentDB (旧称: 仮想コアベースの Azure Cosmos DB for MongoDB)」と併記しています。
新規サービスではなく既存のvCoreベース製品の改称なので、すでに使っているなら移行作業は発生しません。GA告知が挙げる特徴は、コンピューティングとストレージを独立にスケールする課金モデル、HAとリージョン間レプリカを組み合わせた構成で提供される99.995%のフルスタックSLA、Entra ID認証とカスタマー管理キー(CMK)への対応です。日本語製品ページは無料のバックアップ保持期間を最大35日間、Freeレベルのストレージを32GBと記載しています。
Azure DocumentDBとAzure Cosmos DB for NoSQLの選定軸
紛らわしいのは、Azure Cosmos DBというブランド自体は残っている点です。RU(要求ユニット)課金のAzure Cosmos DB for NoSQLは別系統の製品として存続しており、DocumentDBエンジンとは無関係です。Azure DocumentDBとAzure Cosmos DB for NoSQLを比べるなら、MongoDBドライバを使う前者と専用SDKを使う後者という区別になります。ただしAzure Cosmos DBにはMongoDB互換のRU課金版も残っており、Microsoftはそのよくある質問で、既存のMongoDBアプリを移行する用途にはAzure DocumentDBの検討を案内しています。RU課金や整合性レベルの選び方はAzure Cosmos DBとは?マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断を実装者目線で解説で整理しています。
| 項目 | DocumentDB(OSS) | Azure DocumentDB | Azure Cosmos DB for NoSQL |
|---|---|---|---|
| 提供形態 | 自己運用 | フルマネージド | フルマネージド |
| ライセンス/課金 | MIT | コンピューティング+ストレージ | RU課金 |
| クライアント | MongoDBドライバ | MongoDBドライバ | Cosmos DB SDK |
| 実行場所 | 任意(ローカル・他クラウド) | Azure | Azure |
| SLA | なし | 99.995%(HA+リージョン間レプリカ) | 製品SLAに準拠 |
GA告知は、Kubernetes OperatorがAzure・AWS・GCP・オンプレミスにまたがってクラスタを管理できる点を、マルチクラウド戦略の根拠に挙げています。OSS版で開発してAzure DocumentDBへ移す流れは、公式も想定した使い方です。
Amazon DocumentDB・MongoDB・FerretDBとの関係整理
同名のAmazon DocumentDBは別製品だが、AWSはプロジェクトの当事者
AWSのAmazon DocumentDBは、MongoDB互換のマネージドデータベースという点は似ていますが、別のサービスです。AWSは2025年8月24日のオープンソースブログでDocumentDBプロジェクトへの参加を表明しています。Azure DocumentDBが公式ドキュメントでオープンソースのDocumentDBを基盤だと明記しているのに対し、AWSはAmazon DocumentDBがこのエンジンを採用しているとは説明していません。日本語圏で「DocumentDB」と検索したときに上位へ並ぶのは、ほとんどがこちらの解説です。料金体系やインスタンス設計はAmazon DocumentDBとは?MongoDB互換マネージドDBの仕組み・料金・採用判断を実装者目線で解説を参照してください。
製品としての比較と、OSS開発での協力関係は分けて捉える必要があります。AWSはLinux FoundationのDocumentDBプロジェクトに支持企業として名を連ねているだけでなく、TSC 11名のうち4名を送り込んでいます。自社のマネージド製品を持ちながら共通のOSSエンジンの設計にも関与する、という二重の立場です。
MongoDB本体との違いはライセンスと互換の方向
MongoDB本体のサーバーはServer Side Public License(SSPL)バージョン1、2018年10月16日付のライセンスで配布されています。SSPLはサービスとして提供する際に運用スタック全体のソース公開を求める条項を持ち、クラウド事業者がマネージドサービスを作る障壁になってきました。DocumentDBのMIT採用は、この前提への回答です。
互換性の方向にも注意が要ります。Technical Charterが掲げるのはMongoDBのオープンソースドライバとの互換性を可能にすることであり、MongoDB Atlasの機能全体は対象ではありません。公式ドキュメントのhello応答例が示すワイヤプロトコルの対応範囲はminWireVersion: 0からmaxWireVersion: 21までで、対応・未対応の機能を一覧にした公式の対照表は用意されていません。Atlasの全文検索やAtlas固有の運用機能を前提にした構成は、そのままでは移せません。Atlas側の機能構成はMongoDB Atlasとは?クラスタ階層・料金・セキュリティ設定と採用判断を実装者目線で解説【2026年版】にまとめています。
FerretDBはDocumentDBをバックエンドエンジンとして採用済み
MongoDB代替として知られるFerretDBは、2025年3月5日公開のv2.0.0でバックエンドをDocumentDBに切り替えました。READMEは自らの構成を「uses PostgreSQL with DocumentDB extension as a database engine」と説明し、配布するDockerイメージにDocumentDB拡張入りのPostgreSQLを同梱しています。DocumentDB側のREADMEもFerretDBの統合に言及しており、参照は相互です。
| 名称 | 提供元 | ライセンス/形態 | DocumentDB(OSS)との関係 |
|---|---|---|---|
| DocumentDB | Linux Foundation | MIT | 本体 |
| Azure DocumentDB | Microsoft | マネージド | エンジンとして採用 |
| Amazon DocumentDB | AWS | マネージド | 別実装(AWSはTSCに参加) |
| FerretDB | FerretDB Inc. | Apache-2.0 | バックエンドに採用 |
| MongoDB | MongoDB, Inc. | SSPL v1 | 互換対象(ドライバ・ツール) |
DocumentDBの採用判断|本番運用の制約と評価用途
インプレースアップグレード未対応という運用上の壁
導入検討で最初に見るべきはバージョン番号です。最新のv0.117-0は1.0に到達しておらず、これは体裁の問題ではなく運用手順に直結します。リリースノートは互換性の節でこう宣言しています。「Pre-GA upgrade policy: In-place package upgrades from earlier releases are not supported yet. Use a clean host for a fresh installation」。
ネイティブパッケージを旧版から更新する場合は、クリーンなホストへの新規インストールが案内されています。パッケージを削除してもデータベースファイルは残るので再インストールがデータ初期化になるわけではありませんが、この制約だけで全構成のローリング更新可否は判断できません。Operatorにはバイナリ更新とスキーマ更新を分ける手順があり、停止時間や移行可否は構成ごとの検証が必要です。
Kubernetes Operatorもプレビュー段階
本番運用を想定するならKubernetes Operatorが選択肢ですが、こちらもバージョンは0.3.0(2026年7月17日公開)で、documentdb.ioは「The operator is still in preview」と明示しています。クロスクラスタレプリケーション・HA・バックアップ・TLSは文書化済みですが、プレビュー表記が外れるまでは障害時の復旧手順を自前で検証しきる前提が要ります。
見送るべきケースと、いま試す価値があるケース
次のいずれかに当てはまるなら、OSS版の自己運用は見送ってマネージドサービスを選ぶべきです。SLAを契約上必要とする業務系(OSS版にSLAはありません)、採用構成で更新時の停止時間や復旧手順を検証できない運用、Kubernetes構成を選びながら運用要員を確保できないチーム。
逆に価値があるのは、SSPLとベンダーロックインの回避が要件として先にあるケースです。MITライセンスのエンジンをローカル・オンプレミス・任意のクラウドに配置できる点は、実行環境を選びたい場合の採用理由になります。開発環境をDockerのローカルイメージで揃え、本番はAzure DocumentDBに置く組み合わせなら、いまの成熟度でも現実的です。
よくある質問
DocumentDBとは何ですか?
PostgreSQLの拡張として実装された、MongoDB互換のオープンソースのドキュメント指向データベースです。Microsoftが2025年に公開し、2025年8月25日にLinux FoundationへMITライセンスで移管されました。BSON型をPostgreSQLに持ち込み、MongoDBのドライバとツールからそのまま操作できます。
MongoDBとDocumentDBの違いは何ですか?
ライセンスと実装基盤が違います。MongoDB本体のサーバーはSSPLバージョン1で配布されるのに対し、DocumentDBはMITライセンスで、PostgreSQLの上に構築されています。DocumentDBはMongoDBのオープンソースドライバやツールとの互換性を目指していますが、MongoDB Atlas固有の機能は対象外です。
Azure DocumentDBとAmazon DocumentDBは同じものですか?
別物です。Azure DocumentDBはOSSのDocumentDBをエンジンに採用したMicrosoftのマネージドサービスで、旧称は「仮想コアベースのAzure Cosmos DB for MongoDB」、2025年11月18日にGAとなりました。Amazon DocumentDBはAWSのMongoDB互換マネージドデータベースで、AWSはこれがOSSのDocumentDBを基盤にしているとは説明していません。
DocumentDBの料金はいくらですか?
OSS版は無料です。MITライセンスの条件を守れば、ローカル・オンプレミス・任意のクラウドで利用できます。自己運用でもサーバー・ストレージ・保守の費用は別途必要です。マネージドサービスのAzure DocumentDBはコンピューティングとストレージを独立に課金する仕組みを採り、最大35日間のバックアップは追加費用なし、32GBのストレージを含むFreeレベルも用意されています。
DocumentDBはPostgreSQLのどのバージョンで動きますか?
v0.117-0の時点で、documentdbメタパッケージはPostgreSQL 18を選択します。PostgreSQL 17で動かす場合はdocumentdb-17を指定してメタパッケージを外します。MongoDBドライバから接続するためのネイティブなゲートウェイ構成にはPostgreSQL 16以降が必要で、PostgreSQL 15向けは拡張のみの提供です。