Why a Fast VPN Still Slows a Synchronous SQL Commit

Open a query session on the primary and watch what a simple write is waiting for. If the database belongs to a synchronous-commit availability group and the secondary is connected, part of that wait leaves the building: log records travel to the replica, are hardened there, and word of that hardening comes back before the commit finishes. Bandwidth does not shorten that round trip. The walkthrough below follows the acknowledgment from the screen to the remote disk and back again.

Start at the Wait Type on the Primary

A write waiting on the remote replica shows up as a log-related wait rather than a CPU or lock wait, and the transaction's duration tracks the round trip instead of the row count. Many small commits make it obvious, because each one pays the trip separately. A single bulk operation hides the same cost inside one longer acknowledgment.

Sort your workload by commit frequency before concluding anything about the link.

Read the replica state before you read the network. The counters that matter are the send queue, the redo queue and the synchronization state, and together they show whether the secondary is keeping up or falling behind. A growing send queue points at transport, while a growing redo queue points at the secondary's own work or storage. Those are different repairs, and neither one improves by adding bandwidth.

Follow the Acknowledgment to the Secondary

Under synchronous commit the primary waits for confirmation that the relevant log has been hardened on the secondary before it reports the commit as done. Hardened means durable in the log, not replayed into data pages. That distinction is exactly why a synchronous secondary can be behind on redo while still confirming hardening.

Walk the path in order and time each stage rather than the whole. Log records go over the transport, the secondary writes and flushes them, and the acknowledgment returns along the same path. Transport delay, secondary scheduling and secondary log-disk latency all land in the total, and only the first belongs to the network owner. A secondary whose log volume is saturated by something else can stretch every commit while the link sits idle.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Take that snapshot before and after a representative write rather than once on a quiet afternoon. The delta is what tells you which queue moved while the commit waited.

Measure the Path Instead of the Link

A throughput test measures capacity between two points that are not your replicas, under a load that is not your workload. Ask the network owner for delay and loss along the real replica path while real traffic runs, in both directions. Loss matters more than capacity here, because a dropped segment costs a retransmission and every commit is waiting on one acknowledgment. A link that looks excellent in a download test can still be a poor fit for a chatty commit pattern.

Keep database transport security and access controls intact while measuring. Measuring a path is never a reason to bypass them.

Correlate timings with the counters rather than with intuition. If the send queue stays empty and the commit still waits, the delay is in the acknowledgment or the secondary's flush. If the send queue grows steadily, transport or capacity is the constraint. Record which observation supported the conclusion so the next person can repeat the measurement instead of repeating the argument.

What Asynchronous Mode Actually Changes

Asynchronous commit removes the wait for the secondary's hardening acknowledgment, which is why writes get faster and why your durability position changes. The primary confirms the transaction without that remote confirmation. The secondary is then allowed to lag, and the lag is the exposure.

If the primary is lost before the log reaches a usable failover target, forcing service onto that replica discards transactions the application had already been told were committed.

That is a recovery-point decision and it belongs to the database owner, not to a performance review. Set the tolerated data-loss window first, choose the mode that satisfies it, then optimise inside that boundary. Options that keep synchronous protection include removing avoidable commit round trips where the application permits, fixing a measured transit or storage bottleneck, and moving the replica so the acknowledgment travels less far. Weigh them against the durability requirement you started with, which has not changed.