Consulting Briefing

19.06.2026 · boddenberg.de

SQL Server Lizenzierung: Aktuelle Informationen und Änderungen für 2026

Executive Summary

Kurz gesagt: Das gute alte SQL-Server-Lizenzmodell lebt noch, aber drumherum hat sich 2025/2026 genug bewegt, dass dich Nichtstun bares Geld kosten kann. Microsoft hat das Preismodell mit SQL Server 2025 zwar nicht umgebaut – Per-Core und Server+CAL bleiben –, aber die Editionen wurden kräftig aufgebohrt und die Cloud-Anbindung über Azure Arc wird ab Juni 2026 ernster genommen. Wer das ignoriert, zahlt entweder zu viel Enterprise oder fliegt aus der Compliance.

Die drei Botschaften für die Geschäftsführung: Erstens, die Standard Edition kann jetzt deutlich mehr (32 Kerne, 256 GB RAM, Resource Governor) – das ist eine handfeste Chance, teure Enterprise-Kerne einzusparen. Zweitens, Azure Arc bringt verbrauchsbasierte Abrechnung (Pay-as-you-go), aber mit einer harten 30-Tage-Online-Regel. Drittens, ohne aktuelle Bestandsaufnahme deiner Kerne, Editionen und Software-Assurance-Stände triffst du jede dieser Entscheidungen blind. Genau hier setzen wir an.

Worum geht es im Detail?

Fangen wir mit der beruhigenden Nachricht an: Das Grundgerüst der Lizenzierung ist stabil geblieben. Es gibt weiterhin zwei Wege, SQL Server zu lizenzieren. Das Core-based-Modell (Per-Core) zahlt pro physischem oder virtuellem Kern, mit einem Minimum von vier Kernen pro Prozessor, verkauft in 2er-Packs. Das Server+CAL-Modell zahlt eine Serverlizenz plus eine Zugriffslizenz (Client Access License) je Nutzer oder Gerät. Wichtig und unverändert: Server+CAL gibt es nur für die Standard Edition. Die Enterprise Edition bekommst du ausschließlich per Core. Wer also Enterprise braucht, kommt um die Kern-Zählerei nicht herum.

Jetzt das, was sich tatsächlich geändert hat – und das ist mehr, als die Überschrift „keine Modelländerung“ vermuten lässt. Mit SQL Server 2025 (seit November 2025 allgemein verfügbar) hat Microsoft die Standard Edition deutlich aufgewertet. Die maximale Compute-Kapazität steigt von 24 auf 32 Kerne, der nutzbare Arbeitsspeicher verdoppelt sich von 128 GB auf 256 GB. Obendrauf wandert der Resource Governor, früher ein reines Enterprise-Feature, in die Standard Edition. Auch der Power BI Report Server darf jetzt mit Standard-Lizenzen betrieben werden – und zwar ohne die früher zwingende Software Assurance. Die Express Edition darf ihre Datenbanken von 10 GB auf 50 GB wachsen lassen. Und die Web Edition? Die ist mit 2025 schlicht gestrichen.

Abb. 1: Was die Standard Edition mit SQL Server 2025 dazugewonnen hat.

Warum ist das relevant fürs Portemonnaie? Weil viele Unternehmen in der Vergangenheit nur deshalb zur teuren Enterprise Edition gegriffen haben, weil ihnen bei Standard die Kerne, der RAM oder ein einzelnes Feature wie der Resource Governor ausgingen. Genau diese Gründe fallen jetzt teilweise weg. Ein Enterprise-Kern kostet grob das Vierfache eines Standard-Kerns – diese Spreizung spiegelt Microsoft sogar in den „normalized cores“ der Azure-Abrechnung wider, wo ein Enterprise-Kern als vier Einheiten zählt. Jeder Workload, den du sauber von Enterprise auf Standard zurückstufen kannst, ist deshalb ein echter Hebel.

Der zweite große Block ist Azure Arc. Damit kannst du deine On-Premises- und Multi-Cloud-SQL-Server an Azure anbinden und zentral verwalten. Für die Lizenzierung gibt es dabei drei Typen, und die musst du verstehen: „Paid“ heißt, du bringst deine eigene Lizenz mit aktiver Software Assurance oder Subscription mit – dann sind die Arc-Zusatzfeatures kostenlos. „PAYG“ (Pay-as-you-go) bedeutet stündliche Abrechnung pro Kern direkt über Azure, ganz ohne Vorabkauf. „LicenseOnly“ ist die Variante für perpetuelle Lizenzen ohne SA – günstig im Einkauf, aber ohne die schönen Vorteile wie kostenloses Versions-Upgrade, HADR-Failover oder Unlimited Virtualization.

