This would make me so sad 
I’m running about 20 strapi installations now with mongo (not using telementry, I always type my package.json’s myself so it’s not in there). I really hope this break doesn’t come soon.
1 Like
Might I suggest that you introduce an import/export feature before version 4 is out, in order to make the transition easier?
As someone who’s been using strapi in production for the past year and a half, I don’t know what I’d do. I might end up forking v3 and maintaining it, because it might be more cost-effective.
Ideally I would love to see the support going on for another major version, in order to have more time to adjust.
3 Likes
- Find a community member, company or partner who would like to maintain the connector.
What kind of workload do you anticipate this to be? Specifically, what’s the time investment you expect for ongoing support, as well as one-time larger investments when there are big changes (e.g. v4)?
There could be community support, but those who want to help should know what they’re getting into.
Depending on the changes we make to the SQL databases in v4 it may require an almost total rewrite of the MongoDB connector.
1 Like
As mentioned earlier in the thread, we don’t even expect a beta release of v4 until the end of the summer, there is no set date for a stable release but tentatively the end of the year.
If we would do something like this, it would be more so a small tooling script that runs outside of Strapi. Import/Export is tad too basic and wouldn’t account for complex parts of a project such as relations (and media).
It’s highly unlikely we would consider something like this, the best example I can think of is Python 2 => 3. This was the same reason they kept Python 2 alive for so long and caused more issues than it solved (fracturing the ecosystem). For us it also becomes a much larger problem as we want to build some very awesome features on top of the v4 (things like content-versioning, publication workflows, ect) that just will not fit well within MongoDB as they will be extremely relation based.
Hello everyone - this is MongoDB phoning in. We are discussing taking over support of this connector, and I have reached out to Aurelien via email. Thank you to the folks who pinged us about this post!
Rachelle
12 Likes
Thank you for this. I think that connector will need a full rewrite, so here are some of my thoughts:
- try to use node mongodb native not mongoose
- do not treat
mongodbas relational database, I don’t needsql <--> noSqlmigration, when I build an API and when I choose a database it’s ok to stick to it forever, and if someone needs such migration will be able to do this using conversion tools. If not sure if this is a good choice please open a poll.
From mongoDB main page:
MongoDB is a document database, which means it stores data in JSON-like documents. We believe this is the most natural way to think about data, and is much more expressive and powerful than the traditional row/column model.
When we build a website we use json, then when we send the data to the server is converted twice (in the current implementation), hence all the problems and lack of performance. Please try not to repeat the same mistakes!
Aurelsicoko -
This is absolutely right and correct decision!
Several years have passed since the first version of strapi was created and the overall vision has changed.
I agree with you that you need to discard all that delays team from moving forward.
I think this topic is about those affected by this decision and not about those who were happy before and will be just as happy after. Some have spent years of their lives developing their project and now they will be left without support …Or it doesn’t matter to you if you kill a few thousands because you still have millions of them?
@DMehaffy
I created this PR to update main readme file to inform users about the change since there may be users installing Strapi based on mongoDB as we speak. I saw Strapi updated some slides used in some videos without mongoDB, but I think all documents containing mongoDB should be updated right away so as not to mislead users.
I also think that that the conversion tool should be made available as soon as possible to give users time to decide where to migrate and to have time to get acquainted with that database. In fact, I think Strapi should have built that tool first and then made the announcement…
Only now found out about this decision and I am very devastated to know Strapi devs are planning to drop MongoDB support. I have several projects running on Strapi and MongoDB and it would be quite bad to lose support of Mongo. Absolutely not looking forward to having to migrate projects to Postgres.
4 Likes
Those projects that are already running on one of the previous versions of strapi will continue to work in the same way.
You just can’t do an easy upgrade to the newest version of strapi.
Thank you all for your messages and the healthy discussion, it’s really appreciated! By making this tough decision, we knew we would disappoint some of you, especially those who run Strapi projects in production using MongoDB.
However, Strapi is a product, a CMS. We have to make decisions to continue to be competitive and make sure we can deliver a lot of value to you. Even, if MongoDB users represent a thousand projects on Strapi, even if some of you disabled the Telemetry (like many SQL users) at the end, it still represents a minority of users. We cannot slow down the development of Strapi by 20% for every single feature and enhancement we would like to make for the reason above. This is our point of view, you might disagree with it and I completely understand. On our side, if we continue to maintain and support connectors, or features that a minority of users use, we are going to build a “tank” like other very famous CMSs, very hard to maintain and contribute. We don’t want to be this CMS.
We understand that some of you like MongoDB, we still like it a lot too. This decision isn’t against MongoDB or the users using it. It’s a product strategic decision of the Core team to ensure we can find a way to be sustainable as a company to continue investing in the open-source product. As @techbelle mentioned, we started to discuss with MongoDB (another team) to let them take over the maintenance of the package. It’s very good news and we are glad to start collaborating closely with them 
Be sure that we won’t let down anyone (it never has been the plan), Strapi v3 still officially supports Mongo as a database. The initial plan was to drop the support for the v4 which isn’t developed yet, we expect a Beta release this summer and a stable version at the end of Q3, 2021. According to the discussion with MongoDB, we have two scenarios in front of us:
- We have 6 months to think about the migration strategy and tools for those who would be interested to migrate to an SQL database.
- Strapi v4 would support MongoDB, the connector wouldn’t be maintained by the Core team but my MongoDB or Mongoose’s maintainer itself.
5 Likes
FWIW: I have my fingers and toes crossed 
for scenario #2, (paraphrased: Keep MongoDB support & have the MongoDB team support/maintain the connector) 
Thx for persevering through all of this due diligence; y’all are awesome! 
7 Likes
it would be terrible to drop support for mongodb like me and others migrating from different solution to work with mongodb for better scale like MongoDB sharded cluster! backend is very powerful especially when havy traffic for client endpoint for stream and for sure hope scenario #2, (paraphrased: Keep MongoDB support & have the MongoDB team support/maintain the connector)
2 Likes
Based on this chart we can safely say that it’s safer for us to migrate to Postgre instead of MariaDB because you’ll not drop the support for it?
It’s unlikely we will drop support for any of the existing SQL databases because there is very little cost involved to support one over the other (doesn’t include adding new databases such as MSSQL or Oracle DB but for largely different reasons, likewise proprietary cloud DBs like Aurora Db on Azure).
For the most part the SQL databases are supported because have a single set of packages that just handle them natively with only minor differences (Knex.js)
3 Likes
We have a MongoBD replica set and a lot of custom services, written with custom queries. It’s really hard to migrate to SQL now because 90% of all requests has some specific logic. It’s so terrible news for us that I can’t imagine how we could move on
@DMehaffy, tooling to help to migrate off Mongo now in version 3.x would be great. For live projects that are actively developed, who can afford to wait to see if migration tooling will or will not drop? Better to get off Mongo now.
Now you’ve announced the decision, I think prioritising migration guides/scripts/tooling (Mongo to PG etc.) for 3.x deployments would be appropriate. Otherwise, we have to freeze development or carry on in hope that migration tooling will eventually arrive, or start our individual migration (or reimplementation) efforts now.
4 Likes