Auf einen Blick

Azure SQL ist nicht einfach „SQL Server in der Cloud, aber im Browser klickbar“. Die Plattform hat eigene Spielregeln, die du als Entwickler kennen musst, sonst tappst du in jede Falle, die schon tausend andere vor dir gefunden haben. Die Plattform ist verzeihend, was Architektur angeht — aber gnadenlos, was Latenz, Connection-Handling und Auth-Designs angeht.

Dieses Whitepaper ist für Entwickler, die mit Azure SQL bauen oder bauen werden. Egal ob Migration einer bestehenden .NET-Anwendung oder Greenfield-Projekt. Es geht nicht darum, welches Bereitstellungsmodell die richtige Investition ist — das ist Entscheider-Thema. Es geht darum, was du im Code anders machen musst, sobald die Datenbank nicht mehr 0,5 ms entfernt unter deinem Schreibtisch steht.

Sechs Themen, die jede Cloud-Datenbank-App betreffen:

• Connection-Strings, Pools und warum jedes Open() teuer ist
• Authentifizierung — und warum SQL Auth 2026 noch immer überall lebt, obwohl es eigentlich Müll ist
• Latenz: warum dein lokal flüssiger Code in Production ruckelt
• Schema-Migration im CI/CD — DACPAC, EF Core Migrations, oder Mix?
• Read Replicas, ApplicationIntent und die Falle der eventual consistency
• Lokale Entwicklung — was geht, was nur ähnlich, was gar nicht

Plus: Drei typische Fallen, die in Code-Reviews regelmäßig auftauchen, und drei Praxisbilder aus konkreten Projekten.

IN KÜRZE Microsoft.Data.SqlClient ist der aktuelle Provider — System.Data.SqlClient ist Legacy. Falls du noch das alte verwendest: jetzt wechseln. Connection Pooling ist nicht optional. Verbindungen kosten in der Cloud 200-500 ms im Aufbau. Wer pro Request öffnet, verliert. Transient Errors sind in der Cloud Normalfall. Ohne Retry-Logik fliegt deine App regelmäßig auseinander, ohne dass jemand verstehen kann, warum.

 

Welches Modell tut weh, welches nicht

Bevor wir in Code-Patterns einsteigen: Du solltest grob verstehen, in welchem der vier Azure-SQL-Modelle deine Anwendung läuft, denn das entscheidet, welche Features du nutzen kannst und welche du dir abschminken musst.

Vier Optionen: Azure VM (klassischer SQL Server in der Cloud), Managed Instance (managed mit fast vollem SQL-Server-Funktionsumfang), Azure SQL Database (single DB als Service) und Serverless (Azure SQL Database mit Auto-Scaling). Aus Architektur-Perspektive sind die im Entscheider-Whitepaper sauber durchdekliniert. Hier nur die Frage, die dich als Entwickler interessiert: Welche Features fallen weg, je weiter du nach rechts in Richtung „managed“ gehst?

Abbildung 1: Was funktioniert wo — die Features, die in Code-Reviews regelmäßig zur Diskussion stehen.

Was du im Hinterkopf haben musst

Linked Server gibt es praktisch nicht mehr

In Azure SQL Database und Serverless: gar nicht. In Managed Instance: nur eingeschränkt zwischen MI-Instanzen. Wer Cross-Database-Operationen über Linked Server gemacht hat (Klassiker: Reporting-Tabellen aus einer separaten DB ziehen), muss umbauen. Lösungsweg: External Tables, Elastic Query, oder im Anwendungs-Code mehrere Connections gegen mehrere DBs öffnen und in der App zusammenführen.

SQL Agent Jobs sterben mit Azure SQL Database

Wenn du Background-Jobs in der DB hast — Datenbereinigung, Aggregations-Berechnungen, Email-Versand — ist Azure SQL Database der falsche Ort. Bei Managed Instance gibt es SQL Agent weiterhin. Bei Azure SQL Database brauchst du Elastic Jobs (eigene Database mit Scheduling-Funktion), Azure Functions mit Timer-Trigger, oder Logic Apps.

Cross-Database-Joins sind in SQL Database eingeschränkt

Was bei Managed Instance und VM problemlos geht (`SELECT * FROM dbA.dbo.tab1 JOIN dbB.dbo.tab2 ON …`), funktioniert in Azure SQL Database nur über Elastic Query und mit Setup-Aufwand. Bei Microservices-Architekturen ist das oft kein Problem (wer Cross-DB-Joins macht, hat ohnehin eine zu enge Kopplung), bei migrierten Monolithen tut es weh.

CLR ist tot in den managed Modellen

Wer .NET-Assemblies in der Datenbank hatte — CLR-Funktionen, Aggregates, Types — kommt in Managed Instance noch über die Runde, in Azure SQL Database gar nicht mehr. Der Migrationspfad: CLR-Logik raus aus der DB, rein in die Anwendung oder in Azure Functions.

FileStream, FileTable: vergiss es

Wer Binärdaten direkt in der DB gespeichert hat (oft im Healthcare-Bereich oder bei Dokumentenmanagement-Systemen mit zwanghafter Transaktionalität): nur Azure VM kann das noch. In allen managed Modellen fällt das weg. Empfohlene Alternative: Azure Blob Storage mit URL-Referenz in der DB. Mehr Architekturarbeit, dafür Cloud-tauglich.

Provider-Wahl

Bevor du die erste Zeile Code schreibst: Bitte verwende `Microsoft.Data.SqlClient`, nicht das alte `System.Data.SqlClient`. Die alte Library wird zwar noch gewartet, kriegt aber keine neuen Features mehr. Die neue Library hat insbesondere Azure-AD-Authentifizierung deutlich besser eingebaut.

