DocumentDB 1.2.0 Follows 1.0 With No 1.1; Local Image Needs a Password by Default, and an Issue Reports Some 1.0.0 Queries Slower Than MongoDB 9.0.4

Overview

DocumentDB, which InfoQ describes as an “open source, MIT-licensed document database built on PostgreSQL, with compatibility for the MongoDB wire protocol”, released version 1.2 on 2026-11-12, according to the project’s 1.2 release notes. The GitHub release page says 1.2 follows 1.0 and that “There was no 1.1 release; its changes are part of 1.2.”

InfoQ’s report that “DocumentDB 1.0 is the first generally available release” is dated 2026-11-14. The project’s 1.0 release notes date that release 2026-10-19, and InfoQ’s article does not mention 1.2. A separate GitHub issue, opened on 2026-10-20 and still open when the Herald checked on 2026-11-14, reports that DocumentDB 1.0.0 was slower than MongoDB 9.0.4 on several query types in the reporter’s own test. The Herald ran no performance measurements; every performance figure below is a source’s.

What 1.2.0 changes

The items below are the Herald’s selection from a longer list in the GitHub release.

Local container image. The GitHub release lists a change to refuse to start the documentdb-local image “without a password, also on an existing data volume.” The docs release notes say DOCUMENTDB_ALLOW_DEFAULT_PASSWORD=true restores the public default password “for short-lived local evaluation”, and that an empty TLS_MODE, or a list such as allowTLS,requireTLS, is rejected. They say these two changes can stop an existing docker run command or Compose file from starting. The GitHub release tags the TLS_MODE change as Breaking/Security and says TLS_MODE=allowTLS,requireTLS “used to start without enforcing TLS”.

The docs notes also say --password no longer stays in the container’s process list, and add: “Both —password and PASSWORD are still visible to docker inspect.” The 1.0 release notes, as of their 2026-10-19 version, listed among their known issues #685, “a —password argument is readable in the container’s process list; pass -e PASSWORD instead”, #758, “container settings that aren’t secure by default”, and #773, “A newer container image doesn’t upgrade an existing volume”. The 1.2 docs notes say “A newer image updates the extensions on an existing data volume at start.” They cite none of those three issue numbers, so the cited sources do not say whether the changes respond to them.

Metrics rename. The docs notes say the gateway’s db.client.* metric names are now docdb.gateway.* and tell users to update dashboards and alerts. The GitHub release’s change list, as of 2026-11-14, does not mention the rename. A docs commit timestamped 2026-11-12 19:47:57 UTC, titled “Add the release date and the metrics rename to the 1.2 notes (#99)”, explains the gap: “The gateway renamed its metrics in 1.2 and the changelog does not say so.” The GitHub release page shows 19:05:58 UTC the same day, so the docs commit came about 42 minutes later (the Herald’s own subtraction).

Other items, among others. The GitHub release lists estimating the inner side of a $lookup join “from collected statistics instead of a fixed fallback selectivity”. It says the install script’s stable channel “can stay on the previous release for a while (1.0.0 for now)”, and warns that “Going back to 1.0 on updated data is not supported: 1.0 starts, then fails on some queries.” The docs notes say collation is still off by default.

What InfoQ reports

InfoQ’s article, bylined Renato Losio, says 1.0 supports PostgreSQL 15 to 18 through container images, with Linux packages for PostgreSQL 17 and 18, and includes a Kubernetes operator. It says practitioners in a Reddit thread “raise concerns about current MongoDB compatibility and confusion with similarly named products”, and that “The project plans separate long-term support and development tracks, with its versioning policy still under discussion.”

On performance, InfoQ says Layerbase compared FerretDB and DocumentDB with YCSB, “finding that DocumentDB delivered 20–33% higher read throughput, while FerretDB had lower tail latency for updates in mixed workloads, but noting the results are not conclusive”. InfoQ adds: “An open GitHub issue reports higher query latency in DocumentDB 1.0 than MongoDB 9.0.4 across several workloads, but the results have not been independently verified.”

The latency issue

Issue #806 was opened on 2026-10-20 by GitHub user KieranP (GitHub dates and times in this article are UTC). The reporter writes that DocumentDB 1.0.0 “is close to MongoDB 9.0.4 on single-document and simple indexed reads (within 1.1x to 1.2x)” and “1.5x to 6x slower on paginated $facet, $skip-based deep pages, $lookup, $group and updateMany”, and a prefix regex anchored with \A “about 15x slower”.

In the issue, the reporter ran both servers in Docker containers limited to 4 CPUs and 4 GB on a macOS host, with PostgreSQL 17.11 at image defaults. The reporter’s table gives the median of three p50 latencies per server. Among its rows, MongoDB versus DocumentDB: find by _id, 0.56 ms versus 0.63 ms (1.12x); 50 rows plus $lookup, 1.25 ms versus 5.49 ms (4.39x); updateMany, 2.88 ms versus 13.07 ms (4.54x); $facet deep page, 2.83 ms versus 15.38 ms (5.43x); $group over the whole collection, 18.69 ms versus 115.39 ms (6.17x); and the \A regex, 0.51 ms versus 7.94 ms (15.57x). The reporter lists as not tested “larger datasets, concurrent clients, TLS, and a tuned PostgreSQL configuration”, and writes that “differences of 10 to 20% are within normal variation between MongoDB versions”.

On 2026-11-03 a GitHub account on the issue marked as a contributor replied “we are looking at all the scenarios pasted here” and said the Ruby anchored-regex item “is fixed on this commit”, linking a commit dated 2026-10-24. The commit message says it addresses the regex-prefix report in #806, and the changelog line it adds sits under the heading “documentdb v1.3-0 (Unreleased)”. Neither the GitHub release notes nor the docs notes for 1.2 mention #806 or that anchored-regex change. The issue’s other comment is from an automated triage tool, and the issue was open with those two comments on 2026-11-14.

What the sources do not say

None of the cited sources reports a rerun of the issue’s queries on 1.2.0. The 1.2 notes list planner changes, including the $lookup estimate above, but do not say whether they affect the reporter’s figures. The cited sources do not say why 1.1 was skipped. InfoQ describes the issue’s results as not independently verified, and the Herald has not verified them either.