MongoDB alternatives in 2026: revisit Percona Server for MongoDB, FerretDB and DocumentDB before you migrate another collection

Manoj Shukla
October 18, 2026

Picture a diagnostic lab chain headquartered in Guwahati, with collection centres in Shillong, Jorhat, Silchar, Dibrugarh and Tezpur (an invented example, not a real client). Its lab information system runs on a three-member MongoDB Community replica set. Sample tracking, billing and report status live in one database. A payment and a sample status change are written in one multi-document transaction. A change stream triggers the “report ready” SMS. The front desk searches patient names case-insensitively with a collation, and a $jsonSchema validator stops negative amounts reaching the payments collection.

Then the plan changes: host the same system for smaller partner labs across the Northeast, and give each partner direct database access for its reporting tools. Someone says “MongoDB is SSPL, we cannot do that”, and three proposals arrive. The DBA wants Percona Server for MongoDB, the same engine with more security features. A PostgreSQL fan wants FerretDB. The platform engineer wants DocumentDB, now a Linux Foundation project, on the PostgreSQL cluster they already run for billing.

This post compares those three as they stand on 18 October 2026, with MongoDB Community Edition under the SSPL as the baseline: licence history, governance, architecture, documented compatibility, operations, security and maintainer health. Managed services (Atlas, Amazon DocumentDB, FerretDB Cloud, Azure) are out of scope, and so is MongoDB performance tuning, covered in earlier posts. The question here is whether an application keeps behaving the same when you change what is behind the connection string.

Facts come from GitHub releases, LICENSE files, official docs and release notes, MongoDB’s licensing pages and FAQ, the OSI statement, CVE records, and a drill that ran one pymongo script against PSMDB 8.0.32-14, FerretDB v2.7.0 and the DocumentDB 0.117 gateway. It is not a speed benchmark, and it is not legal advice.

The short version

Wire-protocol compatibility is not behaviour compatibility. In the drill, all three gave identical results for the same inserts and aggregation pipelines, then differed on collation, schema validation, transactions, change streams and explain output. Some differences were silent.
MongoDB Community Server has been under the SSPL v1 since 16 October 2018 (AGPL v3 before that). MongoDB’s FAQ says section 13 applies when you offer MongoDB itself as a service to third parties, not to internal use or to ordinary SaaS applications that use MongoDB as their database. The OSI says the SSPL is not an open source licence.
Percona Server for MongoDB (PSMDB) is at 8.0.32-14 (23 September 2026), built on MongoDB 8.0.32, under the same SSPL text. It adds LDAP, Kerberos, audit logging, hot backup and encryption at rest with Vault or KMIP. It changes the features, not the licence.
FerretDB is at v2.7.0 (10 November 2025), Apache 2.0, a Go proxy in front of PostgreSQL with FerretDB’s own DocumentDB fork 0.107.0. Its docs list commitTransaction and abortTransaction as not implemented. There has been no release for eleven months and no commit on main since 7 February 2026.
DocumentDB is at v0.117-0 (10 September 2026), MIT, a pair of PostgreSQL extensions plus a gateway, now a Linux Foundation project with AWS on its technical steering committee. 1.0 is at release candidate 2, for testing only, with no upgrade path between pre-GA versions.
Security: the CVE records published on 13 October 2026 list MongoDB 8.0 builds before 8.0.34 as affected by three new issues, and PSMDB’s newest 8.0 build is based on 8.0.32. No GitHub security advisories exist for FerretDB or DocumentDB; their release notes still list crash fixes.

Where things stand on 18 October 2026

Dates are GitHub release published_at converted from UTC to IST (UTC+5:30), except MongoDB and Percona Server for MongoDB, which publish dates only (taken from their release notes). Licences are from the LICENSE files and licensing pages.

Project

Release

Date (IST)

Notes

Licence

MongoDB Community Server

9.0.4

13 October 2026

Current major; 9.0.0 released 28 September 2026

SSPL v1

MongoDB Community Server

8.0.34

13 October 2026

Fixes CVE-2026-96297, CVE-2026-103965, CVE-2026-104004

SSPL v1

Percona Server for MongoDB (percona/percona-server-mongodb)

8.0.32-14

23 September 2026

Includes MongoDB 8.0.32 and 8.0.30 fixes; newest PSMDB 8.0 tag

