It could be connected with typescript implementation that is one of most wanted features on roadmap:
I am using mongo in some projects deployed on production. Mongoose is not needed for me. I am more comfortable with native mongo connector or experimental mongo support in prisma.
@robwells57 / @stephent
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:
strapi-connector-mongoose package for the v3.beta and stable release of the v4, Strapi wonāt support MongoDB natively, and no connector will be available.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:
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.
everyone ā¦ except MongoDB users
Yes, what do you do if after a while MongoDB becomes the main Strapi connector? Will you still believe then that giving up the rest of the connectors will be āfor the benefit of the massesā?
Your approach is at least unprofessional ā¦ to be elegant!
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)
Thatās not the only point. Take this scenario:
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.
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) 
25 or 25k ?
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?
Which one is correct? 30 daysā¦ or 30 months?
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.
We estimate that between 5 to 15% (it means 700 to 10,000 projects in this case) of the projects disables the telemetry system. We know the database used only if the server starts, not before. Moreover, only 67,3% of the users who want to create a project succeed in that process. It means that for 32,7% of the 77k projects (it means +25k projects) something went wrong (error during the build, lack of disk space, bad internet connection, dependencies installation error, etc). Last but not least 5% of the created projects never start. When you add all of this, you start to be closed to the 46k projects you were looking for.
These numbers are only for quickstart projects. For other projects, following manual installation, the numbers are worth and we lose even more users. As the numbers, I shared with you in my previous arenāt contextualized to quickstart projects, it easily explains the 46k users you were looking for.
I know you might be disappointed about the current situation and decision, please be sure that we take every feedback very seriously whatever the platform is (GitHub, Twitch, Youtube, Discord, Slack, forum, etc) and we do our best to gather as many data but also user feedback as possible. We run user interviews, we talk on a daily basis with companies building huge projects on Strapi. We know this decision isnāt without any consequences, but I repeat it here, Iām convinced that this decision is the best one for Strapi.
Ok, I got it, that means your sharing of Number of new projects created in the last 30 months: +77k was kind of pointless. After that your saying that Number of new projects created using MongoDB: 25 it did not fit that context, and the numbers reffers to 30 days not 30 months plusā¦ those 30 days are the last 30 days which also reveals that these numbers are of no importance. It was more interesting if we had the figures from the last 30 months, or even the last 5 years.
Iām not disappointed, really! I am convinced that the decision to drop MongoDB support was a good one, not because of the numbers, but because Strapi is running very badly on MongoDB. And I am convinced that the involvement of MongoDB Inc. will lead to the realization of a good connector. I pray for that, and I am patient as I said!
I just wanted to point out that Strapi may underestimate the MongoDB market demand .