This is the client needed for mariadb correct?
That’s the package I am instructed to install when I set the client to mariadb. To me, the project look abandoned and it does not install on latest macos:
Your question is off topic, I think you shoud ask this question in a new topic.
He asked me to elaborate above
No, there is no need to use a MariaDB specific client. MariaDB is a drop in replacement for MySQL meaning the normal mysql package will work fine (and it’s what we install by default). This one specifically: mysql - npm
Ideally yes but I think we have safely covered all of the MongoDB topics in this thread and since some users are willing to move, I’m fine to provide limited context here. For more detailed convos about a move yes we should go to a new thread.
Any chance we can get some draft documentation on v4 architecture?
@aveprik all of our v4 RFCs will be here: Pull requests · strapi/rfcs · GitHub
We will progressively add more as v4 is moving along and we will have more detailed information once we get into the v4 beta later this year.
MySQL is still widely used, but only because WordPress isn’t fazed out yet… 
Postgre and MongoDB gain popularity though. And of course I still mostly use MariaDB and MySQL but only because I have to. Realm and MongoDB are more convenient for everything mobile which needs offline sync, which is about everything now.
1 Like
@DMehaffy Thanks for clarifying. I am heartened to hear that you have been in discussion with MongoDB and the Mongoose maintainer in looking to continue support for MongoDB as a persistence layer with Strapi.
I can appreciate that maintaining two very different database models (SQL & NoSQL) would be a larger strain on the development team to maintain both. Although I would say that the data you cite does appear to be very skewed. When data shows something as popular as MongoDB at only 0.4% from an analyst perspective my first instinct would be to question that and dig much deeper as to why. I would imagine that something is amiss there and before making decisions based on that data I would want to really know I could trust it.
Although trends can be useful at a superficial level they will also be heavily skewed as they would very much correlate to popularity and marketing of other systems, some which are blogs and many others which aren’t. If you have switched to using SQLite as the default installation then that too will skew results as any default would. It’s also not really something you want to be running in production so maybe excluding this from usage percentages may be more appropriate?
Also any search trends graphs are just that, search trends, not motivational trends or related to the business use case or even specifically to Strapi or CMS’s. They don’t provide the qualitative data which would provide a little more context. I would imagine that speaking to customers much like those which have come forward in this thread would provide some genuinely useful insights and a more contextual picture, especially from a production deployment point of view.
From a product perspective I would have also considered differentiation as a significant plus point. As others in this thread have also mentioned, many have come to Strapi because of its support for MongoDB which is unique among CMS’s. It’s advantageous from a mobile perspective and could be much better suited if you already use MongoDB for other systems. Having a fully distributed persistence layer with unlimited scalability and no concurrency limits is certainly nice to have when planning systems implementations. MongoDB Streams also help to move that data around to other systems for analysis or data warehousing without trying to setup and maintain CDC. Atlas can provide a nice easy setup for newbies and smaller use cases as well.
Anyway it seems that you have already made your decision, even prior to this thread opening, so I respect that. I would hope that you really do work with MongoDB/Mongoose in making sure the connector is as good as first-party and is supported long into the future. It is a concern to be replying on a third-party connector not officially supported by the product but with the parties involved I am provided with a little more confidence. It may even turn out for the better. I remain hopeful.
Thanks for the great work on Strapi, it really is a fantastic product and I’m looking forward to seeing what v4 brings, especially when MongoDB support is introduced…
We have a similar concern but during our research are unable to tell why it’s so low (we eliminated quite a few factors) and we were just as surprised to see that.
SQLite is already excluded from production usage (which honestly is the only metric that really matters here), any other environment did not impact our decision, only production.
We did speak with quite a few of our customers (and during pre-sales which doesn’t always convert into a customer, some do opt to stick with community instead of enterprise). That list included existing customers currently on MongoDB, and with a few exceptions most of them were willing to move without question. Quite a few stated they were already in the process of moving to a SQL database even before we brought up the topic. Most of the concerns weren’t about MongoDB vs SQL but more so about feature parity to ensure they wouldn’t lose any features (they won’t).
Indeed, this is possible (and I’m sure there is at least a handful of our users that came to Strapi for this reason) however we believe the move is worth the risk at this time. Since the MongoDB/Mongoose team will be building (and supporting) their own connector, this should more or less make this a non-issue now. The only difference is that we (Strapi), specifically my team, won’t provide Enterprise support for those users, nor will our GitHub issues allow for reporting bugs with that connector to us. Outside of that nothing should change other than the date MongoDB users could upgrade to v4 (we have no timeline for when MongoDB/Mongoose will start/finish their connector as the v4 will only launch from us with SQL support).
After months and months of discussion and interviewing external parties yes, we will do our best to help the MongoDB/Mongoose teams to build the connector. Whatever they put out in terms of compatibility and support for MongoDB will be far better that we could in the same amount of time.
Thank you!
2 Likes
@DMehaffy is there any update on this? I saw some other posts you commented on it felt like the MongoDB wasn’t eager to pick up the task. Can you elaborate? Still very much hoping this will happen.
1 Like
The MongoDB reached out a few weeks back to show a little interest on working on this. We clarified our position with them (we can’t help them build it, but we are willing to talk with them to find an integration path).
It’s still on their plate to build the package and will remain so. As far as we are aware they have not started working on it and we don’t have any idea how long it will take them. Integration is a concern especially now that we have no connector system, no ORMs (other than the one we built), and the @strapi/database package is entirely focused on SQL databases using Knex.js
This is going to take some time I believe and most likely won’t be completed before our v3 goes EOL.
Our upcoming migration guides will run in 2 parts for MongoDB users:
- v3 MongoDB => v3 SQL
- v3 SQL => v4 SQL
Initially we will have manual guides while we work with a contractor to help us develop automated tooling to help migrations.
Thanks for the insights @DMehaffy . It would be great if you could keep us updated on the matter in this post (so I don’t have to find news in other topics). Whatever the outcome, any news you can share would help in figuring out what to choose for the future.
I see at Migration Guides | Strapi Documentation that “The code and data migration guides will be released in March 2022.” Here’s hoping…
@Laurens_Kling & @adamskhan much like most everything we do, it’s all in the open:
Migration guides are being worked on in our public documentation repo: https://github.com/strapi/documentation
And I’ll do my best to keep up to date information in this repo but please keep in mind that from Strapi (the company’s perspective) we are no longer focused on MongoDB at all and will continue moving forward with our short and long term plans with absolutely zero focus on MongoDB or any other noSQL database.
If more information comes from the MongoDB team and their progress I’ll happily update but it’s not something we will be reaching out to them to ask about often or at all.
I just don’t want to raise anyone’s hopes here that Strapi will go back to supporting MongoDB in any capacity on our own because that is absolutely not in the plans. We will help the MongoDB team integrate their 3rd party package with Strapi if it comes to that but nothing we build going forward will focus on MongoDB integration. This falls in line with any other database that is not natively supported by the package we use for database connections:
Knex.js: https://github.com/knex/knex
(On that note, a community member is actively working on adding new support for CockroachDB: https://github.com/strapi/strapi/pull/12346)
Thanks @DMehaffy for the update. I’m not looking to continue with MongoDB, just wanting some migration help moving off it.
For those unaware and still looking to migrate, we do have a data migration script for v3 Mongo to v3 SQL (and of course our v3 SQL to v4 SQL):
1 Like