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 
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
2 Likes
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.
3 Likes
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)
2 Likes
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 
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. 
15 Likes
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.
2 Likes
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 
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?
2 Likes
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
To be honest this is such a good decision. Strapi works really well the SQL database and current implementation is clearly breaking the NoSQL database principles too. Technically strapi is utilising NoSQL as SQL itself which destroys the purpose of NoSQL. I have seen numerous issues in Github from populating relationship to much more like indexing, some complex query patterns etc. This may break some users but this can also remove so much headache for many.
As a solution providing some migration scripts would be really helpful. With this change I can also see that Strapi can focus more on making its database layer much more efficient rather than making something that it is not meant for.
4 Likes