You’re offline. This is a read only version of the page.
294
I must admit I've not paid much attention to Dataverse. My apps all use SQLServer databases: I can use all the power and speed of TSQL to do the heavy lifting, and rarely use Forms in Power Apps. So I've not really seen the need to learn Dataverse, which I've assumed (?) must be slower than SQLServer and lacks essential features like stored procedures and triggers.
Thinking about improving ALM, however, and experimenting with different environments, I'm told I HAVE to use Dataverse, and indeed, that not using it is 'unhealthy'.
Is this imperative just to support functionality like Solutions, or do I have to convert all my data sources to Dataverse and lose all my lovely fast SQLServer functionality if I want lifecycle management? How much do I have to sign up to the Dataverse religion just to get help with ALM?
Wow! Thank you @MattB-MSFT for a superb exposition, for once not overlaid with Microsoft-speak marketing froth. There is a lot to mull over in what you say, and I am very grateful to you for taking the time to say it. This is really helpful in getting over the 'Dataverse is a database - Dataverse is not just a database' conundrum that is so difficult to comprehend.
I will absorb and inwardly digest!!
a bit wordy .. but hang in there...
Taking your specific ask into account, here is how we (Microsoft) think about this:
PowerApps is the "UX" for the Power Platform. There are currently 3 UX engines in play, each with a different goal and focus, 2 of which are being merged together as a single 'engine' with 2 subsystems.
They are,
PowerAutomate is the "async workflow" engine for the Power Platform. (Leaving out the desktop automation aspects for the moment). This is the equivalent of Azure logic apps with a simpler interface and native support for the functions of the Power Platform. Power Automate communicates via "Connectors" to other systems internal and external to the Power Platform.
Dataverse is the "Engine" in the Power Platform. Its effectively "Azure in a box",
It provides the
There are several other systems in the Power Platform, but the 3 I listed are the 'big 3' (though the Power Virtual Agents system (BOTS) is rapidly approaching being the 4th 'big' system.
As I said,
Dataverse enables the Solution System. The solution system is our configuration portability system between environments for all aspects of a Power Platform environment. it's a big part of our "ALM" enabled system.
On top of that we have a packaging system that allows for you to bundle multiple solutions + data + deployment related code operations into a Power Platform Package.
Conceptually, the mapping of a Power Platform deployment to something like a Visual Studio solution works out like this.
A Power Platform Solution is equivalent to a Visual Studio "DLL Project"
A Power Platform Package is equivalent to a Visual Studio "Solution" (a group of projects within a solution deployed together)
Now, with all that out of the way and a bit of context set 🙂
When you hear us say "Dataverse is required for heathy ALM";
We are not saying that you have to use dataverse all the features we provide ( data / security / api ).
We are saying that you need to use Solutions (hosted in dataverse) to manage your configuration.
What all that means is that you can keep your PowerApps and Power Automates on top of SQL, you just need to create a solution and add those existing components too it, then use the solution to move it between environments (or a package if you are doing more complex things)
Sorry about the Long-winded answer there, but I think having the context as to WHY we are asking you do something helps folks understand what we are thinking and helps you provide us better feedback.
Thanks @DianaBirkelbach, that's an interesting blog. I can see a case where you are starting from scratch.
For an existing large and complex SQL Server database, though, the blog seems to imply you can 'pass through' Dataverse with 'virtual tables', but from a performance point of view I still can't see why you would want to put another layer in the way. Still less migrate hundreds of lovingly-perfected tables, views and stored procedures that have been performance-tuned over many years using the excellent SSMS, to something that's new, difficult to comprehend, and [possibly] bloaty.
I will experiment and see if I can get any of the positives - lifecycle management, Solutions - without giving up my beloved, 'unhealthy' addiction to raw SQLServer...
Hi @JonathanGibbs ,
I guess Microsoft heard you: the blog "3 Primary Reasons to Learn Dataverse" was published yesterday. It's a good answer to your question : https://powerapps.microsoft.com/en-us/blog/3-primary-reasons-to-learn-dataverse/
#1
WarrenBelz
85
Most Valuable Professional
#2
Michael E. Gernaey
65
Super User 2025 Season 1
#3
mmbr1606
55
Super User 2025 Season 1
Share
Report
All responses (
Answers (