SSPL v1 (“source-available”)

Percona Backup for MongoDB

v2.17.0

15 October 2026, 1:39 PM

Physical PITR now replays index changes

Apache 2.0

Percona Operator for MongoDB

v1.23.1

6 October 2026, 12:56 AM

Persistent logging for mongos

Not documented

FerretDB (FerretDB/FerretDB)

v2.7.0

10 November 2025, 11:17 PM

Latest release; “works best with” fork 0.107.0-ferretdb-2.7.0

Apache 2.0

FerretDB DocumentDB fork (FerretDB/documentdb)

v0.107.0-ferretdb-2.7.0

10 November 2025, 10:54 AM

Builds for Debian 11 and 12, Ubuntu 22.04 and 24.04, RHEL 8 and 9; PostgreSQL 15 to 17

MIT

DocumentDB (documentdb/documentdb)

v0.117-0

10 September 2026, 7:41 AM

Current stable; what the package repository installs

MIT

DocumentDB

v1.0-RC2

10 October 2026, 5:03 AM

Testing only; no fixes, no upgrade path

MIT

DocumentDB Kubernetes Operator

1.0-rc1

16 October 2026, 2:08 AM

Preview; default DocumentDB 0.117.0

Not documented

GitHub stars on 18 October 2026: mongodb/mongo about 28,651, FerretDB about 11,101, DocumentDB about 3,462, PSMDB about 251. Stars measure attention, not fitness for your workload.

Timeline

Date (IST)

Event

16 October 2018

MongoDB issues the SSPL; all Community Server versions released after that day, including patches for older series, use it

February 2019

Fedora’s change page for Fedora 30: SSPL is not a free software licence, so MongoDB packages are dropped

19 January 2021

OSI board statement “The SSPL is Not an Open Source License”; the licence was submitted and later withdrawn

1 December 2021

MangoDB, announced a month earlier, renamed FerretDB after MongoDB, Inc. objected to the name

11 April 2023

FerretDB 1.0 GA under Apache 2.0, on PostgreSQL

23 January 2025

Microsoft open-sources DocumentDB under MIT; first release v0.100-0 the same evening

5 March 2025

FerretDB 2.0 GA, rebuilt on the DocumentDB extension

24 August 2025

AWS joins the DocumentDB project and its technical steering committee

25 August 2025

DocumentDB joins the Linux Foundation; FerretDB announces FerretDB Cloud

10 November 2025

FerretDB v2.7.0, its latest release

17 July 2026

DocumentDB v0.114-0, with a warning not to upgrade because active connections were closed after two hours

10 September 2026

DocumentDB v0.117-0

22 to 28 September 2026

PSMDB 7.0.43-23, 8.0.32-14 and 8.3.11-3

28 September 2026

MongoDB 9.0.0

10 October 2026

DocumentDB v1.0-RC2

13 October 2026

MongoDB 8.0.34 and 9.0.4; three new CVE records published

First question: what exactly is the licence problem?

“MongoDB is SSPL” is a fact, not a problem statement. Before comparing engines, write the problem in one sentence, and get a lawyer to read it with you:

We want to leave (or adopt) [product] because [specific clause or business risk]. Our application depends on [transactions, change streams, collation, validators, text search, roles, TTL]. A candidate is acceptable only if [our integration tests] give the same results and the same errors against it, and we can run its HA, backups and upgrades with [the team we have].

The MongoDB FAQ is specific. Section 13 is the only substantive change from GPL v3: if you make the program’s functionality available to third parties as a service, you must release the source of the whole service stack under the SSPL. Internal use, including for subsidiaries, is not making it available to a third party, and SaaS applications that merely use MongoDB as their database carry no copyleft condition. For the Guwahati chain (invented), the core system is a SaaS application, but raw database access for partner labs is much closer to section 13. That part needs legal reading; the rest may not.

Once the licence question is clear, compatibility has three layers:

Wire protocol. The driver connects, authenticates and sends OP_MSG. Every option here passes this.
Command surface. Which commands, aggregation stages and index types exist. The docs of each project tell you this, more or less.
Behaviour. Same results, same errors, same guarantees for the same request. Only your own tests tell you this.

What each option actually is

MongoDB Community Edition, the baseline