Aspekt	System.Data.SqlClient	Microsoft.Data.SqlClient
Status	Legacy, nur Bug-Fixes	Aktiv weiterentwickelt
Entra ID Integration	Mühsam, eigene Token-Logik nötig	Native, einfach
Always Encrypted mit Enclaves	Nicht unterstützt	Unterstützt
NuGet-Paket	System.Data.SqlClient	Microsoft.Data.SqlClient
EF Core ab 5.0	Wird nicht mehr verwendet	Standard-Provider

Tabelle 1: Die beiden SQL-Client-Libraries. Wenn du noch nicht migriert hast, ist das der erste Aufräum-Schritt.

PRAXIS Aus einem Code-Review eines mittelständischen ISVs: Anwendung hatte ein `using System.Data.SqlClient;` in 247 Dateien. Migration auf Microsoft.Data.SqlClient: ein globales Such-und-Ersetzen, dazu vier Connection-String-Parameter umbenennen (kleinere Inkompatibilitäten), ein Tag Aufwand. Ergebnis: Entra-ID-Auth funktionierte sofort ohne eigene Token-Logik. Ein Tag investiert, einen Workshop voll Frust gespart.

 

Connection — alles dreht sich darum

Wenn du nur eine Sache aus diesem Whitepaper mitnimmst, dann diese: In der Cloud sind Connections teuer. Sehr teuer. Eine frische SqlConnection zu öffnen — TLS-Handshake, Auth-Token holen, Gateway-Routing zur Datenbank, Session aufbauen — kostet zwischen 200 und 500 Millisekunden. Wenn deine Web-App das pro Request macht, hast du kein SQL-Performance-Problem mehr, sondern ein Connection-Performance-Problem. Und das siehst du in keinem Query-Plan.

Abbildung 2: Was zwischen `Open()` und der ersten Query passiert — und wo die Cloud anders reagiert als On-Premises.

Connection Pool — der wichtigste Trick

Der Connection Pool von ADO.NET hält offene Verbindungen für dich vor. Wenn du eine Verbindung schließt (`Dispose()` oder `using`-Block), wird sie nicht wirklich geschlossen, sondern in den Pool zurückgegeben. Beim nächsten Open() bekommst du dieselbe Verbindung wieder — ohne den teuren Aufbau. Das spart dir 90 Prozent der Latenz.

Drei Dinge, die du wissen musst:

• Pool-Identität wird über den Connection-String berechnet. Schon ein Leerzeichen Unterschied bedeutet zwei verschiedene Pools. Setz deinen Connection-String einmal global, nicht überall ad-hoc zusammen.
• Default Pool-Größe ist 100. Wenn deine App mehr parallele Connections braucht, läuft sie in `InvalidOperationException: Timeout expired`. Pool-Größe per Connection-String setzen: `Max Pool Size=200`.
• Wenn du `Pooling=false` setzt — was manche Cargo-Cult-Tutorials empfehlen — schießt du dir massiv in den Fuß. Mach das nie ohne sehr guten Grund.

ACHTUNG Klassische Pool-Killer: Connection-Strings dynamisch zusammensetzen mit jeweils anderer Reihenfolge oder Whitespace Application Name pro Request setzen (jede Variante = eigener Pool) Connections nicht disposen — Pool läuft voll, irgendwann Timeouts Lange offene Connections in async-Code — der Pool wartet, bis du fertig bist Diagnose: Sieh dir `sys.dm_exec_connections` in der DB an. Wenn da 50+ Connections von einem App-Service-Worker rumliegen, hast du irgendwo ein Disposal-Problem.

Transient Errors — das musst du einplanen

Cloud-Datenbanken werden gelegentlich umgezogen, repliziert, gewartet. Im Sekundenbereich. Aus deiner App-Sicht: eine Query schlägt fehl, die nächste funktioniert wieder. Das nennt sich Transient Error, und Microsoft hat eine handvoll bekannter Fehler-Codes dafür:

Code	Bedeutung
4060	Cannot open database — DB ist gerade in Übergang oder pausiert (Serverless)
40197	Service has encountered an error — Failover läuft, in 1-2 Sekunden klappt es wieder
40501	Service is currently busy — Resource Throttling, einfach zurücktreten und nochmal versuchen
40613	Database not currently available — meist Failover-Fenster
49918-49920	Cannot process request — Capacity-Throttling
11001	Network — DNS-Resolution-Fehler, oft transient
10928, 10929	Resource limits reached — Connection-Limit oder DTU-Limit

Tabelle 2: Die häufigsten Transient-Error-Codes. Vollständige Liste unter docs.microsoft.com — diese hier deckt 95 Prozent der Fälle ab.

Retry-Logik — wie du es richtig machst

Drei Wege:

1. Eingebaute Retry-Logik in Microsoft.Data.SqlClient

Ab Version 3 hast du den `ConfigurableRetryFactory`. Damit kannst du eine Default-Retry–Strategy für alle Connections konfigurieren. Funktioniert, ist aber etwas verborgen. Vorteil: keine Drittabhängigkeit.

2. EF Core mit EnableRetryOnFailure

Wenn du EF Core nutzt, ist das die einfachste Lösung:

`optionsBuilder.UseSqlServer(connectionString, opts => opts.EnableRetryOnFailure(maxRetryCount: 5, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null));`

