Dataverse vs. SQL vs. SharePoint: Entscheidungshilfe

„Sollen wir das in Dataverse, in SQL oder einfach in SharePoint Lists bauen?" — diese Frage steht am Anfang fast jedes Power-Platform-Projekts im Mittelstand und wird oft aus dem Bauch beantwortet: SharePoint, weil es schon da ist. SQL, weil die IT das kennt. Dataverse, weil Microsoft es empfiehlt. Alle drei Begründungen taugen nichts.

Dieser Beitrag stellt die drei ehrlich gegenüber — mit Kosten, Limits und dem, was nach zwei Jahren passiert, nicht nur am Demotag. Ziel ist nicht, dir Dataverse zu verkaufen, sondern dir die teure Fehlentscheidung zu ersparen.

1. Worüber wir hier eigentlich entscheiden

Die drei sind keine Gegner auf derselben Ebene — sie lösen unterschiedliche Probleme:

SharePoint Lists — ein Listen-Werkzeug für Teams. In jeder M365-Lizenz enthalten, nie als Anwendungsdatenbank gedacht.
Azure SQL — eine reine Datenbank-Engine. Maximale Kontrolle, aber Logik, Sicherheit und Oberfläche baust du selbst dazu.
Dataverse — dazwischen: relationale Datenhaltung plus Logik plus Sicherheitsmodell, fertig in die Power Platform integriert.

Die richtige Frage ist nicht „welches ist das beste", sondern „welches passt zum Lebenszyklus, den die Anwendung vor sich hat". Die meisten Fehlentscheidungen entstehen, weil die Anwendung in der Demo nach SharePoint aussieht und in zwei Jahren ein SQL-Problem ist.

2. Die ehrliche Gegenüberstellung

Das folgende Schaubild fasst die Achsen zusammen, an denen die Entscheidung fällt — nicht Featurelisten, sondern Eignung über die Zeit.

SharePoint Lists — schneller Einstieg, harte Decke

SharePoint Lists ist gut für das, wofür es gemacht ist: eine überschaubare Liste, die ein Team gemeinsam pflegt. Sofort da, kostet nichts extra, Power Apps greift direkt darauf zu.

Die Decke kommt schneller als gedacht. Die 5.000-Elemente-Schwelle ist kein hartes Datenlimit, aber ab dort werden Filter, Sortierung und delegierbare Abfragen zur ständigen Reibung. Beziehungen zwischen Listen sind fragil — referenzielle Integrität gibt es nicht. Die Berechtigung ist grob; ein zeilengenaues, rollenbasiertes Modell baust du damit nicht sauber.

Ehrliche Empfehlung: richtig, wenn die Anwendung klein bleibt, team-intern ist und keine harte Berechtigung braucht. Sobald „später für Abteilung X öffnen" oder „mit dem CRM zusammenspielen" fällt, ist es die falsche Grundlage — der Umbau ist teurer als der korrekte Start.

Azure SQL — maximale Kontrolle, maximale Eigenleistung

Eine eigene SQL-Datenbank gibt dir alles: volle Kontrolle über Schema, Indizes, Optimierung, beliebige Last. Für hochfrequente, schreibintensive Szenarien mit Millionen Transaktionen oft die einzig sinnvolle Wahl.

Der Preis steht woanders: Sicherheit, Logik, API, Oberfläche und Lebenszyklus baust du selbst. Was Dataverse mitbringt — Rollenmodell, Audit, Web-API, Power-Apps-Integration — ist bei SQL Eigenentwicklung. Kein Argument gegen SQL, sondern eine Kostenwahrheit: günstig in der Lizenz, teuer in der Eigenleistung über die Laufzeit.

Ehrliche Empfehlung: richtig bei sehr hoher Last, Eigenentwicklungen außerhalb des Power-Platform-Kontexts oder echtem Bedarf an Engine-Kontrolle. Für die typische Mittelstands-Business-App meist Über-Engineering.

Dataverse — der mittlere Weg mit den niedrigsten Folgekosten

Dataverse ist selten am Entscheidungstag am billigsten und oft über die Laufzeit am preiswertesten: relationale Datenhaltung, zeilengenaues Sicherheitsmodell, Logik am Datensatz und Integration in Power Apps, Power Automate und Power BI — ohne das selbst zu bauen.

Der Gegenwert: Lizenzkosten pro Nutzer oder App und eine Lernkurve beim Daten- und Sicherheitsmodell. Wer Dataverse wie eine SharePoint-Liste behandelt, zahlt den Plattformpreis ohne den Nutzen. Wie man es richtig macht: Dataverse-Leitfaden.

3. Die Entscheidungslogik in einer Frage-Kette

Statt Featuretabelle: vier Fragen, die fast immer reichen.

Diese Kette ersetzt keine Architekturberatung, filtert aber die falschen Optionen schnell heraus. Der häufigste Fehler: eine Anwendung mit langem Lebenszyklus auf SharePoint zu starten, weil es am Demotag am schnellsten geht.

4. Die versteckten Kosten, die niemand in die Demo schreibt

Jede Option hat Kosten, die erst nach Monaten sichtbar sind:

SharePoint: der Sanierungsaufwand, wenn die Anwendung über Listenlimit oder grobe Berechtigung hinauswächst. Eine Migration nach Dataverse ist machbar, aber nie trivial.
Azure SQL: die laufende Eigenleistung für alles, was Dataverse mitbringt — Sicherheit, API, Oberflächen, Lifecycle. Ein dauerhafter Posten.
Dataverse: Lizenzkosten bei vielen Gelegenheitsnutzern und die Lernkurve. Wer Daten- und Sicherheitsmodell unsauber aufsetzt, zahlt zusätzlich den Sanierungsaufwand — siehe Security Roles und Best Practices zur Datenmodellierung.

Die nüchterne Sicht: Rechne nie nur den Lizenzpreis, sondern die Total Cost of Ownership über drei bis fünf Jahre, inklusive wahrscheinlichem Wachstum. So gewinnt Dataverse für die typische Mittelstands-Business-App häufiger, als der Tagespreis vermuten lässt — und SharePoint seltener, als seine Null-Lizenzkosten suggerieren. Gesamteinordnung: Power-Platform-Leitfaden für den Mittelstand.

Fazit

Es gibt keine universell beste Option, aber vorhersehbar falsche. SharePoint Lists ist richtig, solange die Anwendung klein und team-intern bleibt, und wird zur Hypothek, wenn sie wächst. Azure SQL ist richtig bei hoher Last und Kontrollbedarf, Über-Engineering für die typische Business-App. Dataverse ist selten am Entscheidungstag am günstigsten und über die Laufzeit oft am preiswertesten — vorausgesetzt, du behandelst es als Plattform, nicht als bessere Liste.

Die ehrlichste Empfehlung: Entscheide nicht nach dem, was die Anwendung heute ist, sondern nach dem, was sie in zwei Jahren absehbar wird. Diese Perspektivverschiebung verhindert die meisten teuren Fehlentscheidungen.

Unsicher, was zu deinem Fall passt?

Wir schauen uns deinen Anwendungsfall an — Lebenszyklus, Nutzerzahl, Berechtigungsbedarf — und sagen dir ehrlich, welche der drei Optionen trägt. Auch wenn die Antwort „SharePoint reicht" lautet.

Anwendungsfall durchsprechen Power Platform Leistungen ansehen