7 reasons to choose FerretDB over MongoDB

Short version: FerretDB gives you the MongoDB wire protocol on top of PostgreSQL under an Apache 2.0 license, so the driver, the connection string, and ordinary queries stay the same while the SSPL obligations go away. You operate Postgres instead of a second database, you get the Postgres toolbox (pgvector, PostGIS, pg_cron, plain SQL) against the same data, and you get per-pull-request branching MongoDB never offered. The reasons not to are real too: $lookup, change streams, $text indexes, $graphLookup, capped collections, and $merge/$out are not implemented, and the Atlas ecosystem is Atlas-only.

FerretDB is a document database that speaks the MongoDB wire protocol but stores your data in PostgreSQL. Same mongodb:// connection string, same MongoClient driver, same query syntax, under an Apache 2.0 license. We have a hands-on MongoDB vs FerretDB comparison that runs identical code against both; this post is the shorter version of the question people actually ask first: why would I choose it over MongoDB at all?

Here are seven reasons, and then an honest section on when you should not.

Contents

• 1. The license is the headline
• 2. One fewer database to operate
• 3. Your application code barely changes
• 4. The PostgreSQL ecosystem comes with it
• 5. Neon-style branching MongoDB never had
• 6. No Atlas lock-in
• 7. A low-risk way to find out
• When to Stay on MongoDB
• Try It Locally First

1. The license is the headline

MongoDB relicensed to the SSPL in 2018, and that one change is why FerretDB exists. The SSPL requires anyone who offers MongoDB as a service to release the source of their entire surrounding stack, which is why Debian and Fedora dropped MongoDB from their repositories and why managed-database vendors cannot freely build on it. If your legal team has ever flagged a dependency's license, the SSPL is the kind they flag.

FerretDB is Apache 2.0. You can self-host it, embed it in a product you sell, build an internal database platform on it, modify it, and redistribute it, with none of the SSPL obligations. For a lot of teams that single fact is the whole decision.

2. One fewer database to operate

Running MongoDB means operating MongoDB: its own backup tools, its own monitoring, its own replication protocol, its own sharding coordinator. That is a separate operational surface your team has to learn and carry.

FerretDB stores its documents in PostgreSQL, so operating it means operating Postgres. If you already run Postgres anywhere in your stack (most teams do), your existing backups, point-in-time recovery, monitoring, replication, and connection pooling already cover it. You add a document API without adding a second system to babysit.

3. Your application code barely changes

FerretDB implements the MongoDB wire protocol, so you keep the standard mongodb driver and the queries you already wrote:

import { MongoClient } from 'mongodb'

// Pointed at FerretDB instead of MongoDB. The code does not know the difference.
const client = new MongoClient(process.env.MONGODB_URI!)
const tasks = client.db('app').collection('tasks')

await tasks.insertOne({ title: 'Ship it', priority: 'high', tags: ['release'] })
const urgent = await tasks.find({ priority: 'high' }).sort({ createdAt: -1 }).toArray()

For standard CRUD, filtered queries, array matching, and core aggregation, the same code produces the same results on both engines. Our comparison post runs exactly this kind of code against MongoDB and FerretDB side by side to prove it.

4. The PostgreSQL ecosystem comes with it

Because your documents live in Postgres, you can reach for the rest of the Postgres toolbox in the same database: pgvector for embeddings and semantic search, PostGIS for geospatial queries, pg_cron for scheduled jobs, and plain SQL when you want to query your document data relationally. Document storage and relational data in one place, with one set of tools, instead of stitching a separate document database into your architecture.

5. Neon-style branching MongoDB never had

Branching your database the way you branch your code, an isolated copy per pull request that you delete on merge, became normal for Postgres developers. MongoDB never got it; Atlas snapshots restore into a whole new cluster, which is slow and expensive and nobody runs it per feature branch.

FerretDB on Layerbase Cloud branches straight from the dashboard in seconds, because the data is Postgres underneath. Point a preview environment at the branch, delete it when the PR merges. We wrote this up in full in Branching with MongoDB: the Neon workflow, on a Mongo-compatible database.

6. No Atlas lock-in

MongoDB's polished managed experience is Atlas, and the gravity is real: Atlas Search, Charts, and Realm only work inside that ecosystem, and your bill scales with it. FerretDB has no equivalent lock-in. It is open source you can run on any Postgres, anywhere, and a managed FerretDB on Layerbase Cloud is flat per-instance pricing on a database you can always take with you. Owning the thing is the point.

7. A low-risk way to find out

