Skip to content
LayerbaseLayerbase

7 reasons to choose FerretDB over MongoDB

5 min readMongoDBFerretDBDatabases

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

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:

typescript
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.

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.

Try It Locally First

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

bash
npm i -g spindb    # npm
pnpm add -g spindb # pnpm

spindb create ferret-trial -e ferretdb --start
spindb url ferret-trial
text
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 SpinDB:

bash
spindb stop ferret-trial    # Stop the server
spindb start ferret-trial   # Start it again
spindb url ferret-trial     # Print the connection URL
spindb 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.

Something not working?