EF Core kennt die meisten Transient-Error-Codes von Haus aus. Du kannst eigene über `errorNumbersToAdd` ergänzen. Eine Zeile Code, das Problem ist gelöst.

3. Polly für eigene Retry-Policies

Wenn du außerhalb von EF Core arbeitest oder mehr Kontrolle brauchst (Circuit Breaker, Bulkhead-Patterns), nutz Polly. Etwas mehr Setup, dafür einheitliche Retry-Logik für DB, HTTP-Calls und alles andere.

TIPP Faustregel: maximal 5 Retries, exponentielles Backoff, mit Jitter. Also nicht 1s, 2s, 4s, 8s, 16s — sondern 1s±200ms, 2s±400ms, etc. Das verhindert „Thundering Herd“: alle deine Worker, die gleichzeitig retryen und damit das Problem verschärfen.

 

Authentifizierung — bitte nicht mehr SQL Auth

Drei Wege, dich gegen Azure SQL zu authentifizieren. Einer davon ist 2026 immer noch in 70 Prozent der Code-Bases zu finden — und das ist genau der, den du nicht mehr nehmen solltest.

Abbildung 3: Die drei Auth-Optionen im Vergleich. Wenn du was Neues baust, geh den rechten Weg.

SQL Authentication — die Legacy-Variante

Username + Passwort im Connection-String. Kennt jeder, geht überall, lokal und in der Cloud. Drei Probleme:

• Passwort-Rotation ist ein Krampf. Du musst Connection-Strings in App-Settings, Key Vaults, CI-Pipelines synchronisieren. In 80 Prozent der Setups passiert das nie — das initiale Passwort ist auch das letzte.
• Audit auf User-Ebene gibt es nicht. Du siehst, dass „die App“ etwas gemacht hat, nicht welcher konkrete Mensch hinter der App-Identität sitzt.
• Compliance-mäßig ein Headache. DSGVO und NIS2 verlangen nachvollziehbare Identitäten. SQL-User mit shared Passwort erfüllen das nicht.

SQL Auth abschalten geht in Azure SQL übrigens komplett — du kannst die Datenbank so konfigurieren, dass nur noch Entra-ID-Auth funktioniert. Das ist das Ziel.

Microsoft Entra ID — der neue Standard

Authentifizierung gegen Microsoft Entra ID (früher Azure AD), entweder als interaktiver User-Login oder als Service Principal. Tokens werden automatisch geholt, an die SQL-Verbindung gehängt, vom Server geprüft.

Connection-String-Beispiel für einen Service Principal:

`Server=tcp:srv.database.windows.net;Database=mydb;Authentication=Active Directory Service Principal;User Id=app-id;Password=app-secret;`

Die Microsoft.Data.SqlClient-Library nimmt sich den Rest. Token-Refresh, Token-Cache, Renewal: macht die Library alles für dich. Du brauchst keine eigene Logik mehr.

Managed Identity — wenn dein Code in Azure läuft

Das ist der Goldstandard, aber nur möglich, wenn deine Anwendung in einer Azure-Compute-Ressource läuft (App Service, VM, Function App, AKS, Container Apps). Die Compute-Ressource bekommt eine eigene Identität, die du in der Datenbank als User registrierst. Connection-String:

`Server=tcp:srv.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;`

Kein Passwort, kein Secret, kein Key Vault-Zugriff. Die Identity wird von Azure verwaltet, automatisch rotiert, kann nicht aus dem Code geleakt werden. Das ist die Auth-Variante, die du wählen solltest, wenn dein Hosting es zulässt.

ACHTUNG Häufige Fehlannahme: „Mit Managed Identity läuft mein Code lokal nicht mehr.“ Stimmt nicht ganz. Lokal nutzt die Azure.Identity-Library als Fallback deine Visual-Studio-Anmeldung oder die Azure CLI. `DefaultAzureCredential` probiert eine Reihe von Wegen durch, bis einer funktioniert. Lokal: dein Login. In der Cloud: die Managed Identity. Du musst im Code nichts ändern.

Setup-Schritte für Entra-ID-Auth

Damit das Ganze funktioniert, sind drei Dinge nötig:

• Entra-ID-Admin auf der Azure-SQL-Instanz konfigurieren (im Azure Portal: SQL Server → Microsoft Entra → Set admin).
• App-Identity (Service Principal oder Managed Identity) als Datenbank-User anlegen — `CREATE USER [my-app] FROM EXTERNAL PROVIDER;`.
• Berechtigungen vergeben: `ALTER ROLE db_datareader ADD MEMBER [my-app];` und `db_datawriter` analog. Bitte nicht alle Apps als `db_owner` registrieren — das ist die SQL-Variante des Root-Logins.

PRAXIS Aus der Migrationspraxis: Mittelständischer ISV migriert von On-Premises zu Azure SQL. Bei der Gelegenheit wollen sie SQL Auth loswerden. Aufwand für die Umstellung: zwei Tage Code-Anpassung (Connection-Strings, ein paar Stellen mit `SqlCredential`), drei Tage Setup im Azure Portal und Coordination mit dem Identity-Team. Ergebnis: keine Passwörter mehr im Code, keine Rotations-Albträume mehr, NIS2-Audit lässt sich endlich beantworten. Der Code wurde zudem deutlich kleiner — die ganzen Workarounds für Passwort-Cycling konnten weg.

 

Performance — Latenz frisst alles

