Update! Please see this message:
Context
Back in 2014, the very first version of Strapi was using an ORM called Waterline. The goal of an ORM is to provide a generic query language to perform requests on different databases. For the developer experience, it’s great, it makes things easier but it can create a lot of issues: performance, lack of native features support according to the database, etc.
When we re-developed from scratch Strapi, in 2017, we decided to use more specific ORMs. One for SQL database called Knex, and one for NoSQL MongoDB called Mongoose. Why? MongoDB was huge at that time. The MEAN (Mongo Express Angular Node) stack was rising, Node.js was often associated with MongoDB. We had to support it! We were also heavy users of software based on MySQL, and Postgres was getting a lot of traction too. We had to support them too!
Note: In 2017, our definition of Strapi was that “we are a data management framework with an administration panel”. We wanted to manage data without defining ourselves as a CMS. Data isn’t content. We now assume that we are a CMS. Nothing else.
Since then, Strapi has always supported SQL databases such as MySQL, Postgres, SQLite, MariaDB, etc, …and MongoDB.
Two years ago, we introduced the quickstart command to create a project in no time without any configuration. In order to achieve that goal, we used SQLite. Thus, MongoDB wasn’t the recommended starting database to test and try Strapi. It has been replaced by SQLite. We started to see a decrease in MongoDB usage from that moment until now (thanks to the Telemetry system)
- In March, MongoDB usage represents less than 0.4% of all the projects.
Mongo seems to represent a very low amount of projects.
Problem
Today, having to support two different connectors (SQL + MongoDB) slows down our developments. It makes also the engineering part more complicated. We have to make sure a feature has the same behavior and the API returns the same response according to the database. We have to do twice the job.
As we don’t use MongoDB as we should do to keep a consistent experience across databases, we have performance issues on many-to-many relations for example. But there are many more (see)
Motivation
As the usage of MongoDB as a database continues to decrease, as MongoDB Inc. told us they won’t maintain the current connector, as the success of Strapi isn’t linked with MongoDB and as the content modeling promotes the relational model that fits better with SQL database, I would suggest removing the official support of MongoDB and only support SQL databases natively.
From a product perspective, we could have a strong importers strategy to compensate for the lack of MongoDB (& other databases) support. If it’s easy to migrate content from a CMS using MongoDB to Strapi thanks to importers, it sounds good to me.
Drupal, WordPress, and many other CMSs restrict to one database, often SQL one and these are successful projects.
Consequences & Impacts
- Documentation
- We would have to remove all the documents & guides that relate to MongoDB.
- We would have to inform our users that we don’t officially support MongoDB natively.
- Support
- We should engage with customers and work with them to migrate to a supported database, we will not be able to support them long term as they will be unable to handle the jump to v4 when it’d released.
- Engineering
- We would have to remove the
strapi-connector-mongoose
package from the monorepo and create a new one. - We would have to change the README and clearly indicates that we don’t support it officially.
- Find a community member, company or partner who would like to maintain the connector.
- We would have to remove the
Last but not least, we already had a debate within the Core team, and we are all aligned by making this decision. We want to gather your feedback and discuss it with you (the community). It’s important for us to be more transparent about the decisions we would like to make as it impacts each one of you.
I’m looking forward to reading your answers, let’s have a free and respectful debate