MongoDB
Problem
We want to Provide MongoDB via AppCat. MongoDB licensing might be an issue. This decision looks closely at the licensing and alternative products that can be used as drop-in replacements for MongoDB.
Proposals
- Proposal 1: Use MongoDB Community Edition
-
MongoDB community edition is licensed under the SSPL. The SSPL dictates that the source code for the tooling that provides the services needs to be available to the public. However, it would also need to be licensed under the SSPL.
- Proposal 2: Use MongoDB Enterprise Operator
-
MongoDB Enterprise Operator can be used to manage MongoDB instances on Kubernetes. There has been preliminary contact with MongoDB about the licensing for the AppCat use. The pricing options are internally available. There’s a helm chart to deploy it. It does need an enterprise license though. Which will require a license key to be present on the K8s clusters.
- Proposal 3: Use FerreDB with PostgreSQL
-
FerretDB is a Drop-In replacement. FerretDB is an adaptor for PostgreSQL which exposes a MongoDB compatible API. It uses PostgreSQL as the backend to store data. FerretDB itself is stateless and can be deployed as deployments alongside a PostgreSQL instance. However, it does not implement everything that MondoDB supports. So a MongoDB AppCat service based on FerretDB might not be fully compatible with all workloads, which can result in bad UX for the customers.
Decision
Proposal 2: Use MongoDB Enterprise Operator.
This is the only viable option to run a MongoDB SaaS on K8s. There’s no helm based deployment for MongoDB Enterprise Edition. The implementation for this service cannot rely on the generalizations we’ve made for helm based services. It will need more custom implementation, like StackGres based PostgreSQL deployments.
Due to the licensing required, this service will not be deployed by default. For development purposes community edition could be used.