Ein Wort zur Virtualisierung, weil hier die richtig großen Beträge liegen. Wer Enterprise per Core lizenziert und Software Assurance hält, bekommt das Recht auf Unlimited Virtualization: Du lizenzierst die physischen Kerne des Hosts und darfst darauf beliebig viele VMs mit beliebig vielen SQL-Server-Instanzen betreiben. Über Azure Arc wird das sauber als eigene Lizenzressource abgebildet, mit einer Mindestgröße von 16 physischen Kernen. Für dicht gepackte Virtualisierungshosts ist das fast immer günstiger als jede VM einzeln nach v-Cores zu lizenzieren. Aber Achtung: Auf den von Microsoft gelisteten Cloud-Anbietern gilt dieser Vorteil nicht – dort musst du pro virtuellem Kern zahlen.

Abb. 2: Der Entscheidungspfad von der Edition bis zum Azure-Arc-Abrechnungstyp.

Und hier kommt der Termin, den du dir rot anstreichen solltest: Ab Juni 2026 wird durchgesetzt, dass sich Arc-verbundene Server mindestens einmal alle 30 Tage bei Azure melden. Bei Pay-as-you-go ist das sogar existenziell – bleibt eine Maschine länger als 30 Tage offline, läuft das Abonnement aus, und du bist formal nicht mehr berechtigt, die Software zu nutzen. Kurze Verbindungsabbrüche verzeiht das System, ein vergessener Server im Keller ohne Internet wird zum Compliance-Risiko.

Was sind Chancen? Was sind Risiken?

Die größte Chance ist offensichtlich die Edition-Downgrade-Story. Wenn du heute Enterprise einsetzt, nur weil ein Server 28 Kerne hat oder 180 GB RAM braucht, dann war das gestern eine Enterprise-Pflicht und ist morgen vielleicht ein Standard-Kandidat. Wir haben bei einem mittelständischen Maschinenbauer genau das erlebt: drei Datenbankserver liefen auf Enterprise, weil jemand vor Jahren „auf Nummer sicher“ gehen wollte. Bei der Nachmessung brauchte exakt einer davon wirklich Enterprise (wegen Online-Index-Operationen rund um die Uhr). Die anderen zwei? Standard reicht locker. Das ist kein Rundungsfehler im Budget.

Chance Nummer zwei ist Flexibilität durch PAYG. Für saisonale oder schwankende Workloads – Jahresabschluss, Kampagnen, Testumgebungen – kannst du Kapazität stundenweise zahlen, statt dauerhaft Kerne zu kaufen, die elf Monate im Jahr Däumchen drehen. Dritte Chance: Wer Software Assurance hält, bekommt über Arc kostenlose passive Failover-Instanzen, Unlimited Virtualization mit Enterprise und den 180-Tage-Dual-Use-Vorteil sauber gemanagt und automatisch erkannt.

Vierte Chance, oft übersehen: Extended Security Updates. Läuft eine ältere SQL-Server-Version aus dem Support, kannst du die Sicherheitsupdates über Azure Arc als Subscription beziehen – flexibler und häufig günstiger als der klassische ESU-Einkauf in großen Blöcken. Gerade für Altlasten, die du nicht von heute auf morgen migrieren kannst, ist das ein eleganter Weg, compliant und gepatcht zu bleiben, ohne in eine Hauruck-Migration getrieben zu werden. Voraussetzung ist auch hier wieder eine aktive Anbindung an Azure.

Jetzt die Risiken, denn die gibt es reichlich. Erstes Risiko: blinde Verlängerung. Wer sein Enterprise Agreement oder seine Lizenzen einfach „wie gehabt“ verlängert, konserviert Überlizenzierung, die mit SQL 2025 vermeidbar wäre. Zweites Risiko: die 30-Tage-Falle bei PAYG. Offline-Server, abgeschottete Produktionsnetze oder schlicht vergessene Maschinen können dir die Lizenzdeckung wegziehen. Drittes Risiko: das Server+CAL-vs-Per-Core-Missverständnis. Server+CAL lohnt nur bei überschaubaren Nutzerzahlen; jenseits von grob 130 Anwendern wird Per-Core meist günstiger, weil die CAL-Kosten linear mitwachsen, die Kernlizenz aber gedeckelt ist.

Abb. 3: Die relevanten Zeitpunkte rund um SQL Server 2025 und Azure Arc.

Viertes, gern unterschätztes Risiko: die Web Edition ist tot. Wenn du Webhoster bist oder über einen Hoster Web-Edition-Lizenzen genutzt hast, gibt es das ab SQL Server 2025 nicht mehr neu – nur noch bis SQL Server 2022 über Hosting-Programme. Wer hier nicht rechtzeitig umplant, steht bei der nächsten Version ohne passendes SKU da. Und fünftes Risiko, das Klassiker-Eigentor: Mischst du auf einem physischen Host ohne VMs mehrere Instanzen, wird der gesamte Host nach der höchsten installierten Edition abgerechnet. Eine einzige Enterprise-Instanz „infiziert“ also die Lizenzkosten des ganzen Blechs.

Was müssen wir jetzt schon vorbereiten?

