Azure SQL Database and SQL Managed Instance Import/Export service takes a long time to import or export a database

Applies to: Azure SQL Database Azure SQL Managed Instance

When you use the Import/Export service, the process might take longer than expected. This article describes the potential causes for this delay and alternative workaround methods.

Azure SQL Database Import/Export service

The Azure SQL Database Import/Export service is a REST-based web service that runs in every Azure data center. This service is called when you use either the Import or Export a database option to move your database in the Azure portal. The service provides free request queuing and compute services to perform imports and exports between Azure SQL Database and Azure Blob storage.

The import and export operations don't represent a traditional physical database backup but instead a logical backup of the database that uses a special BACPAC format. The BACPAC format lets you avoid having to use a physical format that might vary between versions of Microsoft SQL Server, Azure SQL Database, and Azure SQL Managed Instance.

What causes delays in the process?

The Azure SQL Database Import/Export service provides a limited number of compute virtual machines (VMs) per region to process import and export operations. The compute VMs are hosted per region to make sure that the import or export avoids cross-region bandwidth delays and charges. If too many requests are made at the same time in the same region, significant delays can occur in processing the operations. The time that's required to complete requests can vary from a few seconds to many hours.

Additionally, as the Import/Export service performs a logical backup of the database the time to complete is more dependent on the number of objects in the database than a traditional physical database backup.


After resources are assigned and a request starts to process, the service automatically cancels the request after two days.

If your database exports are used only for recovery from accidental data deletion, all the Azure SQL Database editions provide self-service restoration capability from system-generated backups. But if you need these exports for other reasons, and if you require consistently faster or more predictable import/export performance, consider the following options:

Things to consider when you export or import a database

  • All the methods discussed in this article consume Database Transaction Units (DTUs) or CPU quota, which causes throttling by the Azure SQL Database service. You can view the DTU stats for the database on the Azure portal. If the database has reached its resource limits, upgrade the service tier to add more resources.
  • Ideally, you should run client applications (like the sqlpackage utility or your custom DAC application) from a VM in the same region as your database. Otherwise, you might experience performance issues related to network latency.
  • Exporting large tables without clustered indexes can be very slow or even cause failure. This behavior occurs because the table can't be split up and exported in parallel. Instead, it must be exported in a single transaction, and that causes slow performance and potential failure during export, especially for large tables.

Considerations when exporting a database