MongoDB’s licensing page is short: SSPL for all versions released after 16 October 2018, including patch fixes for prior versions, and GNU AGPL v3 before that. Drivers are Apache 2.0; commercial licences come with Enterprise Advanced. The 2018 press release gave the reason: cloud vendors offering MongoDB as a service without contributing back. MongoDB submitted the SSPL to the OSI and later withdrew it; the OSI’s 2021 statement says software under it should not be called open source. Fedora dropped MongoDB for the same reason.

Since 8.2, MongoDB ships major releases every two years with a five-year lifecycle (8.0, 9.0) and minor releases in between (8.2, 8.3) that must be upgraded through in sequence. Treat the licence history as context, not a verdict: many organisations run Community Edition under the SSPL with no issue at all.

Percona Server for MongoDB 8.0.32-14

Percona describes PSMDB 8.0 as an enhanced, fully compatible, source-available drop-in replacement for MongoDB 8.0 Community Edition, needing no application changes. The 8.0.32-14 release notes say it includes the improvements and fixes of MongoDB 8.0.32 and 8.0.30 Community and supports the protocols and drivers of 8.0.32. You can confirm what you are running: buildInfo returns a psmdbVersion key only on PSMDB.

The licence does not change. The LICENSE-Community.txt on the v8.0 branch is byte-for-byte the SSPL text in mongodb/mongo, and Percona’s copyright page calls PSMDB source-available software. What changes is the feature set. Percona’s own comparison lists, for PSMDB versus MongoDB Community: encryption at rest with HashiCorp Vault or KMIP (Enterprise only upstream), hot backup on replica sets, LDAP authentication and authorisation, Kerberos, AWS IAM authentication, audit logging and log redaction. The docs also cover OIDC, OpenBao as a key store and an ngram text search option.

Around it sit Percona Backup for MongoDB (Apache 2.0, v2.17.0, with logical, physical and incremental backups and PITR) and the Percona Operator for MongoDB (v1.23.1), which since 1.23.0 can run Percona ClusterSync for MongoDB to clone and follow a source cluster during a migration.

Two things to know. PSMDB follows upstream with a lag: nine 8.0 builds in 2026, the latest on 23 September, while upstream 8.0.34 came on 13 October. And its telemetry subsystem is on by default; set perconaTelemetry=false if your policy needs it.

FerretDB v2.7.0

FerretDB started in 2021 as MangoDB and reached 1.0 GA in April 2023 under Apache 2.0. The README calls it a proxy that converts MongoDB 5.0+ wire protocol queries to SQL, with PostgreSQL and the DocumentDB extension as the engine. Version 2.0 (March 2025), built with Microsoft, replaced its own storage layer with that extension. FerretDB ships its own DocumentDB fork, and each release names the fork version it “works best with”: v2.7.0 pairs with 0.107.0-ferretdb-2.7.0.

The compatibility page is honest: error codes match MongoDB but messages may differ, and commitTransaction, abortTransaction, role management, bulkWrite, setParameter and killOp are not implemented. Users are PostgreSQL roles, only SCRAM-SHA-256 is supported, and authorisation is not yet supported, so roles must be empty. High availability is PostgreSQL streaming replication; logical replication may not work. A useful diff-normal mode proxies to a real MongoDB and logs the differences between responses.

Maintenance deserves its own paragraph. The latest release, v2.7.0, came on 10 November 2025; the last commit on main is a dependency bump on 7 February 2026. The repository is not archived and has 449 open issues. The fork is ten minor versions behind upstream DocumentDB, with no Debian 13 or PostgreSQL 18 packages. On 18 October 2026, www.ferretdb.com returned HTTP 404 with a hosting provider’s “Website Expired” page, while the docs and blog still loaded. None of this proves the project has stopped, but ask the company about support and roadmap before you move a production collection onto it.

DocumentDB v0.117-0 (and the 1.0 release candidates)

Microsoft open-sourced DocumentDB on 23 January 2025 under MIT, as the engine behind vCore-based Azure Cosmos DB for MongoDB. It has three parts: pg_documentdb_core adds a BSON data type and operators to PostgreSQL, pg_documentdb is the API surface for CRUD, queries and indexes, and pg_documentdb_gw is the gateway that turns MongoDB protocol requests into PostgreSQL queries. Indexes include single-field, multikey, compound, text and geospatial (through PostGIS), and vector search through pgvector. It loads pg_cron as well, and background jobs such as index builds and TTL run through it.

