Enterprise lohnt sich für eine Anforderung, nicht für eine Featureliste.
„Wir brauchen Always On, also brauchen wir Enterprise.“ Dieser Satz fällt in vielen Budgetgesprächen, und er ist in dieser Allgemeinheit falsch. Die Failover Cluster Instance (FCI) und die Basic Availability Group gibt es in der Standard Edition, und sie decken einen großen Teil der Hochverfügbarkeitsanforderungen ab. Enterprise rechtfertigt sich durch genau vier Anforderungen, und für drei davon gibt es einen Standard-Weg, mit Abstrichen. Dieser Teil zeigt die vier Anforderungen, die Kapazitätsgrenzen, die oft der eigentliche Treiber sind, und die Lizenzregeln, die die Architektur mitbestimmen: was „passiv“ heißt, wann eine Secondary eine eigene Lizenz braucht und warum Software Assurance zur HA-Frage gehört. Regeln, keine Preise; maßgeblich ist Ihr Vertrag.
Kurz gesagt
- Vier Anforderungen rechtfertigen Enterprise: Datenbanken, die zusammen umschalten müssen; lokale Automatik plus Schutz im zweiten Standort; eine Kopie, die Berichte liest oder Backups übernimmt; Betriebsmerkmale wie Contained AG, Distributed AG, Online-Indexwartung und Fast Recovery. Für die ersten beiden hat Standard einen Weg, für die dritte keinen, für die vierte nur Handarbeit.
- Standard kann mehr, als der Satz „Always On braucht Enterprise“ vermuten lässt: FCI mit zwei Knoten, Basic AG mit einer Datenbank und zwei Replikaten, Log Shipping, Accelerated Database Recovery, TDE und seit SQL Server 2025 den Resource Governor.
- Der heimliche Treiber ist die Kapazität: Standard nutzt je Instanz bis SQL Server 2022 höchstens 24 Cores und 128 GB Buffer Pool, ab 2025 höchstens 32 Cores und 256 GB. Wer darüber liegt, braucht Enterprise, egal wie er umschaltet.
- Passive Replikate sind ein Recht aus Software Assurance oder Subscription. Ohne SA oder Subscription braucht nach Microsoft auch der passive Knoten eines Failover-Clusters eine eigene Lizenz. Mit SA: ein passives Replikat für beliebigen Zweck inklusive Hochverfügbarkeit, zwei weitere nur für Disaster Recovery, eines davon in Azure.
- Passiv heißt: Das Replikat liefert keine Daten an Benutzer. Eine lesbare Secondary ist deshalb nicht passiv und braucht eine eigene Lizenz. Konsistenzprüfungen, Voll- und Log-Backups und das Messen der Ressourcennutzung sind auf dem passiven Replikat laut Product Terms zulässig.
- Eine Basic AG wird nicht zur vollen AG. Die Instanz lässt sich im Setup von Standard auf Enterprise hochstufen, auch bei einer FCI; die Gruppe muss danach entfernt und neu angelegt werden.
Vier Anforderungen, die Enterprise rechtfertigen
Die Featurematrix aus Teil 2 listet, was die volle Availability Group mehr kann. Für die Entscheidung hilft die Liste wenig, denn kaum jemand braucht alles davon. Hilfreicher ist die Frage, welche Anforderung hinter dem Wunsch steht, und ob Standard sie auf einem anderen Weg erfüllt. Es sind vier.
Mehrere Datenbanken müssen zusammen umschalten
Viele Anwendungen bestehen aus mehreren Datenbanken, die zusammengehören: Fachdaten, Konfiguration, Archiv, eine Datenbank je Mandant. Fällt eine um und die andere nicht, steht die Anwendung trotzdem. Die Basic AG kann das nicht lösen: Sie enthält genau eine Datenbank, und mehrere Basic AGs auf derselben Instanz schalten unabhängig voneinander um (Teil 1). Die volle AG löst es mit einer Gruppe, die alle Datenbanken gemeinsam umschaltet.
Der Standard-Weg: die FCI. Sie schaltet nicht Datenbanken um, sondern die ganze Instanz, und damit alle Datenbanken zusammen, samt Logins, Jobs und Linked Servern (Teil 1). Was er kostet: gemeinsamen Speicher, eine einzige Datenkopie, einen Failover, der ein Instanzneustart mit Recovery ist. Wer eine Enterprise-Empfehlung mit „mehrere Datenbanken“ begründet, sollte vorher gefragt haben, warum keine FCI.
Lokale Automatik und Schutz im zweiten Standort
Die typische Anforderung eines Rechenzentrumsbetreibers: Fällt ein Server aus, soll es automatisch weitergehen; fällt der Standort aus, soll im zweiten Rechenzentrum eine Kopie bereitstehen. Dafür braucht es mindestens drei Replikate: zwei synchron am ersten Standort, eines asynchron am zweiten. Die volle AG macht genau das, wahlweise als Distributed AG über zwei Cluster (Teil 2). Die Basic AG hat zwei Replikate und kann deshalb nur eines von beiden: lokale Automatik oder Standortschutz.
Der Standard-Weg, mit Abstrichen: FCI für die lokale Automatik plus Log Shipping in den zweiten Standort. Log Shipping läuft in Standard, hat eine eigene Datenkopie auf eigenem Speicher und schützt mit einem verzögerten Restore sogar vor Anwenderfehlern, was keine AG kann. Der Preis: Der Rollenwechsel im zweiten Standort ist Handarbeit, der Datenverlust entspricht dem Takt der Log-Backups, und Logins und Jobs müssen dort gepflegt werden wie bei jeder AG. Wer einen manuellen Standortwechsel akzeptieren kann, hat damit eine belegte Standard-Architektur.
Die Kopie soll arbeiten
Das ist die eine Anforderung ohne Standard-Weg. Berichte auf der Secondary lesen, Backups auf der Secondary laufen lassen, Integritätsprüfungen auslagern: Das kann nur die volle AG (Teil 2). Die Basic-AG-Secondary erlaubt keinen Lesezugriff, keine Backups und keine Integritätsprüfungen. Passive FCI-Knoten sind gestoppt; es gibt dort nichts zu lesen. Die Standby-Datenbank von Log Shipping ist nur zwischen den Restores lesbar, also nicht für laufende Berichte.
Zwei Dinge gehören zu dieser Anforderung dazu. Erstens ist die lesbare Secondary nicht kostenlos: 14 Byte je geänderter Zeile auch auf dem Primary, Zeilenversionen in der tempdb der Secondary, mögliche Redo-Blockaden durch lange Leser (Teil 2). Zweitens ändert sie die Lizenzrechnung: Eine Secondary, die Berichte liefert, ist nicht mehr passiv und braucht eine eigene Lizenz. Dazu unten mehr. Wer die Berichte nur vom Primary wegbekommen will, hat Alternativen: eine getrennte Reporting-Kopie per Replikation oder Datenextrakt, zeitversetzte Auswertungen auf einem Standby mit Log Shipping, oder die Frage, ob die Berichte auf dem Primary wirklich stören.
Betriebsmerkmale, die den Alltag erleichtern
Die vierte Anforderung heißt selten so, steckt aber in vielen Enterprise-Wünschen: Die Contained AG (ab SQL Server 2022) führt Logins und Jobs mit der Gruppe; die Distributed AG verbindet zwei Cluster; Online-Indexoperationen und der fortsetzbare Indexaufbau halten Wartungsfenster klein; Fast Recovery bringt eine Datenbank nach dem Redo online, während das Undo noch läuft; dazu Online-Seitenwiederherstellung, parallele Konsistenzprüfung, Mirrored Backups und Hot Add Memory. Alles laut Editionsseiten nur in Enterprise, in allen vier Versionen von 2017 bis 2025.
Der Standard-Weg ist Handarbeit: Logins mit gleichen SIDs und Jobs mit Primary-Prüfung auf jedem Replikat pflegen (Teil 2), Indexwartung in Wartungsfenstern, Recovery ohne Fast Recovery. Immerhin: Accelerated Database Recovery gibt es seit SQL Server 2019 auch in Standard, und sie nimmt der Recovery den größten Zeitfresser, die Undo-Phase langer Transaktionen (Teil 2). Ob die Handarbeit ein Argument für Enterprise ist, hängt an der Betriebsmannschaft: Ein Team mit Automatisierung trägt sie, ein Administrator nebenbei eher nicht.
Der heimliche Treiber: Kapazität
In vielen Projekten entscheidet nicht die Hochverfügbarkeit über die Edition, sondern die Größe. Die Standard Edition ist je Instanz begrenzt, und die Grenzen stehen auf den Editionsseiten von Microsoft:
| Grenze je Instanz | Standard 2017 bis 2022 | Standard 2025 | Enterprise |
|---|---|---|---|
| Rechenkapazität | der kleinere Wert aus 4 Sockeln oder 24 Cores | 4 Sockel oder 32 Cores | Betriebssystemmaximum |
| Buffer Pool | 128 GB | 256 GB | Betriebssystemmaximum |
| Columnstore-Segment-Cache | 32 GB | 32 GB | unbegrenzt |
| Speicheroptimierte Daten je Datenbank | 32 GB | 32 GB | unbegrenzt |
Die Grenzen gelten je Instanz, nicht je Server; mehrere Standard-Instanzen können einen größeren Server ausnutzen. In virtualisierten Umgebungen zählt die Zahl der logischen Prozessoren der VM. Liegt die Last einer einzelnen Instanz über diesen Werten, ist die Editionsfrage beantwortet, bevor jemand über Failover gesprochen hat. Und dann lohnt es sich, die volle AG gleich mitzudenken, denn sie ist in Enterprise enthalten.
Standard hat mit den neueren Versionen einzelne Merkmale dazugewonnen, die früher Enterprise-Argumente waren: Transparent Data Encryption und Accelerated Database Recovery ab SQL Server 2019, den Resource Governor und die höheren Kapazitätsgrenzen ab SQL Server 2025. Datenkomprimierung, Partitionierung, Backup-Komprimierung und verschlüsselte Backups sind in Standard seit 2017 durchgängig vorhanden. Bei den Availability Groups ändert SQL Server 2025 für Standard dagegen nichts.
Was Standard kann, in einer Tabelle
| Anforderung | Standard-Weg | Was er kostet | Enterprise-Weg |
|---|---|---|---|
| Knotenausfall automatisch abfangen | FCI (2 Knoten) oder Basic AG (2 Replikate, synchron) | FCI: gemeinsamer Speicher, eine Datenkopie; Basic AG: Instanzobjekte je Replikat | volle AG |
| Datenbanken zusammen umschalten | FCI | Instanzneustart mit Recovery als Failover | volle AG mit mehreren Datenbanken |
| Storage-Ausfall überleben | Basic AG oder Log Shipping (eigene Kopie) | Basic AG: eine Datenbank je Gruppe; Log Shipping: manueller Wechsel | volle AG |
| Lokale Automatik plus zweiter Standort | FCI plus Log Shipping | Standortwechsel von Hand, Datenverlust im Takt der Log-Backups | volle AG mit asynchronem Replikat oder Distributed AG |
| Berichte auf der Kopie lesen | kein Weg | Reporting-Kopie anders beschaffen oder auf dem Primary lesen | lesbare Secondary (eigene Lizenz) |
| Backups auf der Kopie | kein Weg | Backups auf dem Primary | Backups auf der Secondary, ab 2025 auch Voll und Differential |
| Logins und Jobs mit der Gruppe führen | kein Weg | Pflege auf jedem Replikat | Contained AG (ab 2022) |
| Indexwartung ohne Sperrfenster | kein Weg | Wartungsfenster | Online-Indexoperationen, fortsetzbarer Aufbau |
| Schutz vor Anwenderfehlern | Log Shipping mit verzögertem Restore, Backup | manueller Wechsel | ebenfalls nur Log Shipping oder Backup, keine AG |
| Mehr als 24 bzw. 32 Cores oder 128 bzw. 256 GB je Instanz | kein Weg (außer mehreren Instanzen) | Aufteilen der Last | Enterprise |
Die letzte Zeile vor der Kapazität ist die wichtigste: Gegen Anwenderfehler hilft keine Edition und keine Replikation, nur ein getestetes Backup oder ein verzögerter Restore. Wer Enterprise „für die Sicherheit“ kauft, sollte diesen Punkt vorher geklärt haben.
Die Lizenzregeln, die die Architektur mitbestimmen
Lizenzregeln sind kein Thema, das PSG gern in einen Fachartikel schreibt, aber sie bestimmen die Architektur mit, und sie werden in HA-Diskussionen oft falsch wiedergegeben. Deshalb hier die Regeln aus den Microsoft-Dokumenten, Stand 09.11.2026: Licensing Guidance zu SQL Server 2025, Product Terms und der SQL Server 2022 Licensing Guide. Es sind Wiedergaben, keine Rechtsberatung, und es sind keine Preise. Maßgeblich ist der Vertrag, den Sie mit Microsoft oder Ihrem Partner geschlossen haben.
Zwei Lizenzmodelle. Enterprise wird nur per Core lizenziert, Standard per Core oder nach Server plus Zugriffslizenzen (CAL). Beim Core-Modell sind auf einem physischen Server alle physischen Cores zu lizenzieren, mindestens vier je Prozessor; bei einer virtuellen Maschine die virtuellen Cores, mindestens vier je VM. Die Lizenzierung je VM setzt Software Assurance oder eine Subscription-Lizenz voraus. Enterprise mit SA oder Subscription erlaubt auf einem vollständig nach physischen Cores lizenzierten Host unbegrenzt viele Instanzen in beliebig vielen VMs; das Recht endet mit der SA.
Fail-over-Rechte sind ein SA-Vorteil. Das ist die Regel, die Architekturen entscheidet: Passive Replikate sind nach Microsoft ein Recht aus Software Assurance oder Subscription. Lizenzen ohne SA haben keine Hochverfügbarkeits- und Disaster-Recovery-Rechte, auch nicht für Failover-Cluster: Der passive Knoten einer FCI braucht dann eine eigene Lizenz. Mit SA oder Subscription darf jede lizenzierte Primary-Workload bis zu drei passive Umgebungen haben:
- eine für beliebigen Zweck, einschließlich Hochverfügbarkeit, etwa den passiven FCI-Knoten oder die synchrone Secondary,
- eine nur für Disaster Recovery auf einem beliebigen Server,
- eine nur für Disaster Recovery in Azure.
Die Lizenzen, die das passive Replikat sonst bräuchte, dürfen die des Primary nicht übersteigen; ein größerer Standby-Server ist also nicht automatisch abgedeckt. DR-Umgebungen müssen laut Product Terms asynchron und manuell betrieben werden, und ein kurzer Test des DR-Betriebs ist alle 90 Tage erlaubt. Ob das passive Replikat eine AG-Secondary, ein FCI-Knoten oder ein Log-Shipping-Ziel ist, unterscheiden die Texte nicht.
Was „passiv“ heißt. Ein passives Replikat liefert keine SQL-Server-Daten an Benutzer oder Geräte und führt keine aktiven Workloads aus. Zulässig sind laut Product Terms Konsistenzprüfungen, Log-Backups, Vollbackups und das Erfassen von Ressourcenmessdaten. Mehr nicht. Die Folge für die Architektur:
- Eine lesbare Secondary, die Berichte liefert, ist nicht passiv. Microsoft Learn sagt ausdrücklich, dass jede Instanz, die ein lesbares Replikat hostet, eine SQL-Server-Lizenz braucht, und der Licensing Guide 2022 verlangt für Secondaries, die mehr als den reinen Failover leisten, die volle Lizenzierung. Als Vorsichtsregel gilt deshalb: Wer eine Secondary lesbar einstellt, sollte sie als lizenzpflichtig einplanen, bis der eigene Vertrag etwas anderes sagt.
- Eine Secondary, auf der nur Backups und CHECKDB laufen, bleibt im Rahmen der Wartungsliste und kann passiv sein. Differentialbackups, die SQL Server 2025 neu auf Secondaries erlaubt, stehen nicht in der Liste; wer sie dort fahren will, sollte das vertraglich prüfen.
- Der passive FCI-Knoten hat seine Instanz nicht gestartet und ist der klassische Fall des passiven Replikats. Werden auf einem Cluster zwei Instanzen aktiv/aktiv betrieben, braucht jede Umgebung mit aktiver Instanz eigene Lizenzen; passive Rechte gelten nur für wirklich passive Knoten.
- Die Basic-AG-Secondary kann weder lesen noch sichern; dass sie als passives Replikat gilt, sagt keine Lizenzquelle ausdrücklich, folgt aber aus der Definition. Auch das gehört in die Vertragsprüfung.
Editionswechsel. Eine Standard-Instanz lässt sich im SQL Server Setup auf Enterprise hochstufen („Edition Upgrade“), auch eine FCI: Der Upgrade auf einem Knoten genügt, danach startet man die Instanz neu oder schwenkt um. Der Dienst-Neustart ist Ausfallzeit. Der umgekehrte Weg von Enterprise nach Standard ist kein Upgrade, sondern Deinstallation und Neuinstallation, und für Failover-Cluster ist er als nicht unterstützt gelistet. Eine Basic AG überlebt den Wechsel nicht als Gruppe: Sie muss entfernt und als volle AG neu angelegt werden. Lizenzrechtlich nennt der Licensing Guide 2022 den Wechsel von Standard Core auf Enterprise Core als „Step-up“, der SA auf der Standard-Lizenz voraussetzt; der technische Upgrade im Setup ersetzt diesen Schritt nicht.
Woher die Regeln stammen. Der Fail-over-Abschnitt der Product Terms ist für die Programme EA, EAS, SCE, MPSA, MCA, Open Value, Open License, EES und Select Plus wortgleich. Service-Provider-Verträge (SPLA) und Pay-as-you-go über Azure Arc haben eigene Bedingungen, die hier nicht geprüft sind. Einen Licensing Guide zu SQL Server 2025 als PDF haben wir nicht gefunden; die Aussagen stützen sich für 2025 auf die Web-Guidance und die Product Terms, für die Wartungsliste und die Beispiele auf den Guide zu SQL Server 2022.
Was lizenziert wird: dieselbe Topologie, vier Varianten
Dieselben Regeln, angewandt auf eine Beispieltopologie: Jeder Server ist eine VM mit 8 virtuellen Cores, also 8 Core-Lizenzen (Mindestzahl 4 je VM ist erfüllt). Gezählt werden Lizenzeinheiten, keine Preise. Die Spalte „mit SA oder Subscription“ nutzt die Fail-over-Rechte; ohne SA braucht jedes Replikat eigene Lizenzen.
| Variante | Lizenzpflichtig | mit SA oder Subscription | ohne SA |
|---|---|---|---|
| FCI, 2 Knoten, Standard | aktiver Knoten | 8 Core-Lizenzen Standard (oder Server+CAL); passiver Knoten frei | 16 Core-Lizenzen Standard |
| Basic AG, 2 Replikate, Standard | Primary; Secondary nicht lesbar, keine Backups | 8 Core-Lizenzen Standard; Secondary als passives Replikat (Vertragsprüfung) | 16 Core-Lizenzen Standard |
| Volle AG, 3 Replikate (2 lokal synchron, 1 asynchron im zweiten Standort), keine Secondary lesbar | Primary; synchrone Secondary = passiv HA; asynchrone Secondary = passiv DR | 8 Core-Lizenzen Enterprise | 24 Core-Lizenzen Enterprise |
| Volle AG, 3 Replikate, eine Secondary liefert Berichte | Primary und lesbare Secondary; DR-Replikat passiv | 16 Core-Lizenzen Enterprise | 24 Core-Lizenzen Enterprise |
Die Tabelle zeigt, warum Lizenzregeln die Architektur mitbestimmen: Zwischen der dritten und der vierten Zeile liegt nichts als die Entscheidung, auf einer Secondary Berichte zu lesen. Sie verdoppelt die lizenzpflichtigen Cores. Und zwischen „mit SA“ und „ohne SA“ liegt bei jeder Variante der Unterschied, ob der Standby überhaupt frei ist. Beides sind Fragen, die vor dem Architekturentwurf geklärt gehören, nicht danach.
Fünf Fehlschlüsse
„Always On heißt Enterprise.“ Always On ist der Oberbegriff für FCI und Availability Groups (Teil 1). Die FCI mit zwei Knoten und die Basic AG sind Standard. Enterprise wird es erst durch eine der vier Anforderungen oben.
„Wir haben zwei Knoten, also brauchen wir zwei Enterprise-Lizenzen.“ Mit SA oder Subscription ist der passive Knoten frei, in Standard wie in Enterprise. Ohne SA braucht er eine Lizenz, aber dann in der Edition, die läuft, und das kann Standard sein.
„Die Secondary ist Standby, da ziehen wir mal eben die Monatsberichte.“ Sobald sie Daten an Benutzer liefert, ist sie nicht mehr passiv. In Standard geht es ohnehin nicht (Basic AG ohne Lesezugriff), in Enterprise kostet es die Lizenz der zweiten Instanz.
„Wir nehmen Basic AG und stufen später hoch.“ Die Instanz lässt sich hochstufen, die Gruppe nicht. Die Basic AG muss entfernt und als volle AG neu angelegt werden, mit neuem Seeding und einem Wartungsfenster. Wer das in zwölf Monaten vorhat, sollte heute die Architektur der vollen AG planen und die Lizenz vorher klären.
„Enterprise ist gekauft, also nutzen wir die Secondary auch.“ Das ist eine legitime Entscheidung, aber eine mit Lizenzfolge: Die Secondary wird lizenzpflichtig. Die bessere Reihenfolge ist, erst zu klären, ob Berichte auf der Kopie die Anforderung sind, und dann zu lizenzieren, nicht umgekehrt.
Drei Entscheidungsmuster
Die Fachanwendung mit einer Datenbank. Ein Rechenzentrum, Datenverlust ausgeschlossen, Wiederanlauf in Minuten automatisch, niemand liest auf der Kopie, die Last liegt deutlich unter den Standard-Grenzen. Standard reicht. Die Wahl zwischen FCI und Basic AG fällt über den Storage (gemeinsam vorhanden oder nicht) und die Mannschaft (Instanzobjekte pflegen oder nicht). Mit SA oder Subscription ist der zweite Knoten frei. Offen bleibt: Failover geprobt, Anwendung verbindet sich neu, Backup getestet.
Zwei Rechenzentren, mehrere zusammengehörige Datenbanken. Lokale Automatik und Standortschutz, die Datenbanken müssen zusammen umschalten. Enterprise mit voller AG ist der gerade Weg: zwei synchrone Replikate lokal, ein asynchrones im zweiten Standort, alle drei mit SA passiv frei, solange keine Secondary liest. Der Standard-Weg heißt FCI plus Log Shipping: automatisch lokal, von Hand in den zweiten Standort, mit Datenverlust im Takt der Log-Backups. Welcher Weg passt, entscheidet die Frage, ob ein manueller Standortwechsel akzeptabel ist, nicht die Featureliste.
Die Berichte sollen weg vom Primary. Das ist die einzige Anforderung, die zwingend zur Enterprise Edition führt, und sie bringt die Lizenz für die lesbare Secondary mit. Vorher lohnt die Gegenprobe: Stören die Berichte den Primary wirklich, oder fehlt ein Index? Reicht eine zeitversetzte Kopie? Erst wenn die Antwort „laufende Berichte auf aktuellen Daten“ heißt, ist die lesbare Secondary die richtige Architektur, und dann mit vollem Wissen um ihren Preis in tempdb, Redo und Lizenz.
Häufige Fragen
Braucht die Basic Availability Group Enterprise? Nein. Die Basic AG gibt es nur in der Standard Edition. In Enterprise legt man eine volle AG an.
Zählt eine lesbare Secondary als passiv? Nach Microsoft Learn und dem Licensing Guide 2022 nicht: Eine Instanz mit lesbarem Replikat braucht eine Lizenz. Planen Sie eine lesbar eingestellte Secondary als lizenzpflichtig ein, bis Ihr Vertrag etwas anderes sagt.
Darf ich auf dem passiven Knoten Backups und CHECKDB laufen lassen? Ja, laut Product Terms gehören Konsistenzprüfungen, Log-Backups, Vollbackups und das Erfassen von Messdaten zu den zulässigen Arbeiten eines passiven Replikats. Differentialbackups stehen nicht in der Liste.
Kann ich Standard in place zu Enterprise hochstufen? Ja, über den Edition Upgrade im Setup, auch bei einer FCI auf einem Knoten; danach Dienst-Neustart oder Failover. Der Weg zurück ist eine Neuinstallation. Eine Basic AG muss nach dem Wechsel neu angelegt werden, und der Lizenzwechsel ist ein eigener Schritt.
Brauche ich Software Assurance für eine FCI? Technisch nein. Lizenzrechtlich braucht der passive Knoten ohne SA oder Subscription eine eigene Lizenz, weil die Fail-over-Rechte ein SA-Vorteil sind. In der Praxis gehört SA deshalb zu fast jeder HA-Architektur dazu.
Ändert SQL Server 2025 etwas an der Editionsfrage? An den Availability Groups für Standard nichts. Standard bekommt höhere Kapazitätsgrenzen (32 Cores, 256 GB Buffer Pool) und den Resource Governor; damit tragen mehr Instanzen die Last in Standard. Die Web Edition entfällt, und eine kostenlose Standard Developer Edition erlaubt, Anwendungen gegen den Standard-Funktionsumfang zu entwickeln und zu testen, nicht aber Produktion, DR oder Backup damit zu betreiben.
Wie es weitergeht
- Teil 4 · Entscheidungshilfe: acht Fragen zu Anforderungen und Rahmenbedingungen, als Ergebnis begründete Kandidaten; keine Entscheidung aus drei Klicks.
Wenn Sie vor der Entscheidung stehen
Ob Standard reicht oder Enterprise gerechtfertigt ist, entscheidet sich an Ihren Anforderungen, an der Kapazität und am Vertrag, in dieser Reihenfolge. Im Verfügbarkeits-Review unseres Health Checks legen wir Ziele für Datenverlust und Wiederanlauf neben das, was Ihre Umgebung heute erreicht, und prüfen, ob die Last in die Standard-Grenzen passt. Für Planung, Aufbau und Migration steht die Leistung Infrastruktur und Hochverfügbarkeit. Wir verkaufen keine SQL-Server-Lizenzen und beraten deshalb bei Edition und Cores ohne eigenes Lizenzverkaufsinteresse; die Prüfung Ihres Vertrags bleibt bei Ihnen und Ihrem Lizenzpartner.
Quellen
Fachaussagen dieses Teils stützen sich auf Microsoft-Dokumente, geprüft am 08. und 09.11.2026: Editions and Supported Features 2017, 2019, 2022 und 2025; Compute Capacity Limits by Edition; What's New in SQL Server 2025; Basic Availability Groups; Business Continuity and Database Recovery (Abschnitt Read-Scale); Supported Version and Edition Upgrades 2017 bis 2025; In-place Change of a SQL Server Edition; SQL Server 2025 Licensing Guidance; Product Terms „SQL Server“ in den Programmvarianten EA/EAS/SCE, MPSA, MCA, OV/OVS, OL, EES und S/S+; SQL Server 2022 Licensing Guide (PDF, Dezember 2022). Lizenzaussagen sind Wiedergaben dieser Dokumente ohne Preise und ohne Rechtsberatung; maßgeblich ist der eigene Vertrag. Die Zahl synchroner Replikate nennt Microsoft auch im Licensing Guide anders als auf den Editionsseiten; dieser Teil nennt deshalb keine.