Why Azure managed databases degrade under load
Peak load rarely breaks an Azure managed database immediately.
First, response time grows: queries that responded quickly in the morning wait at the evening peak for a connection to be released from the pool, some transactions go into locks, and client applications begin to hit timeouts.
The cause is usually not hardware capacity, but a database bottleneck — a poor query plan, a missing index, or a service tier that no longer matches the data volume.
A zone failure outage looks harsher. If the database has no replica in another zone, automatic failover will not occur: the service goes completely silent, and recovery from a backup takes hours.
Data rolls back to the moment of the last snapshot, and everything written after that has to be collected manually.
The third scenario is invisible until the very end — lack of observability. Without metrics on wait time, number of active connections, and I/O latency, degradation shows up only through user complaints.
An engineer cannot distinguish a rise in request count from a connection leak and from storage throughput exhaustion, so tuning is done by guesswork.
All three failures lie in the same plane — configuration, topology, and monitoring. Let's break down how this is addressed.
What changes after configuration: availability and recovery time
After configuring Azure managed databases, not only configuration parameters change, but also system behavior during failure and degradation.
The states the business depends on — replica failover, recovery from a copy, reaction to growing latency — stop being handled "by eye" and are verified at acceptance. Below is what we record as the result.
Fault tolerance and automatic replica failover. The primary node and replicas are distributed across availability zones, automatic replica failover is enabled at the cluster level rather than by an on-call script.
If a node fails, a ready replica takes over the primary role, the application reconnects through a connection string with retries — database recovery time is reduced from hours of manual troubleshooting to seconds.
The difference is tens of times, and it is reproducible: we rehearse failover with a test rather than waiting for a real incident.
Verifiable backup and recovery. Full and log backups are on schedule, retention periods are defined by policy and do not grow uncontrollably, and some backups are stored in a geographically remote storage.
The main thing is recovery to a separate instance according to a procedure: we know that the backup restores, not just that it "was created." Point-in-time recovery rolls back to the state minutes before the failure.
Database observability. Metrics, logs, and slow queries are collected in one place, alerts are configured for space exhaustion, growth in wait times, and throughput drops. An incident becomes visible before the user notices it, and analysis takes minutes.
Azure deployment modes: single server, pool, or cluster
The choice of deployment mode in Azure managed databases determines two things: how the load will grow and what will have to be changed in the data schema during migration.
A single server, an elastic pool, and a cluster with replicas are not interchangeable pricing tiers, but different models of resource isolation.
| Variant | When it fits | Managed database limitations |
|---|---|---|
| Single server | One database, predictable load, its own settings and backup schedule | Resources are not shared; planned maintenance with connection interruption |
| Elastic pool | Dozens of small databases with varying and peak load | Shared resource ceiling and connection limit; cross-database queries unavailable |
| Cluster with replicas | Read load, requirement for fast failover | Read-only replicas, replication lag, schema changes are more complex |
The limitation of a mode shows up in two scenarios — schema change and failover. In a pool, a heavy migration of one database affects neighbors sharing the common ceiling, so it is spread across maintenance windows.
In a cluster, replicas read the same schema, changes are rolled out in stages, and automatic failover takes seconds but requires the application to handle connection interruption correctly.
Before deployment, we estimate how the database will grow: many small databases — pool, one with heavy reads — cluster, full predictability — single server.
A mistake in the choice surfaces not at the start, but during the first scaling, when migration already affects the schema and connection strings.
Implementation stages: from auditing the current schema to handing over procedures
Migrating Azure managed databases to a fault-tolerant mode proceeds sequentially: each stage relies on data from the previous one, so load auditing always precedes topology selection.
For input, we need metrics for a representative period — a decision made based on average load falls apart at peak.
- Database infrastructure audit. We capture the query profile, data volume and growth rate, peak hours, lock contention. We check network rules and application permissions — most often these are what prevent building a fault-tolerance scheme.
- Fault-tolerance schema design. We choose the topology: one availability zone or geo-redundancy, synchronous or asynchronous writes. We fix the target downtime and acceptable data loss — this is the frame for all further settings.
- Replication setup. We distribute read traffic across secondary nodes, define failover order, and select the consistency level for the application logic. Otherwise, where data freshness is needed, stale data appears.
- Monitoring. We cover replication lag, storage growth, lock waits, and connection errors. We tie alert thresholds to on-call duties so the signal reaches someone who can act.
- Recovery verification. We disable a node, restore the database from a backup on a separate environment, and measure actual time to operability. A discrepancy with the target is a reason to return to the topology, not to the procedure.
- Procedure handover. We provide the schema with failure points, instructions for typical incidents, backup schedule and retention policy, change procedure, and access. The team runs operations independently; we support changes.
What we hand over: configurations, schemas, access policies
We deliver not only a working database but also the complete set that will allow your team to run it further without us. All artifacts are issued to your accounts and stored in your repository — we do not remain the holder of the keys.
- Database configuration: instance parameters, fault-tolerance level, storage growth rules — as declarative files that deploy an identical environment.
- Infrastructure schema: topology with availability zones, read replicas, private endpoints, and network segment boundaries.
- Access policies and roles: separation of administrators, developers, and service accounts, least privilege, connection auditing.
- Backup procedures: backup schedule, retention period, point-in-time recovery, and mandatory recovery verification on a staging environment.
- Monitoring: metrics with thresholds — replication lag, storage fill, long queries — and alert routes with an escalation matrix.
- On-call procedure: response times, what we consider an incident, which actions are allowed without approval.
- Knowledge transfer: architecture walkthrough with your team, change log, instructions for upgrades, rollback, and failover.
We agree on each artifact before handover, so the documents describe the real environment, not a generic template.
A month after launch, we perform a reconciliation: we look at what in the configuration has diverged from the description and return discrepancies back into the files — otherwise the documentation quietly becomes outdated and stops being the source of truth.
Case study: a cluster with automatic failover instead of manual operations
Before being brought under management, the database lived on a single node: the standby was brought up manually according to instructions, and failover took from forty minutes to an hour.
The on-call engineer performed 12–14 manual steps — from stopping applications to changing the connection endpoint, and any step could be performed in the wrong order.
What we changed
We deployed a cluster of Azure managed databases with replicas in different availability zones: health checks automatically remove the failed node, replica promotion and connection redirection are performed by the platform.
We configured a schedule of full backups and retention of intermediate logs, added point-in-time recovery, and monitoring — alerts for replication lag, free connections, and long-running queries.
For the on-call engineer, a short procedure remained: confirm the incident and verify that applications have returned to operation.
What resulted
Failover was reduced to 60–90 seconds, manual operations during node failure — zero instead of 12–14.
Eight out of ten failures are resolved without on-call involvement: the platform moves traffic to a live replica, and the team learns about it from the log, not from a night call.
“Previously, half of failovers happened at night, and until morning no one understood what state the database was in. Now the application survives a node failure unnoticed by the user,” — lead infrastructure engineer
What to do if you already have your own cluster deployed on your own servers?
The transition does not have to be simultaneous.
The environment is usually divided into groups: reporting and analytical databases, queues, and rarely used services are migrated first, while the core with strict latency requirements remains on your servers until the managed database proves its behavior under real load.
A phased migration looks like this: initial snapshot load into Azure, then continuous change replication and checksum reconciliation by tables.
As long as the discrepancy is not zero, the source remains primary and the target database operates in read mode — the application can be switched to it earlier than writes.
Driver compatibility is checked before switching traffic: connection strings, connection pool, behavior on disconnect, encodings, and data types.
Some client libraries require explicit settings, otherwise after the switch the application goes into retries and finishes off the database with repeated attempts.
Data synchronization during the transition stage rests on the change log — it also provides a reverse stream if a rollback is needed. The switchover window is measured in minutes, rollback — by returning traffic to your own replicas without losing writes.
It makes sense to leave heavy background tasks, access to local disks, and schemas with extensions that are not available on the service side in place.
The rest is migrated in waves, and each step has a verifiable criterion — so the question “what if it doesn't fit” is resolved at an intermediate stage, not after fully dismantling the cluster.
Typical concerns: compatibility, rollback, availability zones
Before starting work, the customer checks four things: whether the application will work on Azure managed databases without rewriting, whether an update can be rolled back, what happens during an availability zone failure, and where the contractor's responsibility boundary lies.
Will the application have to be rewritten during migration?
Usually not: we preserve the dialect, connection strings, and drivers, and separately verify the compatibility level, server parameters, and extensions.
Before switching, we bring up a copy, run the real query profile, and compare execution plans — discrepancies are visible before production launch.
How is an unsuccessful update rolled back?
We change the schema through migrations, each has a reverse operation, and they are first applied to a test environment.
We switch versions at the connection string level, so rollback takes minutes; if data is corrupted, we restore the database to a point in time before the change.
What happens if an availability zone fails?
The database is deployed with a replica in another zone, failover is automatic, and the application reconnects itself.
The roles are different, though: a replica protects against hardware failure, while a backup protects against human error and data corruption; one does not replace the other.
Who is responsible for a failure — us or the platform?
The platform is responsible for the physical infrastructure and service availability, while we are responsible for configuration, backup procedures, monitoring, and recovery.
We fix the boundary in a document: what we monitor, what the platform covers, and within what window we are obligated to respond.
Let's discuss the task and come back with a work plan
We do not assemble a work plan “by eye” — it relies on an analysis of the current schema, so for an estimate an inventory is enough: which Azure managed databases are used, in which regions, how applications connect to them, and what requirements for availability and data safety are stated.
If the infrastructure is already described as code, send the repository and configurations; if not, an export of the list of servers and databases, current backup schemes, and access settings is enough. This is sufficient to come back with an implementation plan, not with clarifying questions.
- Analysis of the current schema: topology, replication, fault tolerance, network restrictions, explicit failure points.
- List of risks by priority: where a failure will lead to downtime, and where data will not be recovered within the required timeframe.
- Target architecture: availability level, geo-redundancy, storage parameters, backup and point-in-time recovery policies.
- Order of work by stages: preparation, migration, failure scenario testing, production rollout.
- Effort estimate for each stage with assumptions and dependencies — scope and timelines are transparent before the start.
- Monitoring procedure: which metrics we collect, alert thresholds, who responds and in what order.
- Handover for support: access, documentation, training for your team, and a window for addressing feedback.
Each stage is closed by a verifiable result: test migration, failover test report, working alerts. Describe the task — we will come back with an analysis, risks, and a work plan.