On 25 August 2025 the project joined the Linux Foundation, a day after AWS announced it was joining the technical steering committee with a stated goal of 100 percent MongoDB API compatibility. The site lists 11 TSC members from Microsoft, Amazon, AB InBev, Rippling and YugabyteDB. Releases have been regular: 0.114 in July 2026, 0.116 in August, 0.117 in September.

Read the release notes, because several features are behind flags. Schema validation is on by default since 0.114. Collation is behind documentdb_core.enableCollation, off by default, so collation requests fail with “not supported”. Custom roles are behind documentdb.enableRoleCrud, also off. This pre-GA line supports fresh installation only, not in-place upgrades, and official packages cover Ubuntu 24.04 and EL9 on PostgreSQL 17 or 18; PGDG carries Debian packages. The Kubernetes operator is in preview and needs Kubernetes 1.35+, cert-manager and CloudNativePG.

A note on names

Amazon DocumentDB is AWS’s managed service (2019); its FAQ says it uses no SSPL code. Azure has its own DocumentDB-branded services, and the project blog has a post on the naming. Here, DocumentDB means the open-source Linux Foundation project you install yourself.

Comparison tables

MongoDB Community cells in the security table come from Percona’s own comparison page. Cells without a primary source say “Not documented”.

Licence, governance and maintainer health

MongoDB CE

PSMDB

FerretDB

DocumentDB

Licence

SSPL v1 (AGPL v3 before 16 October 2018)

SSPL v1, same text

Apache 2.0

MIT

OSI view

Not open source (OSI statement)

Same licence

Permissive licence

Steward

MongoDB, Inc.

Percona

FerretDB Inc.

LF Projects; TSC of 11 from 5 organisations

Paid support

Enterprise Advanced

Percona

Enterprise subscriptions (2.0 GA post)

Not documented for the open-source project

Releases in 2026

Frequent patches on 7.0, 8.0, 8.3, 9.0

Nine 8.0 builds

None (last 10 November 2025)

0.114, 0.116, 0.117, two 1.0 RCs

Architecture

MongoDB CE

PSMDB

FerretDB

DocumentDB

Storage

WiredTiger

WiredTiger, or Percona Memory Engine

PostgreSQL tables via the FerretDB DocumentDB fork

PostgreSQL tables via pg_documentdb_core and pg_documentdb

Front end

mongod

FerretDB proxy (Go)

pg_documentdb_gw gateway

PostgreSQL versions

Not applicable

15 to 17 (fork packages)

17 and 18 (official packages); Debian packages from PGDG

Extra moving parts

None

PostgreSQL, pg_cron, the fork

PostgreSQL, pg_cron, PostGIS, pgvector, RUM

Compatibility surface

MongoDB CE

PSMDB

FerretDB 2.7.0

DocumentDB 0.117

Multi-document transactions

Yes

commitTransaction and abortTransaction not implemented (docs)

Not documented; worked in the drill

Change streams

Yes

Not documented; failed in the drill

Collation

Yes

Not documented; silently returned 0 in the drill

Behind documentdb_core.enableCollation, off by default

$jsonSchema validators

Yes

Needs documentdb.enableSchemaValidation; invalid document accepted in the drill even with it on

On by default since 0.114

Role management

Yes

Yes, plus LDAP authorisation

Not implemented; authorisation not yet supported

Behind documentdb.enableRoleCrud, off by default

Error messages

Reference

Same as upstream

Same codes, messages may differ (docs)

Same codes in the drill, different messages

Operations

MongoDB CE

PSMDB

FerretDB

DocumentDB

High availability

Replica sets

PostgreSQL streaming replication

Operator failover through CloudNativePG (preview); otherwise Not documented

Backup

mongodump; Ops Manager or Atlas

PBM: logical, physical, incremental, PITR; hot backup

PostgreSQL backups of the underlying cluster (not tested here)

Operator Backup and ScheduledBackup; PostgreSQL backups (not tested here)

Kubernetes

MongoDB Controllers for Kubernetes (1.13.0)

Percona Operator (1.23.1)

Plain Deployment plus a PostgreSQL with the fork

DocumentDB Operator (preview, 1.0-rc1)

Upgrades

Documented major and minor paths

