FerretDB
"A truly Open Source MongoDB alternative." Go, Apache 2.0, 11,045★ / 486 forks, created 2021-10-30, last pushed 2026-06-05 — two and a half months before this ingest, the only page in this batch whose upstream is not being touched weekly. Read from the repository (T1), pulled from awesome-postgres' five-entry Server section.
It is a proxy that translates a wire protocol: it "converts MongoDB 5.0+ wire protocol queries to SQL" and "uses PostgreSQL with DocumentDB extension as a database engine." An application speaking MongoDB's protocol connects to FerretDB, and Postgres stores the documents.
Why it exists is a licensing argument, not a technical one
The README says so directly. MongoDB "abandoned its open-source roots; changing the license to SSPL — making it unusable for many open-source and early-stage commercial projects." FerretDB is aimed at users who "do not require any advanced features offered by MongoDB" but need something they are allowed to ship.
That makes it the corpus's first instance of a pattern worth naming: a database built to reproduce an interface whose licence changed. The engineering is downstream of the licence. It also means the compatibility claim is deliberately bounded — a "drop-in replacement for MongoDB 5.0+ in many cases", with a maintained list of "known differences and supported commands" rather than a parity claim. The README's own framing, that "features are constantly being added," is a statement that gaps exist and are not enumerated on this page.
What it does to two of this spoke's arguments
Growth edge 8 wanted the document and key-value neighbours — MongoDB and Redis, absent from the corpus. This does not close it, and the distinction matters: FerretDB is a source about reproducing MongoDB's interface, not a source about MongoDB's design. What a document store's storage engine, indexing and consistency model actually are remains unpaged. The edge narrows to that.
And it complicates postgresql-extensions usefully. FerretDB sits in the catalog's Server
section — nominally one of the five alternatives to running Postgres — while in fact being Postgres,
plus the DocumentDB extension, plus a protocol translator. It is not a fork at all, unlike
yugabytedb in the same section. So the catalog's own sectioning overstates the fork count: of the
five entries, one (FerretDB) is an extension-plus-proxy, one (YugabyteDB) forks the storage layer
while keeping the Postgres query layer, and the extension thesis survives the section that was
supposed to be its counterexample.
The architectural position is also familiar. FerretDB is a proxy speaking somebody else's wire protocol, which is exactly what vitess' VTGate is for MySQL and what pgbouncer is for Postgres. Three proxies in this spoke now, doing three unrelated jobs: shard routing, connection multiplexing, and protocol translation. The wire protocol being a stable public interface is what makes all three possible.
Not covered here
The DocumentDB extension itself — whose design decides whether the document model is stored well or merely stored — is named and unread. No benchmark, no account of which MongoDB commands are missing, and no source on how the aggregation pipeline maps to SQL, which is where a translation layer of this kind is usually thinnest.
Related
postgresql · postgresql-extensions · yugabytedb · pgbouncer · vitess · logical-replication · awesome-postgres · operational-databases · analytical-databases