We will need to hold off until at least the end of the quarter and most likely until Q3 due to the fact we haven’t even implemented the changes to the database layer (which will almost certainly require a detailed migration guide anyway).
Right now we are still largely in the design and planning phases for everything except the new design system, hence the lack of any migration guides/tooling currently.
Keep in mind that Strapi v3 will still exist and will still have security updates for at least 6 months after v4 stable release though we might increase that to a year (still discussing that timeline since it’s our first time increasing the major version since Strapi v1 => v3-alpha).
You won’t get any new features sure but it gives you a lot of time (well over a year from now) to make the switch into v4.
I agree this sucks…especially for people already deep in development or in production. I’m a huge MongoDB (database, not the company) fan and have a lot of projects in production using it.
To your point about trust and resources lost, this is a problem with ALL open source projects. We use open source projects for the time saving benefits. That comes at the cost of the people benefiting the most from time saved using the project, not having full control over the direction of the project. If you can’t fork over enough cash yearly to influence that direction (sponsorship), you’re at the mercy of the majority. That’s easy to forget. I’ve been through it with other projects.
That’s why I’m thankful for forks. If the change is too dramatic for me or my team, we fork our own version and maintain what we need. Everybody can do the same if they don’t want to migrate away from MongoDB at the cost of losing the time saved from the core team providing updates.
Hey everyone, we had a great and productive meeting with MongoDB Inc. last week. Here a summary of the actions and initiatives:
Valeri Karpov (Mongoose maintainer) will maintain the strapi-connector-mongoose package for the v3.
The Strapi Core team and MongoDB (included Valeri) will have a shared slack channel to communicate efficiently.
For the beta and stable release of the v4, Strapi won’t support MongoDB natively, and no connector will be available.
In Q4 2021, we will start working with MongoDB engineers to develop a strong and better database connector system within Strapi to let Valeri develop a MongoDB connector compatible with v4 afterward.
I personally think it’s good news for the ecosystem as it removes the burden to develop a connector system if we want to release the v4 on time. The second point is that co-developing this system with MongoDB will make it better, and we are happy and grateful to see MongoDB Inc. investing in the ecosystem. Even if MongoDB won’t be supported this year, it isn’t the end of the story between Strapi and MongoDB as announced in my first message but an exciting and promising new start!
Yes, it looks like a promising new start! After all, this step was necessary because the way MongoDB was treated as a relational database was of no use IMHO. Through the direct involvement of MongoDB Inc. I am convinced that no compromises will be made on performance.
Appears to be good news and perhaps bad news. Will a migration strategy from MongoDB to a sql database still be provided? Despite some connector maintenance, it is clear to me from the discussion I have built on the wrong database. Like a bandaid, I am better pulling it off quickly than allow the database to keep ballooning.
Would suggest the planned update to the docs be brought forward to make it much clearer that there is a preference of one database type over the other. At the moment it looks like they are all treated equal. I’m sure it is frustrating for some people who built databases in the past, but nowhere near as frustrating as it will be for those starting a database today and only finding this post in a months time.
Personally, I feel you may be better off sticking with your original plan of removing support. Don’t get me wrong, this will be a huge pain for me. But probably better for everyone for Strapi to take a little bit of heat for a while than create extra work for now three organisations that in the long run, it’s bound to be detrimental to the masses. It also doesn’t provide an attractive scenario for those looking for the most stable platform when it relies on coordination across orgs like that, it would be very hard to suggest MongoDB as an option. I get the feeling you all talked each other into the idea of a hybrid continual support, when perhaps sticking to your guns may had been better.
With more info on and commitment to a migration strategy, the amount of that .4% severely affected would be reduced considerably.
Regarding the .4%, presumably people can disable the telemetry despite what database they use. All things equal, let’s assume as many people on SQLite disabled telemetry as MongoDB and so forth. Suggests .4% would be a relatively accurate number (although curious how many users that equates to but really that’s understandably an internal number ).
I have been developing on an eCommerce site using Strapi+MongoDB for few months now, but this discussion made me sad. And I was rejoicing and looking forward to strapi v4, obviously with mongodb support. My perspectives are following:
MongoDB is popular for a reason. I have personally seen many cool projects using this NoSQL DB from the start, e.g- in Start-ups. It allows you to alter data structure without worrying which happens a lot in start-ups, in contrast to SQL databases where you need to run database migrations.
Overhead cost to start with MongoDB is cheaper. Many small projects can use MongoDB atlas free tier, unlike Postgres for which you will usually need to setup and serve from a cloud VM. These days you can get a VM for as low as 5$, but still it’s higher than FREE!
I think there should be two branches for strapi → Strapi+SQL and Strapi+NoSQL. Then these two products can evolve independently with community contributions.
We didn’t discuss migration strategies for now. What we know is that on Day 1, Strapi v4 won’t support MongoDB. The plan is to work with them to build the connector system, then they will develop a MongoDB connector. It means people having a project running on Strapi v3 with MongoDB won’t be able to migrate to Strapi v4 for at least 6 months until everything is developed on our + MongoDB end.
I agree with you we need to update the documentation as soon as possible. I’ve started a discussion with the Core team on that specific topic to clearly indicate that starting with Strapi v3 + MongoDB might not be a good choice if you want to enjoy v4 once released.
Yes, we will have some docs and/or tooling to help users migrate. Once we get closer to the beta (we haven’t even started on the database layer changes yet) we will provide some information.
We are working on that right now, expect a PR to the Docs in either sometime this week or next.
I believe, we don’t plan to offer any extended support to the possible future MongoDB connector (at least from the perspective of the enterprise version). As the goal of removing MongoDB lifts the problems we have with it from both an engineering and support side.
Just as we don’t “support” (provide help) to users that use 3rd party packages, the possible future MongoDB connector that isn’t developed by us would be treated as the same.
Yup we can’t release the exact number due to other companies watching us very closely But we don’t know who or how many disabled telemetry (that’s basically the point) but from what I’ve seen, even from our EE customers very few disable it so the numbers should be fairly accurate.
From my point of view, Strapi’s approach with telemetry was totally wrong and does not reflect in any way the distribution of the use of databases in web development. Even if that 4% were real, it would only mean that Strapi managed to attract only a tiny part of the MongoDB world that I know for sure is huge. Maybe the Strapi team simply likes to think that 90% use sqLite in production… Yes, I laugh because I think it’s a good joke! The truth is that the distribution of databases depends more on the type of web development targeted: for an eCommerce site, data mining, data analysis or other types of sites where calculations are required, a sql database is probably more appropriate, and for those who do not fall into these categories, a noSql database is probably sufficient. Trying to change this distribution is like blowing in the wind, neither Strapi, nor Wordpress, nor any other cms, crm, or anything else can dictate the distribution but only the market demand can do that!
Anyway, I think through the direct involvement of MongoDB Inc. after a while Strapi will benefit from a competitive connector.
It’s PostgreSQL by about 60% and the rest is made up of MySQL/MariaDB. SQLite in production is roughly 1-2%.
And that data is just telemetry, for our EE Customers it’s mostly PostgreSQL by probably 70% and MariaDB Galera Clusters 20% with the remaining being MySQL and MongoDB (and there isn’t a lot with MongoDB).
From the community side, most people I am helping regularly are PG users (especially those deploying on PaaS like Heroku, GAE, and DO Apps)
10 devs tries Strapi, 5 tries postgres in production (because they know it) and the other 5 tries mongodb in production (also because they know it). After a while, the postgres devs are happy, the mongodb devs are totally disapointed (like me) about the fact that mongodb is adding hundreds of milliseconds to the api response and thus getting a red score on pagesSpeed. Obviously, mongodb devs decide not to use Strapi and tell other mongodb devs about Strapi. After that comes Strapi team and says that they can’t support mongodb anymore and that it’s not a big loss because that’s only 4% …
That’s another reason why I’m saing that the Strapi’s approach with telemetry was totally wrong, this kind of analysis cannot be done purely in accounting terms without taking into account all the factors that led to those figures.
I wrote my thoughts here because I want it to remain written, time will show us the truth anyway. I have all the time in the world, only in business sometimes time makes the difference between being or not being.
Even if MongoDB usage was around 10 to 15% the question would have been the same. It’s a burden to maintain on our side. It doesn’t provide all the value that Strapi can offer to the users. Your point is correct and I would like to share one last metric with you.
Number of new projects created in the last 30 months (edited: days): +77k
Number of new projects created using MongoDB: 25
Number of new projects created using SQL database: +31k
The missing projects are the ones where the installation failed or the telemetry system is disabled before they start their server. The new projects include everything: quickstart + docker + normal + one-click deploy button.
The decision is made, the relationship with MongoDB is created, we need to move forward and see how we can make the migration and transition very smooth for all the users (SQL and NoSQL ones)
You read it well, only 25 (twenty-five projects) in the last 30 days were created using MongoDB. The way we collect the data is exactly the same whatever the kind of database used.
To be 100% transparent with you, when we discussed with MongoDB, they also shared their data with us (it was completely anonymous) and we were talking about less than a hundred projects on their side too. Even if it was important ones (paid customers), the MongoDB usage in the Strapi ecosystem is low.
As a manager, do you really beleave that number? Even if a child with 4 grades on the Moon looks, he would realize that something is incredibly wrong! I think I can find more videos on youtube about projects made Strapi + Mongo than that number! Or do you think that these 3.6k who viewed this topic until now are looking from pure curiosity?
According your nubers: 77k - 31k = 46k users. What are they use?
To make a good comparison you must use the same term for both. If you say only 25 (twenty-five projects) in the last 30 days were created using MongoDB… sure, you already announced that Strapi is dropping MongoDB support… so that may be correct number.