Minor upgrade and upgrade-from-Community guides

Install the matching DocumentDB package first, then ALTER EXTENSION documentdb UPDATE

Pre-GA: fresh installation only

Telemetry default

Not documented

On; perconaTelemetry=false

“Undecided”, which acts as enabled

documentdb-local image on since RC2; native packages unaffected

Security features

MongoDB CE

PSMDB

FerretDB

DocumentDB

Authentication

SCRAM

SCRAM, LDAP, Kerberos, AWS IAM, OIDC, x.509

SCRAM-SHA-256 through PostgreSQL

SCRAM

Encryption at rest

Enterprise only

Vault, KMIP, OpenBao, local keyfile

Not documented

Audit log

Enterprise only

Yes

Not documented

Log redaction

Enterprise only

Yes

Not documented

TLS

Yes

Yes (TLS docs page)

Gateway TLS; four TLS modes in the operator

Worked example for the Guwahati scenario

The Guwahati team (invented) started with the sentence from the first question. Their lawyer’s reading split the work: the core lab system is a SaaS application, outside section 13 per the FAQ; raw database access for partners is the risky part.

Step 1. Inventory what the application really uses. Search the code for with_transaction, watch(, collation=, $jsonSchema, $text, TTL and partial indexes, and list validators and index options from the live database. Theirs matched the drill almost line for line.

Step 2. Run the integration tests against every candidate, not a demo app. For FerretDB, also run diff-normal mode against staging and read the diff log.

Step 3. Migrate a copy and compare. Data first, indexes separately, then counts and a checksum of one known aggregation:

# dump from the MongoDB or PSMDB source (read-only user)
mongodump --uri="$SRC_URI" --db=ghy_lab --out=/backup/ghy-dump

# restore data without indexes; PostgreSQL-based targets rejected textIndexVersion 3
mongorestore --uri="$DST_URI" --nsInclude='ghy_lab.*' --noIndexRestore /backup/ghy-dump

# recreate indexes by hand, then compare counts with the source
mongosh "$DST_URI" --quiet --eval '
  const d = db.getSiblingDB("ghy_lab");
  d.samples.createIndex({lab: 1, status: 1, collected_at: -1}, {name: "lab_status_time"});
  d.samples.createIndex({sample_id: 1}, {unique: true, name: "sample_id_u"});
  d.samples.createIndex({notes: "text"}, {name: "notes_text"});
  d.samples.createIndex({amount_rs: 1}, {name: "amount_reported", partialFilterExpression: {status: "reported"}});
  d.samples.createIndex({expire_at: 1}, {name: "ttl_expire", expireAfterSeconds: 3600});
  d.getCollectionNames().sort().forEach(c => print(c, d[c].countDocuments({})));'

Indexes deserve the same care you would give them on MongoDB; the indexing strategies post applies here, because a restore that silently skips a unique or TTL index changes behaviour, not just speed.

Step 4. Decide per workload. The core system needs transactions, a change stream and collation, so it stays on a MongoDB engine. Partner reporting needs reads, aggregations and text search only; that smaller workload is the one worth trying on a permissive-licence engine.

Step 5. Plan day two. On FerretDB or DocumentDB, failover is a PostgreSQL problem (see the PostgreSQL high availability post) and so are backups (see the PostgreSQL backups post). MongoDB runbooks do not carry over as they are.

Security and hygiene

On 18 October 2026 the GitHub repository security advisories API returned no published advisories for FerretDB/FerretDB, FerretDB/documentdb, documentdb/documentdb or percona/percona-server-mongodb, and OSV had no FerretDB entries. Upstream MongoDB CVEs are where the records are.

CVE-2026-82067 (published 8 September 2026, 9:42 PM IST, CVSS 4.0 score 9.2). Case-sensitivity handling in configuration validation could leave authorisation disabled at startup, so an unauthenticated network client could run administrative operations. Affected 8.0 before 8.0.30 (and 7.0, 8.3 lines); fixed in PSMDB 8.0.32-14.
CVE-2026-89099 (11 September 2026, 11:09 PM IST, CVSS 4.0 score 7.7). A race in the document value layer could corrupt memory. Fixed in 8.0.32 and PSMDB 8.0.32-14.
CVE-2026-96297, CVE-2026-103965 and CVE-2026-104004 (13 October 2026, 8:53 PM to 9:06 PM IST; CVSS 4.0 scores 6.0, 5.3 and 7.1): memory disclosure through an internal aggregation stage, $bucket constants misread as field references, and a crash on insert with collation-accepting validator expressions. The records list MongoDB 8.0 before 8.0.34 as affected. PSMDB 8.0.32-14 is based on 8.0.32, and no newer PSMDB 8.0 tag existed on 18 October; watch Percona’s release notes.
CVE-2026-6231 (MongoDB C driver bson_validate could skip validation). PSMDB 8.0.32-14 upgraded its bundled mongo-c-driver to 1.30.10 for it.
CVE-2026-44477 (CloudNativePG metrics exporter privilege escalation, CVSS 4.0 score 9.4). DocumentDB Kubernetes Operator 0.3.0 moved to CloudNativePG 1.29.1 for it; older operator installs pull a vulnerable CloudNativePG.
No advisory does not mean no bugs. The DocumentDB v1.0-RC1 notes list fixes since 0.117-0 for crashes in $getField, $setField, $firstN and $lastN, a dropIndexes deadlock and a gateway panic, all in testing-only release candidates.

Habits that matter more than CVE counts:

After every restart, check that authentication is really enforced: an unauthenticated listDatabases must fail. CVE-2026-82067 is a reminder that configuration and reality can differ.
On FerretDB and DocumentDB, the application user is a PostgreSQL role. Do not connect the application as a PostgreSQL superuser, and test what a low-privilege user can read.
Decide telemetry on purpose: PSMDB is on by default, FerretDB is “undecided” (acts as enabled), the DocumentDB local image is on since RC2.
Verify checksums, pin the proxy and extension versions together, and never expose any of these ports to the internet.

Decision guide

Situation

Lean towards

Why

Licence is fine for your use; you want LDAP, audit, encryption at rest without Enterprise

PSMDB

Same engine and behaviour; same SSPL

You use transactions, change streams and collation heavily

MongoDB CE or PSMDB

Both PostgreSQL-based options failed at least one of these in the drill

Legal says SSPL blocks your distribution or service model

DocumentDB (MIT), after your tests pass

Permissive licence, foundation governance, regular releases

Already strong on PostgreSQL; simple documents, aggregation, text search

DocumentDB 0.117 now, 1.0 when it ships

Runs as PostgreSQL extensions; backups and HA are PostgreSQL skills

Already on FerretDB 2.x

Plan a test against the upstream DocumentDB gateway

No FerretDB release since November 2025; fork behind upstream

Kubernetes in production today

PSMDB with the Percona Operator

The DocumentDB operator is still in preview

Guwahati (invented) pick. The core lab system moves from MongoDB Community 7.0 to PSMDB 8.0 for LDAP, audit logging and encryption at rest with Vault. Partner access becomes an API instead of raw database access, and a DocumentDB 0.117 pilot, run by the existing PostgreSQL team, serves the read-only partner reports. They re-test at DocumentDB 1.0.

Checklist

Write the licence problem in one sentence and get it read by a lawyer, with the MongoDB FAQ in hand.
Inventory transactions, change streams, collations, validators, text, TTL and partial indexes, and roles in your code and database.
Run your full integration suite against each candidate, asserting on errors as well as results, plus diff-normal mode or a shadow read path.
Restore a production copy, recreate indexes by hand where needed, and compare counts and checksums.
Check every feature flag on DocumentDB (enableCollation, enableRoleCrud, schema validation) and record its value.
Pin versions together: PSMDB 8.0.32-14 or later, FerretDB v2.7.0 with fork 0.107.0, DocumentDB 0.117-0 with gateway 0.117.0.
Plan HA and backups in the engine’s own terms: replica sets and PBM, or PostgreSQL replication and PostgreSQL backups.
Track upstream CVEs for 8.0.34 and Percona’s next 8.0 build.
Re-test at every upgrade, and at DocumentDB 1.0.

Common mistakes

Treating “connects with the MongoDB driver” as “compatible”.
Moving off MongoDB for licence reasons without reading section 13 and the FAQ on internal and SaaS use.
Moving to PSMDB to escape the SSPL. It carries the same licence.
Testing only CRUD and a demo aggregation, never transactions, change streams or collations.
Ignoring a silent difference: a query that returns zero rows with no error is worse than one that fails.
Trusting a validator without inserting an invalid document on purpose.
Letting mongorestore report success for data and missing that index creation failed.
Forgetting that pymongo does not raise errors from abortTransaction, so a failed abort looks like a success.
Upgrading a pre-GA DocumentDB in place, or running a release candidate in production.
Assuming backup and failover runbooks transfer when the storage engine becomes PostgreSQL.

A drill I ran on 18 October 2026

Shared Linux VM (Debian 13, 8 vCPU, 15 GiB RAM), no Docker or Kubernetes, port 8766 left alone. Final runs between about 6:55 PM and 7:05 PM IST. One box, one small synthetic dataset of invented lab samples, so timings show what each step involves, not which engine is faster.

Setup:

PSMDB 8.0.32-14 from Percona’s Debian 13 packages: single-node replica set rs0 with --auth, a keyFile, a 0.25 GB WiredTiger cache and telemetry off. The drill user had the root role.
FerretDB v2.7.0 release binary with FerretDB’s DocumentDB fork 0.107.0-ferretdb-2.7.0 (Debian 12 build) on PostgreSQL 17.11 from PGDG. The fork has no Debian 13 build, so I preloaded Debian 12’s libicu72. That workaround may itself affect behaviour, especially anything to do with collation.
Upstream DocumentDB 0.117-0 (PGDG Debian 13 package) plus documentdb-gateway 0.117.0 (the Ubuntu 24.04 package from GitHub) on a second PostgreSQL 17.11 cluster. The gateway reached PostgreSQL as the postgres superuser over a local Unix socket, a drill shortcut, not a production pattern.
Both PostgreSQL clusters used the postgresql.conf settings from FerretDB’s install guide, including documentdb.enableSchemaValidation = true and documentdb.enableLetAndCollationForQueryMatch = true. I left documentdb_core.enableCollation at its default. FerretDB and the gateway clients logged in as a non-superuser PostgreSQL role with documentdb_admin_role.
Client: pymongo 4.19.0 on Python 3.13.5. All downloads matched their published SHA-256 checksums.

The same script inserted 50,000 invented sample documents for six labs, built five indexes and ran 26 checks. These gave the same result on all three: duplicate key code 11000, find and count (2,157), a $match, $group, $sort pipeline with an identical result hash, $lookup, $facet, $bucket, $setWindowFields, $unionWith, $graphLookup, $out, $merge, $text (10,094 hits), $regex, update_many (1,320), arrayFilters, find_one_and_update, bulk_write and listIndexes.

These differed:

Check

PSMDB 8.0.32-14

FerretDB v2.7.0

DocumentDB gateway 0.117

Collation strength 2 (case-insensitive) count

8,365

0, no error

Error 115, “collation is not supported in the aggregate command yet”

$jsonSchema validator, invalid document

Rejected (121)

Accepted

Rejected (121)

Transaction commit

Committed

Error 59, no such command: 'commitTransaction'

Committed

Transaction abort

Insert rolled back (count 0)

Insert persisted (count 1)

Insert rolled back (count 0)

Change stream sees an insert

Yes

Error 115, $changeStream not supported

Explain output for the compound index

Names index, IXSCAN

Names index, PostgreSQL “Index Scan”, no IXSCAN

Names index, IXSCAN

Duplicate key message

E11000 duplicate key error

“Duplicate key violation on the…”

collStats storageSize / totalIndexSize

2,699,264 / 3,829,760 bytes

16,211,968 / 17,285,120 bytes

16,211,968 / 19,365,888 bytes

FerretDB’s own log shows both commitTransaction and abortTransaction returning CommandNotFound; the driver raises the first and swallows the second. The storage sizes are for repetitive synthetic data and each engine computes collStats its own way; measure your own collections before sizing disks.

Index builds showed the architecture. On PSMDB each createIndex took 138 to 328 ms; on the gateway about 1 to 2 seconds, because DocumentDB builds indexes through pg_cron jobs scheduled every 2 seconds. Single runs on a shared box.

Migration test. mongodump from PSMDB (52,016 documents in five collections) took 0.08 s. mongorestore into FerretDB and into the gateway restored every document, then failed on indexes with “Currently only textIndexVersion 2 is supported, not 3”, and still printed “52016 document(s) restored successfully”. With --noIndexRestore and three indexes recreated by hand, counts per collection, a $group hash, one document hash and the $text hit count matched the source on both targets. The partial and TTL indexes were not recreated in that run, which is exactly the kind of gap a real migration must close.

Setup lesson. On both PostgreSQL clusters, the first createIndex calls hung. The log said cron job 2 connection failed: pg_cron jobs connect to localhost by default, and my pg_hba required a password there. Setting cron.host afterwards did not change existing jobs. This fixed it:

-- in the postgres database of each DocumentDB cluster
SELECT jobid, schedule, command, nodename FROM cron.job;
UPDATE cron.job SET nodename = '/path/to/unix/socket/dir';

An early PSMDB run crashed when this box’s snapshot mechanism dropped a file into the data directory; moving it to /tmp fixed that. The environment, not PSMDB.

What the drill showed:

The happy path is genuinely compatible: inserts, indexes, most aggregation stages and updates matched exactly.
The edges are where applications break, and they are correctness features: transactions, validators, collation.
Silent differences are the dangerous ones. FerretDB returned zero rows for a collation query and accepted an invalid document without error.
The upstream DocumentDB gateway was closer to MongoDB than FerretDB 2.7.0 on this script: transactions and validation worked, collation failed loudly. The fork gap and the libicu workaround may explain part of that; I did not isolate it.
Read the whole mongorestore output; success lines can hide failed index builds.

What this box could not test: replication and failover, sharding, large data or concurrency, Kubernetes operators, authentication edge cases (LDAP, x.509, roles), backups and PITR, MongoDB Community Edition itself, DocumentDB 1.0 release candidates and PostgreSQL 18. All database processes were stopped by 7:05 PM IST. Scripts, logs and results are under drill46/.

Unlearn

Unlearn “MongoDB-compatible” as a yes or no property.
Unlearn that a licence change is a reason to migrate before you know which clause affects you.
Unlearn that a fork of the same engine changes the licence.
Unlearn trusting a successful exit code from a restore tool.
Unlearn GitHub stars as a signal of maintenance.

Re-learn

Re-learn SSPL section 13 and the FAQ on internal use and SaaS applications.
Re-learn the three layers: wire protocol, command surface, behaviour.
Re-learn your own application’s use of transactions, change streams, collation and validators.
Re-learn PostgreSQL operations if your documents will live in PostgreSQL.
Re-learn maintainer health: releases, commits, governance, even whether the vendor’s website still loads.

Closing

MongoDB-compatible databases in 2026 are less about the wire protocol and more about behaviour at the edges. MongoDB Community Edition remains the reference, and for many internal and SaaS uses the SSPL is not the problem it is made out to be. Percona Server for MongoDB 8.0.32-14 is the same engine with enterprise security features and the same licence; watch for its 8.0.34-based build. FerretDB v2.7.0 pioneered the idea under Apache 2.0, but has not released in eleven months, and in the drill it differed silently. DocumentDB 0.117 has the strongest governance story and behaved closest to MongoDB on the PostgreSQL side, but it is pre-1.0 with features behind flags. Learn the three layers. Unlearn “compatible” as a checkbox. Re-learn your own workload. Practise a migration on a copy, with invalid documents and aborted transactions in the test suite. Apply it before you migrate another collection.

Sources

MongoDB and the SSPL

Percona Server for MongoDB

FerretDB

DocumentDB

Security records

Drill tooling

pymongo 4.19.0 on PyPI

Internal

comments powered by Disqus

Releted Posts

Distributed SQL in 2026: revisit CockroachDB, YugabyteDB and TiDB before you shard or go multi-region

Manoj Shukla
October 12, 2026

Picture a mutual fund and stockbroking platform in Mumbai (an invented example, not a real client). Its order book and client ledger run on PostgreSQL 16 with Patroni across three VMs in one cloud region, and a rewards service runs on MySQL 8.

Manoj Shukla
October 11, 2026

Picture a lending company in Bengaluru (an invented example, not a real client). Its loan ledger runs on PostgreSQL 16 across three VMs, managed by Patroni with a three-node etcd cluster and HAProxy in front.

Manoj Shukla
October 15, 2026

Picture a platform team in Pune that runs a B2B lending stack for NBFCs across Maharashtra and Gujarat (an invented example, not a real client).