A deliberately partial schema package that corrects one specific issue in production — without touching anything the package doesn't mention. Here's when to reach for one and how to run it safely.
A data fix is a deployment of a deliberately partial schema package — usually a handful of migration scripts that correct a specific production issue — rather than a full release.
A data fix is a deployment of a deliberately partial schema package — usually a handful of migration scripts that correct a specific production issue — rather than a full release. SchemaQuench supports this as a first-class mode through four configuration flags that flip together, called the datafix profile.
The distinction matters because several SchemaQuench behaviors are correct for a full release and wrong for a partial package. A full release treats the package as the complete truth of what the database should look like: tables not in the package get dropped, migration tracking records with no matching script get pruned, helper infrastructure gets redeployed. A data fix does the opposite — it runs only what's in the partial package and leaves everything else alone.
Data fixes are for narrow, between-release corrections where the full schema-management cycle isn't warranted or isn't allowed. Common scenarios:
Populate a new NOT NULL column's values, backfill a computed column, correct values that shipped wrong in a prior release.
Redact or delete data to meet a GDPR, HIPAA, or PCI deadline without waiting for the next release cadence.
Add an index to stop a query from timing out in production when you can't wait for the next full release cycle.
Restore a reference table that got clobbered by a bad manual change, or re-apply a lookup-table delta that was missed.
Fix a specific row, reset a stuck workflow state, correct a foreign-key orphan, recover from a partial manual edit.
Run data-only changes in an environment where the deployment user has read/write access but no DDL modification ability.
Where a full release treats the schema package as the complete truth of what the database should look like, a data fix treats it as a surgical slice. Eight dimensions separate the two:
| Dimension | Regular release | Data fix |
|---|---|---|
| Package content | Full product (tables, objects, DataDelivery, all migration scripts) | Partial (usually just migration scripts) |
| Package semantics | Complete truth — database reconciles to match | Surgical — only what's in the package executes |
| Table changes | Added, altered, dropped to match the package | No structural changes |
| Migration tracking | Recorded and pruned to match the package | Not recorded; prior tracking preserved |
| Infrastructure | KindleTheForge runs to sync helper procedures |
Skipped — existing infrastructure assumed correct |
| Rerun-ability | Tracked scripts skip; [ALWAYS] always runs |
Every script runs on every invocation |
| Permissions needed | DDL + data | Data-only in most cases |
| Typical cadence | Scheduled release train | On-demand, between releases |
The datafix profile is four SchemaQuench settings that flip together whenever you're deploying a partial package. Each addresses a specific assumption that full-release mode makes and a data fix has to turn off. The four flags are a profile, not a menu — mixing partial-package intent with full-release reconciliation is how tracking records get corrupted or tables get dropped by mistake. Flip all four together.
{
"KindleTheForge": false,
"UpdateTables": false,
"DropTablesRemovedFromProduct": false,
"TrackRunOnceMigrations": false
}Skip redeployment of SchemaSmith's helper procedures and tracking table. The infrastructure is already in place from the most recent full release; a data fix doesn't need to touch it. Also reduces the DDL permissions the deployment user needs, which matters when the fix is running under a data-only service account.
Skip the table-quench phase entirely. The partial package doesn't contain table JSON; this flag stops SchemaQuench from interpreting their absence as "drop everything." Combined with DropTablesRemovedFromProduct: false, it closes both paths to unintended structural changes.
Tables not in the partial package must not be dropped. A datafix package with two migration scripts and no table JSON would otherwise signal "the product has no tables" and trigger a mass drop. This flag is the last line of defense against a silent catastrophic mistake.
Don't record migration script execution in CompletedMigrationScripts, and treat every script as if it carried [ALWAYS]. Data fixes often need to run more than once — the first run didn't quite land, the fix needs to be re-applied after data drift — and tracking would prevent that. This also forces PruneObsoleteMigrationTracking off regardless of its configured value, which protects the tracking records from prior full releases from being deleted by a partial package's pruning pass.
Two SchemaSmith features show up repeatedly in data-fix packages. Neither is required, but each fits the partial-package shape naturally.
When a data fix touches a large dataset and may need to be retried after a connection drop, server restart, or mid-deployment timeout, enable resume so the fix picks up where it left off instead of re-running completed work. See the Checkpoint and Resume section of the SchemaQuench reference for your platform: SQL Server, PostgreSQL, MySQL.
Even in a partial package, a migration script's slot determines when in the deployment sequence it runs. BeforeTables, AfterTablesScripts, and After are the usual homes for data fixes. The slot is a namespacing and timing signal — the fact that a data fix typically has no tables to run between doesn't change the ordering contract. See Migration scripts for the full slot reference.
A data fix should not carry DataDelivery blocks or table JSON. If your fix is "re-seed this reference table," the right shape is usually a migration script that does the seeding imperatively (or calls a stored procedure that does), not a DataDelivery block in what would then stop being a partial package.
Last reviewed May 2026 by the SchemaSmith Team.