HADR_DATABASE_FLOW_CONTROL is an Availability Group wait recorded on the primary when log capture has outrun the network send. Each database in an AG has a quota of unacknowledged messages allowed in flight to a secondary; when the queue is full, log scanning pauses under this wait until the secondary acknowledges some of the backlog.
It is the AG’s built-in throttle: the primary can read log faster than it can ship it, so it waits.
Is It a Problem?
By design it is a safety valve, and small amounts are normal on busy AGs. It matters when it grows, because sustained flow control means the pipeline to a secondary is the bottleneck, and on synchronous replicas that eventually surfaces as HADR_SYNC_COMMIT waits, which users feel as slow commits.
Judge it by trend and by company: rising flow control plus a growing log_send_queue_size in sys.dm_hadr_database_replica_states means the secondary or the network genuinely cannot keep up.
Common Causes
- Network throughput or latency between replicas insufficient for the log generation rate, common with cross-site or cloud-region secondaries.
- Log-heavy operations (index rebuilds, bulk loads) producing bursts far above the steady-state rate.
- A slow secondary: undersized hardware, slow log disk, or redo falling behind and backing pressure up the pipeline.
- Many databases in one AG sharing the same replication capacity.
What To Do
- Quantify the backlog per database and replica:
log_send_queue_sizeandlog_send_rateinsys.dm_hadr_database_replica_states. - Compare log generation rate on the primary with what the network can actually carry. If generation exceeds capacity, either reduce the log volume (tune index maintenance, batch loads) or upgrade the link.
- Check the secondary is pulling its weight: log disk latency and redo queue on the replica.
- On current builds, review Microsoft’s guidance on AG flow control gates; recent versions raised the per-database gates, and trace flag 12310 exists for specific older builds. Test before touching flags.
How To See It
Rank it against everything else with Get-WaitStatistics. Read it alongside HADR_SYNC_COMMIT and the replica-state DMVs to tell a network problem from a secondary problem.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply