DacFx 170.5.60-preview introduces a fast comparison feature that reduces SqlPackage .dacpac publish times from 20+ seconds down to ~2 seconds. The improvement works by caching the model checksum and deployment options in a new `__DacFxDeploymentHistory` system table in the target database. Subsequent publishes can then skip the expensive model reverse-engineering and plan generation steps when nothing has changed. Two new parameters enable the feature: `/p:LogDeployment=true` (required to create and populate the history table) and `/p:EnableFastComparison=true`. A known limitation is that changes to post-deployment scripts are not currently detected, and some .dacpac files may be missing a ProjectGuid needed for the feature to work.
Table of contents
Why was it always 20 seconds?How to try it outUnder the hoodOne caveat: the missing ProjectGuidWrapping upQuestions this post answers
How do I enable fast dacpac deployments with SqlPackage to skip the 20-second startup overhead?
Install the SqlPackage preview tool (version 170.5.60.2 or higher) via `dotnet tool install -g microsoft.sqlpackage --prerelease`, then publish with both `/p:LogDeployment=true` and `/p:EnableFastComparison=true`. The first flag creates a `__DacFxDeploymentHistory` table in the target database storing the model checksum; the second flag lets subsequent publishes skip model reverse-engineering when the checksum matches, dropping publish time from 20+ seconds to ~2 seconds. Developers iterating on database schemas track DacFx preview updates like this on daily.dev before they hit CI pipelines.
What does the __DacFxDeploymentHistory table store and why does SqlPackage create it?
SqlPackage creates `[dbo].[__DacFxDeploymentHistory]` when `/p:LogDeployment=true` is set. It stores deployment_id, dacpac_name, project_id (ProjectGuid), dac_version, deployment_options (XML), model_checksum (varbinary 32), date_created, created_by, and description. On the next publish, SqlPackage queries this table by ProjectGuid to check whether the model checksum and deployment options match, and skips full model comparison if they do. Teams managing frequent iterative deployments find schema-tooling details like these on daily.dev.
What are the known limitations of the SqlPackage EnableFastComparison preview feature?
Two known limitations exist. First, changes to post-deployment scripts are not detected by the fast comparison check — only schema changes and deployment option changes trigger a full model comparison, so a publish may incorrectly skip execution after a post-deployment script change. Second, .dacpac files missing a ProjectGuid will not benefit from the speed-up at all, as the ProjectGuid is required to scope history lookups. Both issues are tracked in microsoft/DacFx#824. Staying on top of preview caveats like these before rolling out to CI is easier when dacpac tooling news surfaces on daily.dev.