Die Cloud-Datenbank liegt nicht mehr unter deinem Schreibtisch, sondern in einem Microsoft-Rechenzentrum 200 Kilometer weiter. Selbst mit ExpressRoute oder Private Endpoint sind es typischerweise 2 bis 10 Millisekunden Round-Trip-Zeit pro Query. Das klingt nach nichts. Multipliziert mit 100 Queries pro Page-Render wird daraus eine Sekunde Wartezeit, die deine User unerklärlich finden.

Abbildung 4: Der gleiche fachliche Vorgang, einmal als chatty Anti-Pattern, einmal als batched Pattern. Faktor 100 in der wahrgenommenen Performance.

Das N+1-Problem ist in der Cloud nicht mehr verzeihbar

Klassisches N+1 mit EF Core: Du lädst eine Liste von Bestellungen, gehst durch und greifst pro Bestellung auf den Customer zu. EF Core lädt jeden Customer einzeln. 100 Bestellungen = 1 + 100 Queries. On-Premises: 100 × 0,5 ms = 50 ms, kaum messbar. In der Cloud: 100 × 5 ms = 500 ms, deutlich spürbar. Mit ExpressRoute aus den USA nach Westeuropa: 100 × 80 ms = 8 Sekunden — und du wirst in eskalierenden Beschwerden ersticken.

Lösungen:

• `Include()` für relationale Daten, die du brauchst — EF Core macht daraus einen Single-Query-JOIN
• `Split queries` (`AsSplitQuery()`) wenn der JOIN zu groß wird — zwei Queries statt einem riesigen
• Explizite Projection mit `Select()` — nur das laden, was du wirklich brauchst
• Bei Massenoperationen: `EF.CompileQuery()` für vorkompilierte Queries

Async überall — aber richtig

Async/Await ist in der Cloud nicht optional. Solange dein Thread auf eine Datenbank-Antwort wartet, ist er blockiert und kann keine anderen Requests bearbeiten. Mit synchronem Code skalierst du nur, indem du mehr Threads bereitstellst — was im Web-Server-Kontext heißt: mehr RAM, höhere Kosten, schlechtere Antwortzeiten unter Last.

Faustregeln:

• Jeder DB-Aufruf wird async: `ToListAsync()`, `FirstOrDefaultAsync()`, `SaveChangesAsync()`.
• Niemals `.Result` oder `.Wait()` — das ist die SqlClient-Variante eines Genickbruchs. Deadlock-Garantie.
• Niemals `async void` außer in Event-Handlern. Exceptions verschwinden in der Async-State-Machine.
• `ConfigureAwait(false)` in Library-Code, nicht in Anwendungscode.

Service Tier verstehen — nicht als Vertriebs-Größe, sondern als technisches Limit

Eigenschaft	Basic / Standard	General Purpose	Business Critical
Storage-Typ	Remote (langsamer)	Premium SSD remote	SSD lokal
IOPS pro vCore	Niedrig	~500 IOPS	~5000 IOPS
Latenz	5-15 ms	2-5 ms	< 1 ms
Read Replicas	Nein	Optional, kostenpflichtig	3 inklusive
Geeignet für	Dev/Test	Standard-OLTP	Schreib-intensiv, latenz-kritisch

Tabelle 3: Service-Tier aus Entwickler-Perspektive. Wenn deine App I/O-Performance braucht, ist Business Critical der relevante Hebel.

In-Memory OLTP — wenn du wirklich Performance brauchst

Azure SQL unterstützt In-Memory-OLTP-Tabellen (Memory-Optimized Tables) ab Business Critical. Wenn du eine Tabelle hast, die hunderttausende Schreib-Operationen pro Sekunde abkönnen muss (Session-Storage, Order-Queues, Counter), kann das Faktor 10 bis 30 in der Performance bringen. Voraussetzung: Tabelle passt komplett in den RAM, Schema folgt den In-Memory-Constraints.

Das ist eine Optimierung, die du gezielt für eine spezifische Tabelle nutzt, nicht als Default. Aber wenn der Schuh passt, lohnt es sich enorm.

TIPP Performance-Diagnose in Azure SQL: Query Store ist Default an. Über `sys.query_store_query_text` und `sys.query_store_runtime_stats` kommst du an alle ausgeführten Queries inklusive Laufzeiten. Plus: das Azure Portal zeigt unter „Query Performance Insight“ die Top-Queries grafisch. Vor dem Tuning erst diagnostizieren — gut möglich, dass deine eine schlechte Query 80 Prozent der DTU verbraucht.

 

Schema-Migration und CI/CD

Cloud-Datenbanken brauchen automatisierbare Schema-Updates. Die alte Methode „der DBA klickt am Wochenende mit dem SQL Server Management Studio“ funktioniert nicht mehr — du hast keinen DBA, du hast keinen Zugriff auf die Maschine, und das Wochenende-Deployment-Modell passt nicht zu Continuous Deployment.

Drei Hauptansätze, jeder mit Stärken und Eigenheiten:

Aspekt	DACPAC	EF Core Migrations	Flyway / Liquibase
Modell	Schema-Snapshot	Code-First Diffs	SQL-Skripte versioniert
Eignung	DBA-zentrierte Teams	.NET-Teams mit EF Core	Polyglott, DB-agnostisch
Tooling	SqlPackage, Visual Studio	dotnet ef CLI, Visual Studio	CLI, Maven, Gradle
Stored Procedures	First-class	Nur als Raw SQL	First-class
Rollback	Implizit (Snapshot)	Down-Migration manuell	Undo-Skripte (Flyway Pro)
Daten-Migration	Über Pre/Post-Skripte	Über Up/Down-Methoden	Im SQL-Skript

Tabelle 4: Drei Schema-Migration-Ansätze im Direktvergleich.

DACPAC — wenn die DB die Quelle der Wahrheit ist

DACPAC ist das Microsoft-eigene Format für Schema-Snapshots. Du baust ein SQL Server Database Project in Visual Studio, definierst dort alle Objekte (Tabellen, Views, Stored Procedures, Indizes), und beim Build kommt eine .dacpac-Datei raus. Die kannst du gegen eine Azure-SQL-Datenbank deployen, das Tool berechnet die Differenz und führt sie aus.

Vorteil: Stored Procedures, Views, Functions, Trigger sind first-class Objekte. Du editierst eine .sql-Datei, beim Deploy wird das Objekt aktualisiert. Nachteil: Daten-Migrationen (z.B. „füge default-Werte für die neue Spalte ein“) sind klobig in Pre/Post-Deployment-Skripten.

EF Core Migrations — wenn der Code die Quelle der Wahrheit ist

EF Core Migrations gehen den umgekehrten Weg. Du änderst dein C#-Modell, EF Core berechnet die Schema-Differenz, generiert eine Migration-Klasse mit `Up()` und `Down()`-Methoden. Die werden im Code committed, beim Deployment ausgeführt.

Vorteil: nahtlos in den .NET-Workflow eingebunden, jeder Entwickler kann Migrationen erzeugen. Nachteil: alles, was nicht direkt aus dem Modell ableitbar ist (Stored Procedures, komplexe Indizes, Trigger), musst du als Raw SQL in die Migration packen — das wird schnell unübersichtlich.

CI/CD-Pipeline aus dem Lehrbuch

Egal welches Tool: in deinem Build-Pipeline solltest du folgende Schritte haben:

• Schema-Migration läuft als eigener Pipeline-Schritt, nicht beim App-Start. App-Start-Migrations sind die Falle, bei der zwei Pods gleichzeitig versuchen, dasselbe Schema zu ändern, und sich gegenseitig die Locks rauben.
• Deployment in Stage-Umgebung gegen produktionsähnliche DB-Größe — mit Reset-Skript, das einen sauberen Zustand herstellt.
• Smoke-Tests, die mindestens die kritischen Queries ausführen.
• Erst dann Deployment der App selbst — Schema-Migrationen müssen rückwärtskompatibel sein zur alten App-Version (wegen Rolling Deployments).

ACHTUNG Goldene Regel des Schema-Migration: Trenne Schema-Änderungen, die alten und neuen Code parallel unterstützen, von Code-Änderungen, die das neue Schema voraussetzen. Beispiel: Spalte umbenennen wird zu „neue Spalte hinzufügen, Daten kopieren, App auf neue Spalte umstellen, alte Spalte löschen“ — vier Deployments, kein Risiko. Statt eines „Big Bang“-Deployments mit drei Stunden Downtime.

 

Read Replicas und Lastverteilung

Wenn deine Anwendung viel mehr liest als schreibt — und das ist bei den meisten OLTP-Anwendungen der Fall — sind Read Replicas einer der größten Performance-Hebel, die Azure SQL bietet. In Business Critical sind drei Replicas inklusive, die im selben Cluster laufen und für Lese-Workloads bereitstehen.

Abbildung 5: Read/Write-Routing über ApplicationIntent. Eine Connection-String-Eigenschaft, die du nicht vergessen solltest.

ApplicationIntent — die magische Connection-String-Property

Im Connection-String setzt du `ApplicationIntent=ReadOnly`. Das war’s. Das Azure-Gateway routet diese Connection automatisch auf eine Read-Replica statt auf den Primary. Fürs Schreiben öffnest du eine zweite Connection ohne diese Property — die landet auf dem Primary.

Praktisches Pattern in EF Core: zwei DbContext-Klassen, eine für Reads, eine für Writes:

`services.AddDbContext<MyReadContext>(opts => opts.UseSqlServer(„…;ApplicationIntent=ReadOnly„));`

`services.AddDbContext<MyWriteContext>(opts => opts.UseSqlServer(„…“));`

In den Controllern oder Services injectest du das passende Context: für Berichte den ReadContext, für Mutations den WriteContext. Das Routing übernimmt Azure.

Wann Read Replicas Sinn machen

• Bei Berichten, BI-Queries, Dashboards — alles, was viele Daten liest, ohne sie zu ändern
• Bei Suchanfragen über große Tabellen
• Bei Health-Checks und Monitoring-Queries — die nerven sonst den Primary mit ständigen Heartbeats
• Bei API-Endpoints, die offensichtlich nur lesen (REST GET-Endpoints)

Wann sie weh tun

Replicas sind asynchron repliziert. Das heißt: Wenn du gerade einen Datensatz geschrieben hast und sofort danach lesen willst, bist du in der Zwickmühle. Die Replica könnte den Datensatz noch nicht haben — Replikations-Lag liegt typischerweise bei Millisekunden, kann aber unter Last in den Sekundenbereich gehen.

Das klassische User-Flow-Problem: User submitted Formular → Server speichert Datensatz → Server lädt Datensatz neu für „erfolgreich angelegt“-Page → User sieht „Datensatz nicht gefunden“. Lösung: Reads, die direkt auf einen Write folgen, müssen auf den Primary.

ACHTUNG Häufiger Fehler in Microservice-Architekturen: Service A schreibt einen Event in die DB, Service B (mit ApplicationIntent=ReadOnly) liest aus derselben DB und reagiert auf den Event. Wenn die Services getrennt deployed sind und Service B schneller arbeitet als die Replikation hinterherkommt, läuft die Event-Verarbeitung leer. Lösung: Cross-Service-Events nicht über DB-Polling, sondern über echte Messaging-Systeme (Service Bus, Event Hubs).

 

Lokale Entwicklung — was geht, was nicht

Azure SQL läuft in der Azure Cloud. Du kannst es nicht lokal starten. Trotzdem willst du als Entwickler nicht für jeden Unit-Test einen Cloud-Roundtrip machen, und du willst auch nicht, dass jeder Entwickler seine eigene Cloud-DB hat (Kosten, Datenschutz, Sync-Probleme). Drei lokale Optionen, jeweils mit Vor- und Nachteilen:

Option	Stärke	Schwäche
SQL Server Developer (Docker)	100 % Engine-Kompatibilität, alle Features	Cloud-Verhalten (Latenz, Failover) nicht simulierbar
Azure SQL Edge	Cloud-näheres Verhalten, kleiner Footprint	Eingeschränkter Funktionsumfang, läuft als Linux-Container
LocalDB	Zero-Config, zum Schnell-Testen perfekt	Veraltet, wenig Cloud-Bezug, Windows-only
Eigene Cloud-DB pro Entwickler	Identisches Verhalten zur Produktion	Kosten, Setup-Aufwand, Datenschutz

Tabelle 5: Optionen für lokale Entwicklung gegen Azure SQL.

Empfehlung: Docker mit SQL Server Developer Edition

Für 90 Prozent der Entwicklerteams ist SQL Server Developer als Docker-Container die richtige Wahl. Du hast vollen Funktionsumfang, kannst Tests offline laufen lassen, und das Image ist auf docker.io frei verfügbar:

`docker run -e ACCEPT_EULA=Y -e SA_PASSWORD=YourStrong!Pass -p 1433:1433 mcr.microsoft.com/mssql/server:2022-latest`

Das gibt dir einen funktionsfähigen SQL Server in unter einer Minute. Connection-String aus deiner App-Config: `Server=localhost,1433;Database=mydb;User Id=sa;Password=YourStrong!Pass;TrustServerCertificate=True;`. In den meisten Setups übersetzt eine Umgebungsvariable zwischen lokal und Cloud.

Was du nicht lokal testen kannst

Drei Cloud-Verhalten lassen sich lokal nicht simulieren:

• Latenz — lokal sind Queries sub-Millisekunde schnell, in der Cloud 2-10 ms. Performance-Tests musst du in einer Stage-Cloud-Umgebung machen.
• Failover — Connection Resilience und Retry-Logik kannst du lokal nicht testen, weil dein lokaler Server nicht aus heiterem Himmel failover macht.
• Resource Throttling — DTU/vCore-Limits, Connection-Limits, Storage-Größen. Lokal hast du quasi-unbegrenzte Ressourcen, in der Cloud nicht.

Für diese drei Themen brauchst du eine Stage-Umgebung in Azure, die in Tier und Größe nahe an Production liegt. Wer ohne Stage direkt in Production geht, lernt diese Verhalten in der Echt-Anwendung kennen.

TIPP Pragmatischer Hybrid-Workflow: Unit-Tests gegen Docker-Container (schnell, zuverlässig). Integration-Tests gegen eine kleine Azure-SQL-Database (DTU 5, kostet 5 EUR/Monat) für realistisches Cloud-Verhalten. Last-Tests gegen eine Stage-DB in Produktions-Tier. Drei Stufen, jede für ihren Zweck.

 

Fünf Fallen, die Entwickler regelmäßig finden

Aus zwei Jahrzehnten Code-Review-Erfahrung: das sind die Fehler, die in Azure-SQL-Projekten immer wiederkommen. Sie sind nicht spektakulär — sie kosten dich einfach nur regelmäßig Tage in Production-Bug-Hunts.

1. Synchroner Code in einer asynchronen Welt

Du hast eine Library, die nur synchrone DB-Methoden anbietet. Der Aufrufer braucht aber async. Lösungsversuch: `.Result` oder `.Wait()` aufrufen. In ASP.NET Core kann das in Sekundenschnelle zu Deadlocks führen — der Synchronisation-Context wartet auf einen Thread, der gerade beschäftigt ist, auf eine Methode zu warten, die auf den Synchronisation-Context wartet. Ergebnis: deine App reagiert nicht mehr, kein Stack-Trace, nur noch Logs voll Timeout-Meldungen.

Fix: Bibliothek async machen oder ersetzen. Niemals `.Result` aufrufen, niemals.

2. „Funktioniert lokal“ — Connection-Strings

Lokal nutzt der Entwickler `localhost` und ein einfaches Passwort. Production nutzt Entra ID gegen `prod-srv.database.windows.net`. Die Connection-String steht in `appsettings.json`, wird per Environment-Variable überschrieben — aber irgendwo bleibt eine Variante hartcodiert. Beim Deployment funktioniert es, einen Tag später kommt der Bug-Report: „Anwendung kann nicht auf DB zugreifen, aber nur Mittwochs.“

Fix: Connection-Strings ausschließlich aus Environment-Variablen oder Key Vault lesen. Im Code keine Defaults für Connection-Strings — wenn die Config nicht gesetzt ist, soll die App beim Start crashen.

3. Fehlende Retry-Logik

App läuft seit Wochen tadellos. Dann gibt es zwischen 03:42 Uhr und 03:44 Uhr drei Exception-Logs mit Code 40197 (Service Failover). Der DBA-Bereitschaftsdienst wird angerufen, prüft die DB, alles okay. Aufgabe geschlossen. Eine Woche später dasselbe. Ursache: Microsoft macht regelmäßig Wartung, die ein paar Sekunden Failover bedeutet. Ohne Retry-Logik fliegt die App jedesmal mit einer Exception, die niemand reproduzieren kann.

