I’m looking for some guidance from the community based on real-world experience.
Has anyone successfully replaced the core Umbraco CMS persistence (content, members, backoffice state, schema/migrations) with MongoDB in modern versions of Umbraco (v9+ / v10+ / v13+ / v17)?
To be clear, I’m not referring to:
using MongoDB as a side-store for domain or application data, or
integrating Mongo for analytics, logs, or external content.
I’m specifically asking about replacing the primary Umbraco CMS database.
From what I can see, Umbraco 9+ is built on EF Core with relational assumptions around migrations, transactions, joins, caching, and backoffice behaviour. I’m trying to understand whether:
this has been achieved successfully in production projects, or
it remains theoretical / experimental, or
there are known limitations or risks that make it impractical.
If anyone has links to real implementations, blog posts, talks, or guidance (or can confirm that this isn’t something people are doing in practice), that would be really helpful.
At the moment, this is not really possible. Yes, it’s partly Entity Framework, but a lot of it is still NPOCO and is very SQL Server specific (and SQL Lite). Currently, SQL Server, SQL Server local db and SQL Lite are the only working databases.
At least HQ has been able to do both Sqlite and MSSQL support so its definitely possible. For the MySQL one, there was just a couple of things that weren’t compatible in core, but I wouldn’t expect that to be the case for every other provider.
There has also been a community effort to do a PostgreSQL provider:
I happened to be in one of the recent MVP meetings (with Luuk as a matter of fact) and brought up this exact PR!
For everyone else, the response was that it was going to take time/gradual transition to EF Core, but they were mum on PGSQL outside of being curious why I was looking for it.
SQL Server just isn’t a good DB for cloud providers. It’s often nearly 2x as expensive as Maria or PGSQL and less integrated with backups/scaling/etc features. For like 99.8% of my own uses, there’s nothing that makes it notable over the other database options.
Sure, there’s Express edition, which I do use sometimes, but MS still has the process capped at 1.4 GB RAM, like it’s 2005. At this point, MSSQL is actually more of an annoyance for me personally, as Umbraco is still holding on to what feels like legacy tech.
As for dropping Mongo in, I feel like that’d be almost a whole new product. Umbraco makes heavy use of the EAV (entity-attribute-value) pattern, which I can’t imagine mapping very well onto a document/nosql database.
The irony of course is that a lot of those values are now just blobs of JSON
Long term I think Umbraco could, and probably should, shift more towards a document-orientied approach to the database. It would be better suited to Umbraco’s content models, improving efficiency and scalability. EF Core can unlock that, and even make for a staggered approach.
BUT, the “S” in CMS covers a shedload of features and a lot of those currently need a “proper” RDBMS.
I’d personally love to see an abstraction through EF Core that lets us do both. Relational by default with the option to have documents/media etc. stored in MongoDB, Cosmos or whatever.