MongoDB compatibility delayed on v4

We are still discussing how we plan to implement connectors in the future (v4) and if we will maintain the current strapi-database package (it’s the abstraction layer between Strapi and the database ORMs/connectors).

There are many within the team that still wish to continue to allow new connectors and open the connector ecosystem to allow the community to build and maintain their own but there is still a cost to this that being discussed internally.

To be clear, I don’t have an answer to this and nor does anyone else in the team as it’s being discussed at an engineering level (I say this and 3 seconds later @Aurelsicoko answers lol)

However I am one of those who would like to keep this layer and eject the current strapi-connector-mongoose package to it’s own repo and offer the option for someone else to take over maintainership of the code and npm package. Many others in the Strapi team also suggested this. Something else we are possibly looking to do is create different connectors for each database to allow for smaller connectors with narrow scopes and the ability to use different orms (or none) to interact with specific supported databases. eg:

  • @strapi/connector-mysql
  • @strapi/connector-postgres
  • @someCompany/connector-mongodb

(Yes btw we are moving all Strapi packages to scoped packages to allow for easier forks of our own packages: Init scoped packages by alexandrebodin · Pull Request #10183 · strapi/strapi · GitHub)


this one should be @someCompany/connector-mongoose which has almost nothing to do with mongodb native driver

We aren’t talking about drivers, connectors are step above drivers and implement logic that pertains to Strapi usage only, hence MongoDB instead of mongoose.

We wouldn’t have talked about connectors if they weren’t drivers, mongoose uses its own driver which has no value in my opinion.

And anyway, if it’s to put a correct name you can’t call mongodb = mongoose, it would be a curse to mongodb

This is disappointing, but I can understand the rationale. However, this comment suggest you won’t be providing any migration tools to get off Mongo. Correct?

1 Like

Wow it was unpredictable, but the reasons is resonable, if it will speed up the development process its great! But unfortunatly for me, I started with strapi + mysql and after few mounth I decided to migrate on mongo, and now I should migrate to sql again :smiley: Please tell me what will be the best choice from suported sql databased especially for strapi, because in the past I already catched some bugs on mysql


Ok but this is very big decision & might impact many users (definitely more than 0.4%), so poll on some public platform would be good (it will increase trust), also no need to design new information gathering system for it, Github upvotes on new issue can also be used for voting. Also you said there are many Github issues are specific to MongoDB, it means many people are using strapi with MongoDB.
& instead of dropping support you can consider disabling or limiting some features for Mongo, like many-to-many relation.


The problem is (which is quite easy to see here), SQL users wouldn’t vote because it doesn’t impact them so all we would get are MongoDB users who don’t want to migrate.

I will clear it on Monday but I will happily pull up and share a graph from our telemetry system to prove the numbers.

We have already confirmed we will be dropping support for it internally. This forum post is more so gauge how we handle that drop and what users feel they need/want/would like to have either to make that migration easier or determine if someone speaks up about taking over maintaining the package.

The decision to drop MongoDB will not be reversed, we just literally do not have the man/woman power to properly maintain the connector through the v4 with everything we have planned. To keep it on the table (won’t happen) would most likely delay the v4 long past what we want.

I know it’s frustrating, I have been in your shoes myself as I was a member of the community of Strapi for more than 3 years before I joined the team. I’ve seen, debugged, and helped fix many of them. I’ve written the documentation, ran tests, ran performance testing, and have looked at the mongoose connector more than I would like.

(The number of bugs does not directly reference the number of users and some of them have been open for two years or more)


We will evaluate that later on, but I would fully expect some documentation and possibly some tooling as we have enterprise customers using MongoDB and will be assisting in their migration. To what level that documentation and tooling extends to is still TBD as done when we will start work on it.

Considering we haven’t even started working on the DB layer yet (Q3 likely) with a rough beta v4 eta at the end of the summer, most likely that documentation and/or tooling will happen in Q4.

Depends on the application and deployment structure. My personal recommendation from performance testing I have done myself:

If you are a smaller project with a single database (not clustered, single geo-location) then PostgreSQL is a good choice and generally what we use internally in our own projects. The Strapi website runs on PG.

If you have a larger application or need a clustered database with excellent syncing capabilities in multiple geo-locations or you need very good multi-master/multi-write (for apps with many post or put queries) then MariaDB Galera cluster and ProxySQL.

(Honestly I prefer MariaDB over MySQL any day for any reason as I don’t trust/major fan of Oracle. And I prefer to support other “truly open source” applications and databases)

Agreed :+1: that is reasonable

Absolutely all the projects that we have created in our team at IBM use MongoDB, but they all have telemetry disabled (request of the security team). So it is a big problem to lose this support.

I even remember that at the beginning of v3, MongoDB was the database that Strapi recommended.

That said, and understanding the decision you want to make… If losing the MongoDB support is inevitable, I would expect at least, provided by the Strapi team, a very simple way to be able to migrate to another database.

I have had to create an account here on this forum, expressly to be able to reply to this topic, since the GitHub issue is blocked and GitHub Discussions are disabled. :frowning_face:


Thanks for the clarification. For my situation a clear path to migrate media library content and preserve existing asset Ids would be the most important thing.

1 Like

(Snipped as off-topic by @DMehaffy)

That .4% stat is that considering all of the projects or just the ones in production. Because I personally have 20+ strapi projects on my computer which ALL use SQLite however If I am working on a project that is going to go into prod I would use MongoDB.


I understand the problem here and I somewhat agree with that approach which Strapi is taking however I think there is a larger underlying problem to be solved. Your team can’t deliver as flexible and simple of a product when you have to cross support functionality in completely different products.

Many CMSs such as Laravel have solved this problem over the years by only supporting one database type, in Laravels case it was only SQL.

That being said I think that it would helpful to abstract the database ORM to support pluggable databases and implement “Strapi connectors” of sorts.

Not only would that allow for you to maintain one specific database type, but it would allow the impact of this decision to be minimal as you could create a “unsupported community maintained” MongoDB connector.

That way people can migrate and maintain their MongoDB stuff while still understanding that the functionality may differ and be less supported.

I think this would be a good road to go down as it would add pluggable functionality for virtually any database someone is willing to make a connector for. They just have to implement it. It would also fuel the open source community to make Strapi related projects which is always a plus for the popularity of frameworks.

Just an idea though :slight_smile:

1 Like

I agree with what’s @aveprik and @Volxz mentioned. Great suggestions.

I myself being using MongoDB when working with Strapi, which are in production as well. This decision was purely because MongoDB Atlas has a generous free tier. This helped the lowest the startup cost as well.

Given the fact I believe the decision you guys that’s made here on an engineering perspective is justifiable. I believe v4 is underway given the announcement in the conference ,but when are you guys hoping to role out this change ?

Oh no, one of the main reason I used strapi was because it support mongodb, now I’m pretty skeptical.

By the way, Is there any migration guide at the moment?


Hi all, just to make the data a little more transparent; these graphs have been pulled from our telemetry system. The information gathered is entirely anonymous and we only track the Strapi UUID from your package.json.

In this case the data being shown is the client value from the running database config (we don’t send anything else from the database config, only this key).

90 Days stacked usage chart

90 Days + only production environment

(SQLite is omitted here because we don’t recommend it in production)

90 Days all environments

60 Days all environments

30 Days all environments

Finally to answer the question about migrations:

We will have more information on migration guides later on this year, at the moment we do not have migration guide from MongoDB to any other database.

1 Like