Fix: EnableRetryOnFailure in EF Core, oder Polly. Eine Codezeile, die das Problem für immer erledigt.

4. Connection-Strings im Source-Code

Klassiker. Connection-String mit Passwort steht im `appsettings.json`, das ins Git committed ist. Dann wird das Repo öffentlich gemacht oder mit Externen geteilt. Innerhalb von Stunden findet ein automatischer Scanner den String, eine Stunde später ist deine DB für irgendwelche Krypto-Mining-Operationen missbraucht.

Fix: Connection-Strings nie in Source-Control. Dev-Umgebung: User Secrets (`dotnet user-secrets`). Production: Key Vault oder direkt Managed Identity.

5. Zu kleines Connection-Timeout

Default-Connection-Timeout ist 15 Sekunden. Bei Cold-Start einer pausierten Serverless-DB kann der erste Connection-Aufbau 30 bis 60 Sekunden dauern. Erste Query nach Pause: Timeout. Lösung: Connection-Timeout im String hochsetzen (`Connect Timeout=60`), und Retry-Logik um den ersten Open()-Aufruf legen.

Fix: Connection-Timeout auf 60 Sekunden, Command-Timeout je nach Workload separat, Retry für Cold-Starts.

PRAXIS Zur Diagnose von Connection-Problemen in Production: Application Insights aktivieren, dort SQL-Dependency-Tracking einschalten. Du siehst dann pro Query die Latenz, Status-Codes, Exception-Stacks. Der Bug, der lokal nie auftritt, ist in Application Insights nach drei Stunden Production-Last meist sichtbar.

 

Drei Praxisbilder

Wie sieht das Ganze in konkreten Projekten aus? Drei Beispiele, anonymisiert auf das Wesentliche reduziert.

Musterwerk GmbH — ERP-Modul-Anpassung

Ausgangslage: Maschinenbauer migriert sein ERP von SQL Server 2019 On-Premises auf Azure SQL Managed Instance. Es gibt ein hauseigenes Reporting-Modul in C#, das per ADO.NET auf die DB zugreift. Code stammt aus 2014, nutzt System.Data.SqlClient, SQL Auth, kein Connection Pooling explizit konfiguriert, keine Retry-Logik.

Anpassungsschritte: Migration auf Microsoft.Data.SqlClient (2 Tage Aufwand). Umstellung auf Entra-ID-Auth mit Service Principal (1 Tag). Einbau von Polly als Retry-Layer um alle DB-Calls (3 Tage). Connection-String-Konstanten zentralisieren (1 Tag, war schmerzhaft, weil 14 Stellen über die Codebasis verteilt). Pre-Production-Tests gegen die Cloud-DB: 2 Tage Performance-Tuning für drei Reports, die mit der höheren Latenz nicht klarkamen.

Ergebnis: nach 9 Entwicklertagen produktionstauglich. Das Reporting-Modul läuft seit 8 Monaten ohne Connection-bezogene Vorfälle.

Sparfuchs & Partner — Multi-Tenant-Mandantenanwendung

Ausgangslage: Steuerberatungs-Software mit 80 Mandanten, jeder Mandant in einer separaten SQL-Server-Datenbank. Migration auf Azure SQL Database mit Elastic Pool. .NET-Anwendung wechselt pro Request den DB-Kontext (je nach eingeloggtem Mandant).

Anpassungsschritte: Connection-Pool-Konfiguration angepasst — vorher hatte jeder Mandant einen eigenen Pool (80 × 100 = 8000 mögliche Connections, was den DTU-Tier sprengen würde). Stattdessen ein gemeinsamer Pool mit dynamischem Database-Switch über `USE [tenant_db]`. Plus: ApplicationIntent=ReadOnly für die Mandanten-Berichte, die auf Read-Replicas laufen können. Plus: alle SQL Agent Jobs aus den Mandanten-DBs in Azure Functions umgezogen.

Ergebnis: 80 Mandanten in einem Elastic Pool von 200 eDTUs (vorher: 80 × eigener DTU). Monatskosten halbiert, Performance besser, weil Pool-Sharing bei den meisten Mandanten ungenutzte Kapazität auffängt.

Trendforge Digital GmbH — Microservices auf Serverless

Ausgangslage: SaaS-Anbieter mit 12 Microservices, jeder mit eigener Datenbank. Lasten stark variabel — manche Services nur tagsüber genutzt, andere nur in Marketing-Kampagnen. .NET 8 mit EF Core 8.

Anpassungsschritte: Alle Services auf Azure SQL Database Serverless umgestellt. Auto-Pause nach 1 Stunde Inaktivität. Connection-Strings angepasst: Connect Timeout auf 60 Sekunden hoch, EnableRetryOnFailure in EF Core eingeschaltet (für die Cold-Start-Resume-Verzögerung). Managed Identity statt Connection-Strings — jeder Service hat seine eigene Identity. Read Replicas für die Analytics-Services.

Ergebnis: Cold-Start-Latenz bei wenig genutzten Services (Admin-UI, Reporting) im einstelligen Sekundenbereich beim ersten Request. Akzeptabel. Monatliche DB-Kosten gegenüber dem vorherigen Setup mit konstantem DTU-Tier um etwa 60 Prozent gesunken.

