The total execution time of SqlPackage (DacFx) publish is overly dependent on SQL Server network latency.

• SqlPackage or DacFx Version: 162.5.57 latest
• .NET Framework (Windows-only) or .NET Core: 8.0.11 latest
• Environment (local platform and source/target platforms): Windows 11 OS, Azure MSSQL database

Steps to Reproduce:

1. Create SQL server in azure
2. Create EMPTY SQL database in the SQL server
3. (optional) Run ping on the SQL server
4. Use some DACPAC with a lot of objects to create (in our case it is around 3000 tables, constraints, procedures and so on)
5. Run SQLPackage to deploy the DACPAC
6. Read time elapsed

Did this occur in prior versions? If not - which version(s) did it work in?
Not version related.

(DacFx/SqlPackage/SSMS/Azure Data Studio)
DacFx and SqlPackage.

Hi,
We have encountered a performance issue with SQLPackage (DacFx) when publishing a DACPAC containing a large number of SQL objects (approximately 3,000 tables, constraints, procedures, etc.) to an empty database. We tested this on the WUS3 and WE data centers.

Observations:

• Low Latency (1 ms):
  When running SQLPackage Publish on an Azure SQL Server with a 1 ms ping (a virtual machine in the same data center as the Azure SQL Server), the deployment of the DACPAC takes approximately 1 minute and 30 seconds.
• Moderate Latency (30 ms):
  When running SQLPackage Publish on an Azure SQL Server with a 30 ms ping (e.g., from my PC in Central Europe publishing to an Azure SQL Server in the WE data center), the deployment takes approximately 4 minutes.
• High Latency (140 ms):
  When running SQLPackage Publish on an Azure SQL Server with a 140 ms ping (e.g., a virtual machine in the WE data center publishing to an Azure SQL Server in the WUS2 data center, or vice versa), the deployment takes approximately 20 minutes.

Root Cause:
We identified the issue within DacFx during the execution of the generated publish script. For each database object, a request is sent to the SQL Server (140 ms) and a error is checked (140 ms). This process occurs sequentially in a single thread, without any batching of operations.

This approach significantly increases the total execution time. In our worst-case scenario, with 3,000 objects, the estimated additional time is:
3,000objects×(140msrequest+140mserrorcheck)= 14minutes

Request for Advice:
We hope this provides a clear understanding of the issue. Is there any advice or optimization we could try to speed up the DACPAC deployment process?

Thank you!

Sincerely,
PP

Start by reproducing the issue with a DACPAC containing approximately 3,000 objects against Azure SQL Server at the latency levels described. Inspect the generated publish script and measure the sequential requests and error checks during execution. Done means the publish process no longer scales so heavily with network latency, with timing improvements demonstrated for the reported scenarios.