Skip to content
Get started

FerretDB (experimental)

Bring MongoDB. That is what production deploys run, and what we run.

If your estate is already Postgres, you can point the same connection string at FerretDB — a MongoDB-protocol server on top of Postgres. We have run the engine against FerretDB 2.7. It passed. That is the whole claim.

This is a verified experimental backend. We will take a report. We do not staff a second database support queue, we do not publish a compatibility matrix, and we do not promise every engine release is proven against FerretDB before it ships. The first customer who runs this in production is what turns experimental into a supported backend. Until then, treat a new engine version as unverified until you have run a real import against it.

Install FerretDB from their documentation. Then set the same variable you would set for MongoDB:

Terminal window
MONGO_CONNECTION_STRING=mongodb://user:password@ferretdb-host:27017/cap_import?directConnection=true

directConnection=true keeps the driver from hunting for a replica set on a single node. The database name still comes from the URI path.

The engine does not know it is talking to FerretDB. There is no FerretDB flag.

Against FerretDB 2.7 (August 2026): ordinary reads and writes, unique indexes, bulk writes, grouped aggregations, and time-based expiry of working data. The engine does not use multi-document transactions or change streams — two Mongo features FerretDB does not offer.

  • Not a second database we operate or staff.
  • Not a drop-in for the Mongo operations, backups, or monitoring you already know. Those are FerretDB’s and Postgres’s.
  • Not in the demo or all-in-one images. Those still expect MongoDB. You bring FerretDB the same way you would bring MongoDB.

If something fails, write to [email protected] with the engine version, the FerretDB version, and what broke. That report is how this graduates.

Next: Configuration reference · Self-hosting overview