cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
Advocate V
Advocate V

SQL Server (on prem) vs Sharepoint Lists for PowerApps

We have an on-prem SQL Server that our ERP system runs on, and we already have the gateway in place and can add/manipulate tables from PowerApps via the gateway, and the $7 p1 fee isn't an issue for allowing this (effective Jan 2019)

 

But I am not a SQL developer/DBA/etc. I know enough to make tables and do the really basic stuff. I've been playing with Sharepoint Lists and like some of its features like calculated columns, and just ease of use - no firing up SSMS, and no exporting/dropping tables/recreating/editing/importing just to add or change columns.

 

But I don't want to get too deep into this project and realize SQL or Sharepoint would have been the right course and I am on the other course.

Our PowerApps will not be super sophisticted. 100% Canvas apps, usually 1-3 tables (or lists) per app, and mostly DIM tables, nothing transactional. So a few hundred to a few thousand records as a rule.

Does anyone have any good links/articles/thoughts on one vs the other.

The Common Data Service doesn't really interest me as it is a 3rd technology to learn and from what I understand, the big benefits don't matter to me due to the data sizes I am talking about. Plus, our environment has the old CDS apparently with PickLists and no word if MS will ever upgrade that, so I have zip interest in learning an obsolete tech, nor much interest in moving hundreds of our existing Flows to a new environment just so any apps we write can work with Flow, and having all of our Flows in one environment.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Super User
Super User

Short answer: Go with SQL

 

Longer answer:

Although not complex (for now) your Apps need to access a few thousand rows and that means delegation. SQL has far more support for delegation (and more scope for workarounds, such as converting a date to a integer to allow delegated filtering).

Also, you can create views in SQL for dealing with relationships between tables and this is easier and more efficient (performant) than doing it on the PowerApps.

Many times, when working with SharePoint as the backend, I've wished I were working with SQL. Never have I worked with SQL as a backend and wished I was working with SharePoint.

View solution in original post

2 REPLIES 2
Highlighted
Super User
Super User

Short answer: Go with SQL

 

Longer answer:

Although not complex (for now) your Apps need to access a few thousand rows and that means delegation. SQL has far more support for delegation (and more scope for workarounds, such as converting a date to a integer to allow delegated filtering).

Also, you can create views in SQL for dealing with relationships between tables and this is easier and more efficient (performant) than doing it on the PowerApps.

Many times, when working with SharePoint as the backend, I've wished I were working with SQL. Never have I worked with SQL as a backend and wished I was working with SharePoint.

View solution in original post

Highlighted


@PaulD1 wrote:

Many times, when working with SharePoint as the backend, I've wished I were working with SQL. Never have I worked with SQL as a backend and wished I was working with SharePoint.


Thanks. That speaks volumes. I was ever so slightly leaning towards SQL, but this makes it a much clearer decision for me.

Helpful resources

Announcements
Community Conference

Power Platform Community Conference

Check out the on demand sessions that are available now!

News & Announcements

Community Blog

Stay up tp date on the latest blogs and activities in the community News & Announcements.

secondImage

Power Platform 2020 release wave 2 plan

Features releasing from October 2020 through March 2021

Community Highlights

Community Highlights

Check out the Power Platform Community Highlights

Top Solution Authors
Top Kudoed Authors
Users online (7,927)