Unternehmen	Modell	Größter Anpassungspunkt
Musterwerk GmbH	Managed Instance	Provider-Wechsel auf Microsoft.Data.SqlClient, Entra ID, Retry-Logik
Sparfuchs & Partner	SQL DB Elastic Pool	Connection-Pooling über Mandanten hinweg, USE statt eigener Pool
Trendforge Digital	SQL Database Serverless	Cold-Start-Resilience, Managed Identity pro Service

Tabelle 6: Drei Projekte, drei Modelle, drei verschiedene Anpassungs-Schwerpunkte.

 

Pre-Production-Checkliste

Bevor deine Anwendung in Production geht, arbeite diese Liste ab. Sie ersetzt keine ausgereifte Test-Strategie, aber sie deckt die Klassiker ab, die in Production-Bug-Hunts immer wieder auftauchen.

Provider und Connections

• `Microsoft.Data.SqlClient` als NuGet-Paket, nicht das alte `System.Data.SqlClient`?
• Connection-Strings ausschließlich aus Environment-Variablen oder Key Vault, nie hartcodiert?
• Connection Pooling explizit aktiviert (Default: ja, aber prüfen), Pool-Size für deine erwartete Last passend?
• Connect Timeout auf mindestens 30 Sekunden (besser 60), wenn ihr Serverless verwendet?

Authentifizierung

• Entra-ID-Auth statt SQL-Auth, wo möglich?
• Managed Identity, wenn deine App in Azure läuft?
• Berechtigungen minimal vergeben (db_datareader, db_datawriter — nicht db_owner)?

Resilience

• Retry-Logik aktiviert (EF Core EnableRetryOnFailure oder Polly)?
• Maximaler Retry-Count und Backoff-Strategie konfiguriert (5 Retries mit Jitter, exponentielles Backoff)?
• Logs zeigen Transient-Errors auf, ohne pro Vorfall einen Alarm auszulösen?

Performance

• EF Core Queries auf N+1-Probleme geprüft (`Include`, `AsSplitQuery`, `Select` für Projektion)?
• Async/Await durchgängig, kein `.Result` oder `.Wait()`?
• Lasttest gegen produktionsähnliche Cloud-Umgebung gefahren, nicht nur lokal?
• Query Performance Insight im Azure Portal angeschaut, Top-Queries identifiziert?

Schema und Deployment

• Schema-Migration als eigener Pipeline-Schritt, nicht beim App-Start?
• Schema-Änderungen rückwärtskompatibel zur vorherigen App-Version (für Rolling Deployment)?
• Roll-back-Plan dokumentiert, nicht nur „im Notfall überlegen wir uns was“?

Read Replicas und HA/DR

• ApplicationIntent=ReadOnly für Read-Workloads konfiguriert (wenn Business Critical)?
• Failover-Verhalten getestet — ja, wirklich getestet, nicht nur dokumentiert?
• Backup-Retention passt zu Compliance-Anforderungen?

TIPP Wenn du alle Punkte mit Ja beantworten kannst, bist du in besserem Zustand als 80 Prozent der Cloud-Datenbank-Anwendungen, die in Production gehen. Wenn drei oder mehr Punkte unklar sind: bitte einen erfahrenen Kollegen oder externe Reviewer ranlassen, bevor du deployest. Ein Tag Review spart dir gerne mal eine Woche Production-Hotfix.

 

Wenn du tiefer einsteigen willst

Dieses Whitepaper deckt die Themen ab, die jede Cloud-Datenbank-App betreffen. Was es nicht abdeckt: SQL-Server-spezifische Performance-Themen wie Indexing, Query-Optimierung, Statistik-Pflege, Locking-Verhalten, Memory-Grants, Tempdb-Tuning. Das ist ein eigenes Buch wert.

Genau das wird es auch: Im Verlauf 2026 erscheint die Reihe „SQL Server in der Praxis“ in fünf Bänden. Speziell für Entwickler interessant:

• Band 1: Performance & Troubleshooting — Wartetypen verstehen, Pläne lesen, Engpässe finden. Erscheint zuerst.
• Band 5: SQL Server für Entwickler — EF Core 9 Tiefenkurs, T-SQL für komplexe Queries, Anti-Patterns und ihre Fixes.

Wenn du jetzt Hilfe brauchst, drei Beratungsformate:

• Code-Review eurer Cloud-Datenbank-Anwendung: 1-3 Tage, mit Befundbericht und priorisierter Aktionsliste.
• Migrations-Sparring: Begleitung beim Umzug einer Anwendung in die Cloud, mit Architektur-Workshops und Code-Reviews der kritischen Stellen.
• Performance-Analyse: Wenn die App in der Cloud spürbar langsamer ist als On-Premises, schauen wir gemeinsam, wo der Schmerz herkommt.

ERSTGESPRÄCH VEREINBAREN Eine kurze Mail mit zwei, drei Sätzen zur Lage genügt — daraus ergibt sich meistens schon der richtige Termin und ein erster Eindruck, ob die Chemie stimmt. Mail: info@boddenberg.de Web: boddenberg.de

Über den Autor

Ulrich B. Boddenberg ist seit über 25 Jahren als IT-Consultant und Fachbuchautor in der Microsoft-Welt unterwegs. Schwerpunkte sind SQL Server, SharePoint, Microsoft 365, Identity-Themen rund um Entra ID und ADFS sowie Compliance-Architekturen. Autor mehrerer Fachbücher, darunter die Reihe „SQL Server in der Praxis“ (Band 1: Performance & Troubleshooting) und „Microsoft Copilot für Entscheider“. Sitz: Dortmund.

© 2026 Ulrich B. Boddenberg.