MongoDB dominates the NoSQL database world and is often praised for its developer experience, thanks to its mature ecosystem of drivers, libraries and tools. I recently read about a viable alternative, FerretDB, which is nearing its 2.0 release and now includes a compelling set of components. So, I thought I’d do a quick test and see how it performs! For this test, I used the release candidate (RC) version, as the full 2.0 release isn’t quite ready yet.

MongoDB is ‘mostly’ open, so what’s the problem?

For most intents and purposes, MongoDB’s Server Side Public License (SSPL) is as open as we’d ever need. It appears to be an eminently sensible license, on the face of it. Providing MongoDB, as a managed service, requires the provider to also open source their entire service stack. So, you couldn’t just suddenly develop a competing service and have the associated source code locked down. Now, it’s obviously the business interests of MongoDB Inc that drove a need for such a license, and is not be a problem for the overwhelming majority of adopters who utilise this NoSQL document database as a store for unstructured data. The following, however, are possible reasons we’d want an alternative:

• For keeping MongoDB Inc on its toes: competition is good.
• As a hedge against any possible future tightening of current license.
• Where enterprise policies restrict the usage of tools or services that are not fully open source.

That second point is important. MongoDB benefits from being open, but one can never predict what goes on in the minds of their executives, especially during the AI-filled sugar-rush we’re living through!

Unleash the Ferret!

Firstly, FerretDB on its own is not going to store anything because it’s essentially a proxy for the MongoDB API; a proper database is still needed and for this the FerretDB team have focused on Postgres with its huge community of users and possibility of unstructured data storage despite its relational nature. Unlike MongoDB, however, Postgres stores unstructured data in JSONB format, while MongoDB uses BSON; both are binary and therefore provide efficiency and indexing, but still different. Microsoft’s DocumentDB extension for Postgres provides the missing piece, enabling storage in the BSON format and enabling a smooth pathway between the MongoDB API and the ultimate storage destination, Postgres (see below).

Evaluating FerretDB Locally on Linux

Given that most deployments in production happen on Linux servers, to me it makes sense to then develop on a linux platform. For the purposes of this evaluation, I took a currently under development private project where MongoDB has already been used. The idea being that I should only need minimal adjustments when swapping MongoDB for FerretDB. After an initial unsuccessful attempt at installing the above components separately using Linux native packages, I quickly utilised FerretDB’s production image to generate containers via a Docker Compose script, which wraps up all necessary components in a single networked container cluster. In the spirit of Open Source, I used Podman Compose and Podman Desktop, to see how these stacked up against native Docker tools (see below).

Docker Compose YAML (Source: FerretDB Production Image):

services:
  postgres:
    image: ghcr.io/ferretdb/postgres-documentdb:16
    restart: on-failure
    environment:
      - POSTGRES_USER=username
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=postgres
    volumes:
      - ./data:/var/lib/postgresql/data

  ferretdb:
    image: ghcr.io/ferretdb/ferretdb:2
    restart: on-failure
    ports:
      - 27017:27017
    environment:
      - FERRETDB_POSTGRESQL_URL=postgres://username:password@postgres:5432/postgres

networks:
  default:
    name: ferretdb

The Results

The above solution worked like a charm, I could quite literally ‘swap’ MongoDB for FerretDB, having uploaded the relevant data, and with practically no adjustment to the codebase: it just worked! The codebase used the Mongoose ODM, which correctly mapped the database fields and the Compass frontend tool connected to the alternative database with no issues whatsoever (see below).

Closing Comments:

This was only a very basic test and a much more comprehensive evaluation is required before getting too excited. As of v2.0, FerretDB is said to have achieved compatibility with v6.0 of MongoDB. However, we’ll only know the extent of this claim when testing in anger, to ensure there are no show-stopping feature omissions. Nevertheless, for the open source absolutists, FerretDB is a clever solution built on top of solid foundations. It will be interesting to see how MongoDB Inc responds. My personal take is that they shouldn’t really mind: anything that entrenches the MongoDB API and tooling within the NoSQL database space may ‘secretly’ be seen as a positive?

Useful Links:

The following are some links related to the tools and packages used for this test.

• FerretDB GitHub page
• Microsoft’s recent DocumentDB Announcement
• Podman
• MongoDB Compass Tool
• Mongoose JS ODM
• Linux Mint