FerretDB

What is FerretDB?

FerretDB accepts MongoDB commands and translates them onto PostgreSQL storage, letting applications that speak MongoDB run on a relational database you already know how to back up and operate.

Best for

MongoDB-era applications that should not carry a second database

Why choose FerretDB

FerretDB is a translation layer: it accepts MongoDB wire protocol commands and stores the data in PostgreSQL. For anyone who has inherited an application that speaks MongoDB but does not want to run and secure a second database engine, that is a genuinely useful trade. You get the operational maturity of PostgreSQL — the backups you already test, the replication you already understand, the SQL access you already use for reporting — while the application stays unaware. Because the underlying storage is relational, you can query the same data with SQL for analytics, which is awkward to do against a real MongoDB deployment. It is also a route for migrating off MongoDB incrementally rather than as a single risky cutover.

Replaces

• MongoDB
• Amazon DocumentDB
• Firebase Firestore

Key features

• MongoDB wire protocol compatibility
• PostgreSQL as the storage engine
• Reuses existing Postgres backup and monitoring
• Apache licensed throughout

What to watch out for

It is a compatibility layer, so the compatible surface is a subset of MongoDB's. Features that depend on MongoDB internals — certain aggregation stages, change streams, specific index types — may be absent or implemented differently, and the supported feature list changes between releases, so verify against your application's actual queries rather than assuming. Performance characteristics differ from native MongoDB because the query planner is PostgreSQL's. Documentation and community answers are far thinner, so an unusual failure is yours to diagnose. Running it in front of an application that assumes full MongoDB behavior can produce failures that look like application bugs.

How to deploy

• Docker Compose with a Postgres instance
• Point the app's Mongo connection string at FerretDB
• Verify the specific commands your app uses

Getting started

Read the current compatibility matrix and confirm every operation your application relies on is supported before deploying anything. Put it in front of a PostgreSQL you already back up, and give it a dedicated database rather than sharing one with other applications. Test the application's real query patterns against it in staging, not just a smoke test — aggregation pipelines are where gaps appear. Monitor the translation layer itself, because errors surface there rather than in either database. Keep a working export path back to native MongoDB in case a feature you need turns out to be unsupported.

Typical setup

It runs in front of a PostgreSQL instance that is already backed up, using a dedicated database rather than sharing one with other applications. The compatibility matrix is checked against the application's actual operations before deployment, and the real query patterns are exercised in staging rather than a smoke test. The translation layer is monitored in its own right, since failures surface there rather than in either database. A working export path back to native MongoDB is kept available in case an unsupported feature turns out to be required.

Who should look elsewhere

Do not use it if your application depends on advanced MongoDB features, because the gaps appear at exactly the worst time. Avoid it as a general-purpose replacement for a relational database too — if you are not serving a MongoDB-speaking application, the translation layer is pure overhead and plain PostgreSQL is the better answer. And if you are unwilling to test the full query surface before migrating, this is not a component to introduce casually.

Project health

• GitHub stars: 11,089
• Last code push: 2026-06-05
• Open issues: 449
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.