Schritt eins, und das ist nicht verhandelbar: eine ehrliche Bestandsaufnahme. Du brauchst eine Liste aller SQL-Server-Instanzen mit Edition, Version, physischen und virtuellen Kernen, RAM-Bedarf, Lizenzmodell (Per-Core oder Server+CAL) und – ganz wichtig – dem Software-Assurance-Status. Ohne diese Tabelle ist jede Optimierungsdiskussion Kaffeesatzleserei. Praktischerweise liefert genau hier Azure Arc mit „SQL Server inventory“ und „Best practices assessment“ die Werkzeuge frei Haus, sobald die Server angebunden sind.

Schritt zwei: Pro Instanz die Frage stellen „Braucht das wirklich Enterprise?“. Geh die Enterprise-only-Gründe durch – Always-On mit mehreren sekundären Repliken, Online-Wartung rund um die Uhr, Tabellenpartitionierung im großen Stil, mehr als 32 Kerne oder mehr als 256 GB Bedarf. Trifft keiner dieser Punkte zu, ist die Instanz ein Standard-Kandidat. Dokumentiere die Begründung, denn das ist später dein Compliance-Nachweis und dein Verhandlungsargument.

Schritt drei: Konnektivität klären, bevor du auf PAYG oder Arc-Features setzt. Stelle sicher, dass jede Maschine, die verbrauchsbasiert abgerechnet werden soll, die 30-Tage-Check-in-Regel zuverlässig einhält. Für abgeschottete Netze ist PAYG schlicht die falsche Wahl – dort bleibst du besser bei klassischen Lizenzen mit aktiver SA. Plane diese Netz-Entscheidung früh, denn sie bestimmt das Abrechnungsmodell mit.

Schritt vier: Timing mit den Vertragszyklen abstimmen. Der ideale Moment für die Optimierung ist der Ablauf deines Enterprise Agreements oder der Software Assurance. Azure Arc erlaubt sogar, eine Per-Core-Lizenz vorab anzulegen und erst zum Stichtag zu aktivieren – so überbrückst du den Übergang ohne Doppelzahlung. Wer das clever staffelt, wechselt nahtlos von „alt bezahlt“ zu „neu optimiert“, ohne einen einzigen Tag doppelt zu lizenzieren.

Schritt fünf: Nicht-Produktivumgebungen sauber trennen. Entwicklung und Test darfst du kostenlos fahren – entweder über die Developer Edition (Funktionsumfang wie Enterprise, aber nicht produktiv nutzbar) oder über eine Azure-Dev/Test-Subscription, in der die SQL-Server-Meter auf null gesetzt sind. In der Praxis verbrennen Unternehmen hier viel Geld, weil produktive Lizenzen auf Test- und Schulungssystemen kleben. Eine klare Kennzeichnung „prod versus non-prod“ in deiner Inventarliste zahlt sich sofort aus.

Häufig gestellte Fragen

Hat Microsoft mit SQL Server 2025 die Lizenzpreise oder das Modell geändert?

Das Lizenzmodell selbst bleibt gleich: Per-Core für Enterprise und Standard, Server+CAL weiterhin nur für Standard. Geändert haben sich vor allem die Editions-Leistungsgrenzen und einige Feature-Zuordnungen, was indirekt deine Kostenrechnung beeinflusst.

Lohnt sich für unsere Umgebung Server+CAL oder Per-Core?

Als grobe Faustregel wird Server+CAL ab etwa 130 Nutzern teurer als Per-Core, weil die CAL-Kosten mit jedem Anwender mitwachsen. Bei wenigen, klar abgrenzbaren Nutzern ist Server+CAL oft günstiger, bei großen oder unbekannten Nutzerzahlen meist Per-Core.

Was passiert, wenn ein Pay-as-you-go-Server länger als 30 Tage offline ist?

Dann läuft das PAYG-Abonnement aus und du bist formal nicht mehr berechtigt, die Software über dieses Modell zu nutzen. Kurze, sporadische Verbindungsabbrüche sind unkritisch, aber dauerhaft offline betriebene Maschinen solltest du klassisch mit aktiver Software Assurance lizenzieren.

Können wir durch SQL Server 2025 von Enterprise auf Standard zurückwechseln?

Häufig ja, weil Standard nun bis zu 32 Kerne, 256 GB RAM und Features wie den Resource Governor abdeckt. Voraussetzung ist, dass kein verbliebenes Enterprise-only-Feature wirklich genutzt wird – das prüfst du am besten Instanz für Instanz und dokumentierst die Begründung.

Brauchen wir Software Assurance noch, wenn wir auf Azure Arc setzen?

Es kommt darauf an: Mit Software Assurance (Lizenztyp „Paid“) bekommst du Failover, Unlimited Virtualization und kostenlose Versions-Upgrades. Ohne SA bleibt nur „LicenseOnly“ mit eingeschränkten Vorteilen oder der Wechsel auf verbrauchsbasiertes PAYG.