Kurz gesagt
Oft ja, für einen Teil der Abfragen. Eine neuere Engine kann dieselben Abfragen mit weniger CPU ausführen, ohne dass Sie eine Zeile Code ändern. Garantiert ist das nicht: Andere Abfragen bekommen nach dem Upgrade einen anderen Plan, und der kann langsamer sein.
Ob Ihre Anwendung gewinnt, entscheidet ein Vergleich Ihrer eigenen Abfragen, nicht die Versionsnummer. Dieser Vergleich gelingt, wenn Sie die drei Dinge, die ein Upgrade ändert, nacheinander umstellen: erst die Engine, dann den Kompatibilitätsgrad, dann einzelne neue Features.
Ein Teil der wirksamsten Optimierungen hängt zudem nicht an der Version, sondern an der Enterprise Edition.
Ist es nach dem Upgrade schon langsamer geworden, liegt die Ursache meist bei geänderten Plänen. Query Store zeigt sie, wenn er vorher schon mitgeschrieben hat.
Ein Upgrade ändert drei Dinge, nicht eins
Wer „Upgrade“ sagt, meint meist die neue Version. Für die Performance zählen drei getrennte Hebel, die zu unterschiedlichen Zeitpunkten wirken:
- Die Engine. Neue Version, neuer Build. Sie wirkt sofort, sobald die Datenbank auf dem neuen Server läuft: Speicherverwaltung, Ausführung, viele Optimierungen.
- Der Kompatibilitätsgrad (compatibility level, kurz CL) der Datenbank. Er legt fest, nach welchen Regeln der Optimizer Pläne baut. Eine wiederhergestellte Datenbank behält ihren bisherigen Grad, solange er nicht unter dem Minimum der neuen Version liegt; bei SQL Server 2025 ist das 100. Er ändert sich erst, wenn jemand ihn anhebt.
- Einzelne neue Features. Viele lassen sich je Datenbank ein- und ausschalten. Etliche wirken nur ab einem bestimmten Kompatibilitätsgrad, einige nur in der Enterprise Edition.
Stellen Sie alle drei auf einmal um, sehen Sie danach nur die Summe. Ob eine Abfrage wegen der Engine schneller, wegen des neuen Grads langsamer oder wegen eines Features anders geworden ist, lässt sich dann nicht mehr trennen. Deshalb gehen wir in Stufen vor, und deshalb ist das Bild dieses Beitrags eine Treppe: vom heutigen Stand aus drei Stufen hinauf.
- Stufe 0heuteändert: nichts
- Stufe 1neue Engineändert: Version und Build
- Stufe 2neuer Gradändert: Optimizer-Regeln
- Stufe 3Featuresändert: je ein Feature
| Stufe | Was sich ändert | Was gleich bleibt |
|---|---|---|
| 0 · heute | nichts | alte Version, alter Grad |
| 1 · neue Engine | Version und Build | Kompatibilitätsgrad, Einstellungen der Datenbank |
| 2 · neuer Grad | Optimizer-Regeln | Engine aus Stufe 1 |
| 3 · Features | je ein Feature | alles andere |
Was beim Wiederherstellen tatsächlich passiert. Im Labor haben wir eine Datenbank von SQL Server 2022 gesichert und auf SQL Server 2025 wiederhergestellt. Absichtlich waren zwei Einstellungen anders als üblich gesetzt. Ergebnis: Kompatibilitätsgrad 160, Datenbank-MAXDOP 2 und das ausgeschaltete Parameter Sensitive Plan Optimization blieben erhalten, Daten und Prüfsummen identisch. Die neuen Schalter für Features aus SQL Server 2025 standen dagegen sofort auf ON, darunter OPTIONAL_PARAMETER_OPTIMIZATION. Wirksam war das Feature trotzdem nicht, denn es setzt Kompatibilitätsgrad 170 voraus.
Daraus folgt: Eine neu angelegte Testdatenbank ist kein Upgrade-Test. Sie bekommt die Voreinstellungen der neuen Version, Ihre Produktionsdatenbank bringt ihre alten mit.
Spielt auf Stufe 1 und 2
Versuch 1: gleicher Code, neue Engine, dann neuer Grad
Erwartung Wenn die Engine allein etwas bringt, muss es bei unverändertem Code und unverändertem Kompatibilitätsgrad sichtbar werden.
Änderung Dieselben gespeicherten Prozeduren, dieselben Daten (500.000 Zeilen mit ungleich verteilten und korrelierten Werten), dieselben Statistiken. Einmal auf SQL Server 2022, einmal auf SQL Server 2025, beide als Enterprise Developer Edition mit Kompatibilitätsgrad 160. Danach dasselbe mit Grad 170.
Beobachtung Durchsatz in Ausführungen pro Sekunde, CPU in Millisekunden je Auswertung.
| Abfrageart | 2022, Grad 160 | 2025, Grad 160 | 2025, Grad 170 |
|---|---|---|---|
| Auswertung mit Join und Aggregation, 1 Sitzung | 32,07 | 38,60 | 38,22 |
| CPU je Auswertung | 107–109 ms | 87–89 ms | – |
| Gemischte Last, 8 Sitzungen (längere Kontrolle) | 492,00 | 618,83 | – |
| Kurze Punktabfrage, 1 Sitzung | 1.478,85 | 1.514,01 | 1.494,67 |
Die Auswertung braucht auf SQL Server 2025 knapp ein Fünftel weniger CPU. Die gemischte Last schafft 25,8 Prozent mehr Ausführungen pro Sekunde. Beides bei unverändertem Grad 160. Der Wechsel auf Grad 170 brachte für diese Auswertung nichts zusätzlich. Bei den kurzen Punktabfragen war unser Lastgenerator der Engpass; daraus lässt sich weder ein Gewinn noch ein Verlust ablesen.
Folgerung Die Engine kann schon auf Stufe 1 einen deutlichen Vorteil bringen, ohne dass Sie den Grad anfassen. Das ist ein Grund, die Stufen zu trennen: Wer gleich auf Grad 170 geht, schreibt den Gewinn dem neuen Grad zu und sucht bei einem Verlust an der falschen Stelle.
Die 25,8 Prozent gelten für diese Last. Sie sind keine Quote, die Sie auf Ihre Anwendung übertragen können. Ihre Abfragen, Daten und Server entscheiden.
Spielt auf Stufe 3
Versuch 2: ein Feature steht auf ON
Mit jeder Version kommen Features, die Pläne verbessern sollen. Für SQL Server 2025 sind das zum Beispiel Optional Parameter Plan Optimization (OPPO) und CE Feedback for Expressions. Dass ein Schalter auf ON steht, sagt aber noch nichts. Wir prüfen deshalb vier Dinge nacheinander:
- 01
Verfügbar
Gibt es das Feature in Ihrer Edition und bei Ihrem Kompatibilitätsgrad?
- 02
Geeignet
Passt Ihre Abfrage zu dem Muster, für das das Feature gebaut ist?
- 03
Genutzt
Zeigt der tatsächliche Plan, dass sie gegriffen hat?
- 04
Nützlich
Ist die Abfrage dadurch messbar schneller oder stabiler geworden?
Erwartung Bei einer Suchmaske mit optionalem Filter (WHERE @Kunde IS NULL OR Kunde = @Kunde) sollte OPPO getrennte Pläne für „Filter leer“ und „Filter gesetzt“ bilden.
Änderung Dieselbe Prozedur auf SQL Server 2025 mit Grad 170, OPPO ein und aus.
Beobachtung Mit OPPO enthielt der Plan einen Verteiler mit zwei Varianten: eine für NULL, eine für alle anderen Werte. Bei zwei optionalen Filtern waren es vier Varianten. Das Feature greift also. Innerhalb der Variante „Filter gesetzt“ teilen sich aber seltene und häufige Werte weiterhin einen Plan. In unserem gemischten Lauf brauchten seltene Werte zeitweise etwa eine Millisekunde, häufige Werte mit demselben Plan etwa 500 Millisekunden.
Folgerung OPPO löst das Problem „leer oder gesetzt“. Ungleich verteilte Werte innerhalb des gesetzten Filters löst es nicht. Dafür wäre Parameter Sensitive Plan Optimization gedacht. In unseren Labortests hat dieses Feature in keiner der geprüften Formen eine Variante gebildet; die Telemetrie meldete, dass die Schiefe der Daten nicht ausreichte. Das ist kein Beleg gegen das Feature, aber ein Beleg dafür, dass ON allein nichts beweist.
Ähnlich bei CE Feedback for Expressions. Für zwei voneinander abhängige Filter schätzte der Optimizer ohne das Feature 500 Zeilen, tatsächlich kamen 5.000. Mit dem Feature stimmte die Schätzung, auch für andere Abfragen mit demselben Filterausdruck. Bei vier voneinander abhängigen Spalten blieb die Schätzung dagegen unverändert falsch, obwohl der Plan einen Feedback-Hinweis trug.
Welche dieser Features Ihnen überhaupt zur Verfügung stehen, hängt auch an der Edition. Darum geht es im nächsten Abschnitt.
Neue Version oder Enterprise Edition?
Für SQL Server 2016 warb Microsoft mit dem Satz „It Just Runs Faster“. Gemeint war die neue Version: Verbesserungen in der Engine, die laut Microsoft in jeder Edition wirken. Das ist Stufe 1 unserer Treppe.
Eine zweite Quelle für Tempo hat mit der Version wenig zu tun: die Edition. Eine Zahl, um wie viel Enterprise schneller ist, nennt Microsoft nicht. Die Editionsübersicht zeigt aber, wo die Unterschiede liegen:
| Bereich | Standard Edition | Enterprise Edition |
|---|---|---|
| Prozessorkerne | 2022: höchstens 24, 2025: höchstens 32 | so viele, wie das Betriebssystem bereitstellt |
| Arbeitsspeicher für den Buffer Pool | 2022: 128 GB, 2025: 256 GB | ohne Editionsgrenze |
| Batch Mode | nur für Columnstore, mit höchstens zwei parallelen Threads | auch für normale Tabellen, ohne diese Grenze |
| Lernende Optimierungen | PSP, OPPO, Optimized Plan Forcing | zusätzlich Adaptive Joins, Memory Grant Feedback, CE- und DOP-Feedback, automatische Plankorrektur |
| Große Tabellen lesen | übliches Vorauslesen | gemeinsam genutzte Scans und mehr Vorauslesen |
Was das für Versuch 1 bedeutet. Beide Server in Versuch 1 liefen als Enterprise Developer Edition. Die Auswertung nutzte auf SQL Server 2022 wie auf 2025 Batch Mode für normale Tabellen, ein Enterprise-Feature. Auf der Standard Developer Edition lief dieselbe Auswertung bei gleicher Hardware im Row Mode. Die 25,8 Prozent sind also ein Vergleich innerhalb von Enterprise. Wie groß der Abstand zwischen Standard und Enterprise für diese Auswertung ist, haben wir nicht belastbar gemessen.
Folgerung. Mit einer neuen Version bekommen Sie in Standard die Verbesserungen der Engine, mit SQL Server 2025 auch höhere Grenzen für Kerne und Speicher. Die Enterprise-Features bekommen Sie nicht. Ein Wechsel der Edition ist deshalb eine eigene Änderung neben der Treppe: Er bestimmt, welche Features auf Stufe 3 überhaupt zur Wahl stehen, und gehört genauso getrennt gemessen. Ohne Lizenzkauf geht das mit den beiden Developer Editionen, die es seit SQL Server 2025 für Enterprise und für Standard gibt.
Spielt auf Stufe 3
Versuch 3: weniger Sperren, anderes Ergebnis
Nicht jede Änderung betrifft die Geschwindigkeit. Manche ändern das Verhalten.
Erwartung Optimized Locking in SQL Server 2025 soll weniger Sperren halten und Blockierungen verringern.
Änderung 1.000 geänderte Zeilen in einer offenen Transaktion, Optimized Locking aus und ein. Danach ein zeitlich genau gesteuerter Ablauf zweier konkurrierender Updates, einmal ohne, einmal mit Optimized Locking und Read Committed Snapshot Isolation (RCSI).
Beobachtung Statt im Median 1.060 gehaltenen Sperren waren es drei. Im konkurrierenden Ablauf endete die Zeile ohne die neue Sperrlogik in allen fünf Wiederholungen mit dem Wert 3, mit Optimized Locking und RCSI in allen fünf Wiederholungen mit dem Wert 2. Microsoft beschreibt genau dieses Szenario in der Dokumentation.
Folgerung Weniger Sperren heißt nicht: gleiches Ergebnis, nur schneller. Wenn sich Ihre Anwendung darauf verlässt, in welcher Reihenfolge konkurrierende Änderungen wirken, gehört das vor dem Einschalten auf den Prüfstand; Microsoft empfiehlt für solche Fälle eine strengere Isolationsstufe. Kein Fehler der Engine, aber eine Änderung, die Ihre Fachlogik betreffen kann. Optimized Locking ist in SQL Server 2025 standardmäßig aus, wird je Datenbank eingeschaltet und setzt Accelerated Database Recovery voraus.
Warum Vorher-Nachher-Vergleiche oft täuschen
Drei Fallen haben wir im Labor selbst erlebt.
Der erste Aufruf entscheidet über den Plan. Eine Prozedur wird für die Werte kompiliert, mit denen sie zuerst aufgerufen wird, und behält diesen Plan. In einer Suchprozedur, die den optionalen Filter von Hand mit IF/ELSE in zwei Zweige aufteilt, brauchte ein häufiger Wert 690 bis 743 Millisekunden, wenn zuerst mit NULL aufgerufen worden war, und 17 bis 20 Millisekunden, wenn zuerst ein häufiger Wert kam. Läuft der Test auf der alten Version mit einem anderen ersten Aufruf als auf der neuen, vergleichen Sie zwei Pläne, nicht zwei Versionen. Mehr dazu im Beitrag Eine Abfrage, viele Pläne.
Gelernte Zustände gehen verloren. Features wie CE Feedback lernen aus vorherigen Ausführungen. Nach einem Neustart fanden wir von 17 gelernten Einträgen unmittelbar noch vier; der Rest baute sich erst mit weiteren Ausführungen wieder auf. Microsoft beschreibt die Speicherung als periodisch und möglicherweise verlustbehaftet. Messen Sie deshalb nicht nur den ersten Tag nach dem Upgrade, und trennen Sie Anlauf und stabilen Betrieb.
Das Upgrade kommt selten allein. Oft wechseln mit der Version auch Server, virtuelle Maschine, Kernzahl, Speicher oder Speichersystem. Jede dieser Änderungen kann Pläne und Laufzeiten verschieben. Halten Sie fest, was alles anders ist, bevor Sie es der Version zuschreiben.
Nach dem Upgrade langsamer? So grenzen Sie ein
- Feststellen, was sich geändert hat. Version und Build, Kompatibilitätsgrad, Einstellungen je Datenbank, Edition, Hardware. Die beiden Abfragen unten lesen die wichtigsten Datenbankwerte nur aus; wir haben sie auf SQL Server 2017 bis 2025 geprüft.
- Die langsamen Abfragen finden. Query Store zeigt unter „Regressed Queries“, welche Abfragen seit einem Zeitpunkt mehr Zeit brauchen und ob ihr Plan gewechselt hat. Dafür muss er schon vor dem Upgrade mitgeschrieben haben. Neue Datenbanken ab SQL Server 2022 haben ihn standardmäßig an; Datenbanken, die per Wiederherstellung oder Upgrade kommen, behalten ihre bisherige Einstellung.
- Pläne vergleichen. Alter und neuer Plan nebeneinander zeigen, wo sich Schätzung und Zugriffsweg unterscheiden. Ein Werkzeug dafür stellen wir im Beitrag sp_BlitzPlanCompare vor.
- Gezielt zurückholen, nicht pauschal. Für einzelne Abfragen lässt sich der frühere Plan über Query Store erzwingen; in der Enterprise Edition kann das die automatische Plankorrektur übernehmen. Ab SQL Server 2022 können Query Store Hints einer Abfrage in jeder Edition zum Beispiel den alten Cardinality Estimator oder einen älteren Grad mitgeben, ohne den Code zu ändern. Den Kompatibilitätsgrad der ganzen Datenbank zurückzusetzen geht ohne Neuinstallation und ist ein gültiger Notausgang. Er nimmt aber auch die Vorteile der neuen Regeln für alle anderen Abfragen weg.
- Die Ursache klären. Ein erzwungener Plan ist eine Überbrückung. Warum der neue Plan schlechter ist, klärt der Ratgeber-Weg SQL Server ist mal schnell und mal langsam.
Nur lesend – ändert nichts an Ihrer Datenbank
-- Nur lesend: Kompatibilitätsgrad und Query Store je Datenbank
SELECT name,
compatibility_level,
is_query_store_on,
is_read_committed_snapshot_on
FROM sys.databases
ORDER BY name;
-- Nur lesend: ausgewählte Einstellungen der aktuellen Datenbank
-- (Zeilen fehlen, wenn die Version die Einstellung nicht kennt)
SELECT name, value
FROM sys.database_scoped_configurations
WHERE name IN (N'MAXDOP', N'LEGACY_CARDINALITY_ESTIMATION',
N'PARAMETER_SENSITIVE_PLAN_OPTIMIZATION',
N'OPTIONAL_PARAMETER_OPTIMIZATION',
N'CE_FEEDBACK', N'DOP_FEEDBACK',
N'CE_FEEDBACK_FOR_EXPRESSIONS',
N'OPTIMIZED_SP_EXECUTESQL');So machen wir das Für genau diesen Vorher-Nachher-Vergleich nutzen unsere Engineers PSG QX. Es wertet den Query Store aus, den Ihre Datenbank vor und nach dem Upgrade geschrieben hat, und sortiert die Abfragen: neu hinzugekommen, mit schlechterem Plan, häufiger aufgerufen oder je Aufruf teurer. Jeden Vergleich stuft QX als vergleichbar, eingeschränkt oder nicht möglich ein, mit Grund, statt eine Verbesserung oder einen Rückschritt zu behaupten. Voraussetzung ist auch hier ein Query Store, der schon vor dem Upgrade mitgeschrieben hat. Mehr zu PSG QX
Vor dem Upgrade: das Vorgehen in sieben Schritten
- 01
Query Store auf der alten Version einschalten und mindestens einige Wochen normalen Betrieb sammeln, einschließlich Monatsabschluss oder anderer Spitzen. Das ist Ihre Vergleichsbasis.
- 02
Die wichtigsten Abfragefamilien benennen: die zehn bis zwanzig Abfragen, die am meisten Zeit oder CPU verbrauchen oder fachlich kritisch sind, jeweils mit typischen und extremen Parametern.
- 03
Eine echte Kopie wiederherstellen, keine neu angelegte Datenbank. Prüfen, welche Einstellungen übernommen wurden.
- 04
Stufe 1: neue Version, alter Grad. Dieselben Abfragen mit festgelegtem ersten Aufruf vergleichen.
- 05
Stufe 2: Grad anheben, erneut vergleichen. Abfragen, die langsamer werden, einzeln untersuchen.
- 06
Stufe 3: neue Features einzeln bewerten, mit den vier Prüffragen. Features, die Verhalten ändern, wie Optimized Locking, gegen die Fachlogik prüfen.
- 07
Nach dem Umstieg beobachten und vorher festlegen, ab wann Sie zurückgehen: auf einen erzwungenen Plan, einen Hint oder den alten Grad.
Microsoft beschreibt denselben Grundablauf: Upgrade ohne Änderung des Grads, Query Store über einen Geschäftszyklus, dann Grad anheben und Rückschritte über Query Store abfangen.
Häufige Fragen
Ist garantiert, dass eine neue Version schneller ist?
Nein. Microsoft verbessert mit jeder Version die Engine, verspricht aber nicht, dass jede Abfrage davon profitiert. Ein typischer Grund für Rückschritte sind die neuen Regeln des Optimizers, die mit dem höheren Kompatibilitätsgrad kommen: Die Schätzungen ändern sich, und mit ihnen die Pläne. Deshalb sieht auch Microsofts eigener Ablauf einen Rückweg für einzelne Abfragen über Query Store vor. Sicher ist nur, was Sie mit Ihren eigenen Abfragen gemessen haben.
Wird SQL Server 2025 schneller sein als unser SQL Server 2019?
Für manche Abfragen sehr wahrscheinlich, für andere nicht. Eine allgemeine Prozentzahl gibt es nicht. Belastbar wird die Antwort erst mit Ihren eigenen Abfragen auf Stufe 1 und 2.
Müssen wir den Kompatibilitätsgrad sofort anheben?
Nein. Die Datenbank läuft auf der neuen Version mit dem alten Grad weiter, und die Engine bringt ihre Vorteile trotzdem mit. Viele neue Features brauchen allerdings den neuen Grad. Heben Sie ihn an, wenn Sie Stufe 2 geprüft haben.
Sollten wir einfach alle neuen Features einschalten und hoffen, dass es hilft?
Nein, und darum geht es meist auch gar nicht. Die meisten Features sind ohnehin an, sobald der passende Kompatibilitätsgrad gesetzt ist. Die eigentliche Frage ist, was Sie tun, wenn eines davon einer Abfrage schadet. Das kommt vor: Beim Scalar UDF Inlining hat Microsoft über viele Cumulative Updates Fehler behoben und Ausschlüsse ergänzt, bei PSP Fehler im Zusammenspiel mit Query Store dokumentiert und behoben. Spielen Sie deshalb aktuelle Cumulative Updates ein, bevor Sie Features bewerten. Erfahrene Praktiker in der Community raten übereinstimmend zum selben Weg wie Microsoft: erst Query Store und eine Vergleichsbasis, dann den Grad anheben, und wenn eine Abfrage leidet, gezielt für diese Abfrage eingreifen. Dafür gibt es je Feature eine Einstellung pro Datenbank und meist einen Hint, den Sie über Query Store ohne Codeänderung setzen können. Ein Feature für die ganze Datenbank abzuschalten, ist selten nötig.
Lohnt sich die Enterprise Edition für die Performance?
Für manche Lasten deutlich, für andere kaum. Batch Mode für normale Tabellen, die Feedback-Features, Adaptive Joins und die automatische Plankorrektur gibt es laut Microsoft nur dort, dazu fallen die Grenzen für Kerne und Speicher weg. Ob Ihre Abfragen davon profitieren, zeigt ein Test mit den beiden Developer Editionen. Für Edition und Kernzahl gilt: erst messen, dann lizenzieren. Wir verkaufen keine Lizenzen.
Unser Hersteller schreibt einen bestimmten Kompatibilitätsgrad vor. Lohnt sich das Upgrade dann?
Ja, möglich. Die Engine wirkt auch bei vorgegebenem Grad, das zeigt Versuch 1. Features, die einen höheren Grad brauchen, bleiben dann außen vor.
Wie lange dauert ein belastbarer Vergleich?
Das hängt von der Zahl der Abfragefamilien ab. Der größte Teil der Arbeit ist die Vorbereitung: Baseline, Kopie, festgelegte Parameter. Die Messung selbst ist dann überschaubar.
Methode und Grenzen
Alle Messwerte stammen aus unserer Laborreihe vom 12.10.2026: SQL Server 2022 CU27 und SQL Server 2025 CU9, für alle Versuche als Enterprise Developer, für den Editionsvergleich zusätzlich SQL Server 2025 als Standard Developer in Containern mit je vier CPUs und 4 GiB maximalem SQL-Speicher, synthetische Daten mit 500.000 Zeilen, gleiche Statistiken. Jede Leistungsvariante lief in mindestens fünf Messfenstern nach einer Aufwärmphase. Varianten, deren Fenster mehr als zehn Prozent voneinander abwichen, haben wir nicht gewertet oder mit längeren Fenstern wiederholt. Die Aufzeichnung der Einzelzeiten verlängerte die Läufe in unseren Kalibrierungen um höchstens 3,59 Prozent. Die beiden Lese-Abfragen haben wir am 23.10.2026 auf SQL Server 2017, 2019, 2022 und 2025 ausgeführt.
Das ist ein Labor, kein Kundenbetrieb. Die Werte zeigen, welche Effekte auftreten können und wie man sie trennt. Sie sind keine Prognose für Ihre Anwendung. Parameter Sensitive Plan Optimization, Adaptive Joins und DOP Feedback haben in unseren Tests nicht gegriffen; positive Beispiele dafür stehen noch aus.
Quellen von Microsoft (abgerufen am 23.10.2026): Kompatibilitätsgrad · Query Store beim Upgrade · Intelligent Query Processing · Editionen von SQL Server 2025 · Optimized Locking · Query Store Hints · Neu in SQL Server 2025: Änderungen an den Editionen · Seiten lesen: Vorauslesen und Advanced Scanning · „SQL 2016 – It Just Runs Faster“ (Archiv) · Kompatibilitätsgrad ändern und Query Store nutzen · Scalar UDF Inlining · Parameter Sensitive Plan Optimization · Neu in SQL Server 2022: Query Store
Wir helfen bei der Entscheidung
Im Upgrade- und Lizenz-Check vergleichen wir Ihre wichtigsten Abfragen in den drei Stufen auf Ihren Daten und nennen Gewinner, Verlierer und offene Risiken. Edition und Kernzahl ordnen wir dabei aus Ihrer Sicht ein. Läuft das Upgrade schon, werten wir mit PSG QX den Query Store von vorher und nachher aus.