You do not have to commit to answer the question. FerretDB uses the same connection string and driver, so trying it is: stand one up, point your test suite at it, and see what passes. For an app built on common document operations, that is often the whole evaluation. When you are ready to move real data, Migrating from MongoDB to FerretDB walks through what carries over, what to check first, and how to do the copy. On Layerbase Cloud that copy is a form: paste your Atlas or self-hosted connection string on the MongoDB Atlas migration page and it moves the collections, documents, and indexes into a managed FerretDB database, verifies the document counts against your source, and tells you what it could not bring across. It reads the source once and never writes to it, so a trial run costs you nothing on the MongoDB side.

When to Stay on MongoDB

The honest part. FerretDB covers a large subset of the MongoDB API, not all of it, and there are real reasons to stay:

• You rely on features FerretDB does not implement yet. $lookup joins, change streams, built-in text-search indexes ($text), $graphLookup, capped collections, and $merge/$out are the common ones. Check the FerretDB compatibility reference against your codebase before deciding.
• You are committed to the Atlas ecosystem. If Atlas Search, Charts, or Realm are load-bearing in your product, those are MongoDB-only.
• Document write throughput is your bottleneck. MongoDB's WiredTiger engine is purpose-built for document workloads; for very write-heavy or large-document cases it may outperform a Postgres backend.
• SSPL is genuinely a non-issue for you. If you ship a product (not a database service) and your legal team is fine with the license, that reason simply does not apply to you, and that is fine.

FerretDB is a strong fit for the common case, not a universal drop-in. Pick based on what your app actually uses, which is exactly why reason 7 (just try it) is the one to start with.

FAQ

Is FerretDB compatible with the MongoDB driver?

Yes for the standard path. It implements the MongoDB wire protocol, so the mongodb driver, your mongodb:// connection string, CRUD, filtered queries, array matching, and core aggregation all behave the same. The gaps are specific rather than general, and they are listed in the FerretDB compatibility reference.

Why does FerretDB exist at all?

MongoDB relicensed to the SSPL in 2018. The SSPL requires anyone offering MongoDB as a service to release the source of their entire surrounding stack, which is why Debian and Fedora dropped it from their repositories and why managed vendors cannot build on it freely. FerretDB is Apache 2.0, so self-hosting, embedding it in a product you sell, or building a platform on it carries none of that.

Is FerretDB slower than MongoDB?

For very write-heavy or large-document workloads, MongoDB's WiredTiger engine is purpose-built for the shape and may win. That is one of the four honest reasons to stay on MongoDB rather than a hedge, and it is why the cheapest evaluation is to point your existing test suite at a FerretDB instance and see what happens.

Can I branch a FerretDB database?

Yes, and that is one of the reasons people move. The data is Postgres underneath, so a branch is the same instant copy-on-write fork Postgres developers already expect. MongoDB never got this: Atlas snapshots restore into a whole new cluster, which is too slow and too expensive to run per feature branch.

What do I do with my existing MongoDB data?

Paste your Atlas or self-hosted connection string on the MongoDB Atlas migration page. It copies collections, documents, and indexes into a managed FerretDB database, verifies document counts against your source, and reports what it could not bring across. The source is read once and never written to, so a trial run costs nothing on the MongoDB side.

When should I stay on MongoDB?

When your code leans on $lookup, change streams, $text search indexes, $graphLookup, capped collections, or $merge/$out. When Atlas Search, Charts, or Realm are load-bearing. When document write throughput is your actual bottleneck. Or when you ship a product rather than a database service and the SSPL was never a problem for you in the first place.

Try It Locally First

The cheapest way to test the claim is to run FerretDB on your machine. The Layerbase CLI (formerly SpinDB) does it with one CLI, no Docker, and provisions the Postgres backend for you. (What is the Layerbase CLI?)

npm i -g layerbase    # npm
pnpm add -g layerbase # pnpm

lbase create ferret-trial -e ferretdb --start
lbase url ferret-trial

mongodb://127.0.0.1:27017

Point your app's MONGODB_URI at that, run your suite, and see what passes. Manage the instance with the Layerbase CLI:

lbase stop ferret-trial    # Stop the server
lbase start ferret-trial   # Start it again
lbase url ferret-trial     # Print the connection URL
lbase list                 # See all your instances

When you want it managed, Layerbase Cloud provisions FerretDB with TLS, backups, branching, and flat pricing, on the same mongodb:// string your code already uses. Layerbase Desktop wraps SpinDB in a GUI on macOS. For the deeper dives, see MongoDB vs FerretDB and Migrating from MongoDB to FerretDB.