Microsoft published Hybrid Logic Apps SQL storage-provider benchmarking on October 26, 2026. The exercise uses a file-driven workflow on a single on-premises host, with the cluster, SMB files, and SQL Server 2025 sharing backing storage. It is a workload-specific observation, not a product capacity guarantee. Microsoft benchmark.
For integration teams, the interesting adoption question is whether a proposed deployment can absorb the business's arrival pattern and recover after a burst. I would make that the center of a pilot.
Read the Measurement Boundary First
The benchmark offered approximately 100 small files per second during a 30-minute window and accumulated a backlog. Its reported workflow execution durations exclude waiting in the receiving folder. A repeat improved completed workflow throughput while average workflow-state data-file write latency worsened. Those measurements describe different parts of the system. Measurement details.
My test report would begin with a simple definition of completion. For an invoice workflow, that might mean the destination has accepted the intended business record and the originating item has reached its agreed terminal state.
Assign each synthetic invoice an identifier before arrival. Preserve that identifier through every test observation so the final reconciliation can account for individual items, including ones still waiting at cutoff.
Add an Arrival-to-Completion View
I would report the age of the oldest waiting item alongside workflow execution time. A business owner can then assess whether an apparently fast run still starts too late to meet the deadline.
Include three proposed test phases: ordinary arrivals, a deliberate burst, and a recovery period after the generator stops. Keep the observation running until the test cohort is reconciled or the agreed recovery deadline expires.
Count unfinished items explicitly. Excluding them from a completed-work latency chart should never make them disappear from the acceptance decision.
Use different payload sizes representative of the intended integration. A pilot should disclose which input mix it covered so another team does not inherit its conclusion for a substantially different workload.
Separate Replica Decisions From Storage Decisions
Microsoft's benchmark scales workflow pods on the same node; adding those pods does not add disk capacity. The shared layout alone also does not prove the cause of a bottleneck. Topology and interpretation.
My proposed experiment would change one capacity variable at a time. Preserve the input cohort and configuration record for each run, then compare both business completion and resource observations.
Have the team state the expected result before the change. If additional replicas are expected to improve drain time, record what evidence would contradict that expectation.
Do not turn an inconclusive run into an infrastructure purchase. Repeatability and a clear explanation of the measurement matter more than a single attractive throughput number.
Test the Management Boundary Separately
Microsoft Learn distinguishes local workflow execution from Azure-connected management. Workflows with locally available dependencies can continue during an Azure connectivity interruption, while Azure-dependent management capabilities can be unavailable. That distinction matters when interpreting disconnected-runtime claims. Hybrid deployment requirements.
I would create a separate operational exercise for a connectivity interruption. Define in advance which local workflow behavior is expected and which operator tasks require Azure connectivity.
Record who can inspect the local queue, how they obtain trustworthy status, and how the team confirms normal management after connectivity returns. Keep this result separate from the load test so success in one exercise does not stand in for the other.
Practical Cloud Engineer Takeaway
Define business completion and reconcile every test item.
Measure waiting time as well as execution time.
Include burst recovery and unfinished work in the decision.
Change capacity variables individually and preserve inputs.
Test connectivity interruption behavior as its own exercise.
Who Should Care?
Logic Apps engineers, BizTalk modernization teams, and platform owners evaluating integrations on infrastructure they operate.
Bottom Line
The new benchmark is useful evidence for designing a pilot. Your adoption decision still needs to show that the intended business workload completes within an acceptable time on the proposed infrastructure.
No cluster was deployed, file workload generated, storage configuration changed, or performance test executed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments