SqlPackage Publish Scalability and Resiliency Improvements for Large Enterprise Databases

• Version: Using the SqlPackage because the DacFx failed to export the entire DB and all objects, until I started exporting them to disk.
• NET Framework (Windows-only)
• Environment (local platform and source/target platforms): Local windows 11 and a few 2019 servers so far.

This issue becomes increasingly visible for enterprise applications with very large metadata footprints where schema extraction and recreation are required for testing, analysis, and automation workflows. The Smaller schema databases do run as expected. I want to have the Data free schema for SQL creation and tuning with DB heuristics imported to optimize Queries using AI\PowerShell to keep actual data separate from AI. In my case, it should just "blast" them in and validate afterward, if possible.

Steps to Reproduce:

1.Running a restore on a Schema with over 100K objects, sometimes 200K or more.
SqlPackage.exe ^
/Action:Publish ^
/SourceFile:test.dacpac ^
/TargetServerName: ^
/TargetDatabaseName: ^
/TargetTrustServerCertificate:true ^
/p:BlockOnPossibleDataLoss=false ^
/p:CommandTimeout=0 ^
/p:LongRunningCommandTimeout=0 ^
/p:VerifyDeployment=false ^
/p:RegisterDataTierApplication=false ^
/p:ScriptRefreshModule=false

2. So for the new database has not been created, using disk or memory to preform the operation, and it takes 12-16 hours to get to the point of creating the new DB. Once it created the DB and failed, because I was pointing it at the SQL 2025 instance, and not 2019, because of encryption was not supported after over 18 hours.

If not - which version(s) did it work in? All latest versions, for this new project DaxFX worked on the really small databases, but switched to sqlpackage.exe, for the disk storage.

SqlPackage Publish Scalability and Resiliency Improvements for Large Enterprise Databases

Product
SqlPackage
DacFx
DACPAC Publish
Version
SqlPackage: [Insert Version]
SQL Server: [Insert Version]
Database Size: [Insert Size]
Object Count: [Insert Approximate Count]

Summary

We are using SqlPackage as part of an automated database portability and testing workflow for large enterprise SQL Server databases.

For databases containing large numbers of schema objects, DACPAC Publish operations can become extremely long-running and increasingly vulnerable to failure. When a deployment fails after hours of processing, the entire operation must be restarted from the beginning.

The current deployment model appears to be largely all-or-nothing, which creates operational challenges when working with very large schema deployments.

Scenario

Our workflow is:

Extract database schema to DACPAC.
Publish DACPAC into clean test environments.
Use restored environments for automated validation, code analysis, and testing.

Observed Challenges

1. No Resume Capability

If the publish process fails after significant progress has been completed, the deployment must restart from the beginning.

For large databases this can result in:

Hours of lost work
Repeated comparison operations
Repeated deployment planning
Increased risk of deployment abandonment
2. Limited Fault Tolerance

Transient failures can require a full restart even when most schema objects have already been processed successfully.

Examples:

Connection interruptions
Resource pressure
Timeout-related failures
Environmental disruptions

3. Poor Visibility Into Progress Using task manager and procmon to monitor, but could be some info logging, vs Debug logging.

During long deployments it can be difficult to determine:

Which object type is currently being processed
Percentage completed
Remaining work
Whether performance has stalled

4. Large Deployment Planning Overhead

Databases with thousands of objects can spend considerable time generating and validating deployment plans before actual deployment work begins.

Requested Enhancements
Resume / Checkpoint Support

Ability to continue from the last successful deployment stage instead of restarting the entire deployment.

Potential approaches:

Checkpoint files
Deployment stage persistence
Resume token support
Incremental Deployment Batching

Process deployment in smaller object groups:

Tables
Views
Procedures
Functions
Triggers

This would improve recoverability when failures occur.

Object-Level Retry

Allow retry of failed operations without requiring regeneration of the entire deployment plan.

Enhanced Progress Reporting

Expose:

Current object count
Total object count
Deployment phase
Estimated completion percentage
Object types currently being processed
Deployment Plan Persistence

Allow deployment plans to be:

Saved
Reused
Resumed

without requiring repeated regeneration.

Business Impact

SqlPackage is an excellent portability mechanism for SQL Server schemas, especially in automated workflows.

However, as object counts increase, the lack of resumability and fault tolerance becomes a significant operational concern.

Improving resiliency for large deployments would substantially improve:

Enterprise adoption
CI/CD reliability
Automation workflows
Large-schema migration scenarios
Long-running deployment success rates
Additional Information

Diagnostics logs and deployment traces can be provided if helpful.
(DacFx/SqlPackage/SSMS/Azure Data Studio)

Start with the SqlPackage Publish command and the large-schema scenario described in the issue, using the supplied DACPAC and deployment options. The issue names no source files or tests; completion would require defining and validating a focused approach for resumability, fault tolerance, progress reporting, or deployment-plan persistence.