I thought you (I mean Strapi) finally understood that the telemetry system had seriously misled you, so … I find these numbers irrelevant.
This is disappointing, But if its really 0.4% then makes complete sense, Is it better to go with PG or MySQL now? Is there one that is recommended by Strapi over the other?
3 Likes
I do understand your decision but as it has been commented already, to have mongo as recommended DB for Strapi during an entire version (v3) to get it completely remove now makes no sense and it is not a customer focus decision. All my projects are using mongo, even in development. To have to migrates these projects already in production to another DB with of course not yet warranty this will happen and will be supported.
It really makes me think if I’d like to continue with Strapi for future projects, not because I don’t like it, because I do love it, but seems I cannot rely on Strapi to be my tool on the future as any version can have breaking changing impacting me and my customers. How can I go to a customer that I have already delivered a project that by the end of the year they will need to pay for a DB migration because Strapi does not support the selected DB? I would expect a longer legacy support at least 1 major version at least if you try to target enterprise customers.
5 Likes
It was only “recommended” in the CLI during the Alpha and Beta (~2 years ago now), in the late beta/stable verison of v3 we switched to SQLite.
We won’t be making decisions like this regularly, this is a massive one that we have been discussing internally for a very long time. We engaged with customers, reviewed all the GitHub issues and Enterprise support tickets. We will be doing our best to make this migration as painless as possible in the near future (especially for the same reasons you have identified, with our EE customers).
Keep in mind we don’t have a stable release date for the v4, we are only expecting a beta towards the end of the summer.
1 Like
from recently shared graph it seems it is considering test projects as SQLite has highest percentage, anyways its misleading as I know many people who has disabled telemetry. they don’t have resources to maintain & their talks with MongoDB Inc, failed so they are dropping support. MongoDB is still a popular DB.
1 Like
You are correct, it is a popular database. But by disabling telemetry you give up the option to have your voice included, as I’ve said before, we won’t change this. We give you the option to opt-out for a reason as we know some companies require it. But if you want your data included in how we make these decisions, then opt-in to the telemetry.
The production environment telemetry still showed a massive gap between SQL and Mongo (without SQLite).
This is a nightmare , 1 year of dev , 5 developers ,to many resources LOST. It is not about profit ,it is about TRUST . If you do this now , this will be a message not only to MongoDB users ,but to all .In the future you can decided to remove postgre to , and sql as well and tell us to migrate to Neo4j or any graph data base .If you lose the trust ,you lose everything (Try to remember what happen to ActionScript and Adobe).What will happen if your bank tell you tomorrow “Sorry we dont take cash no more , but you can use other bank to transfer money in to yours” you will be long gone from this bank and go to the next one not because you need to put cash but because is a matter of TRUST.
3 Likes
@valeri_had I agree. I wish strapi all the luck but me and my team will start moving away from it now.
1 Like
As someone who ended up migrating a production app from Mongo to Postgres (at the advent of v3) I’d say it makes a lot more sense to focus Strapi on relational DBs. Outside of the technical reasons I chose for the migration, I found that Strapi just worked better and the data structure more closely resembled what was communicated in the Admin UI. The Content Type Builder shows things in a more relational manner. When I was running Mongo I was never sure which relation type would give me the best result, and it was easy to make the wrong choice.
I love Mongo and this is a tough call, but I think it’s the right move for Strapi’s longevity.
1 Like
This is certainly unfortunate news since we are a couple weeks from deploying a 5 month long project using Strapi/MongoDB. We certainly were looking forward to v4 but at the same time you have your reasons and sometimes you have to do what’s best for the majority of users. I’m hopefully in the future the community can scrape together a mongoose connector for v4.
Thanks for all your hard work.
2 Likes
This is quite bad news for me as I have been working on an application in Strapi for >1 year and am now in the process of going to production with a mongo db. I had no idea I was in such a minority of users. I have really liked being a part of Strapi’s maturation and would like to stick with it. Please please provide support for users like me who are willing to migrate to stick with Strapi.
Cheering for your success.
3 Likes
Good for you, but Migration is not easy for big projects with custom mongoose query & queries with aggregate, it would be easy to replace Strapi than to change db OR to keep using v3 & maintaining own fork. Like In our case we are not using many admin features, admin is only for limited (superadmin like) user so we can keep using v3, or can choose to replace strapi.
Also this decision came very late, so its not a good sign for strapi & its users.
Can you explain this a bit more? Not sure I understand the meaning here as we made the decision only a week before making this forum post and probably 7 months before the v4 stable release date (roughly we don’t have a stable date planned, only an early beta)
Thank you for remaining positive and I hope we can keep the light abstraction layer and have someone in the community who can pick up the MongoDB connector. But yes we have to do whats best for the future of all of our users and us as a company.
Thank you for sharing this, we entirely agree that MongoDB can certainly be a useful and great database for various reasons but in a massively relational use-case like Strapi a relational DB makes more sense.
1 Like
First 3.0 stable release was in May-2020, at that time, this was no where in roadmap, you also created Github issue for asking suggestions for new features in v4, that time also this was not excepted.
ideally in next major release people expect new features & some breaking changes, but this is like removal of one of the highlight feature, it is still present in Github README & documentation.
- Database agnostic. You can choose the database you prefer. Strapi works with SQL & NoSQL databases: MongoDB, PostgreSQL, MySQL, MariaDB, and SQLite.
& No one would expect removal of highlighted feature in next major release, So I said decision came very late.
4 Likes
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.