SchemaQuench — Declarative Schema Deployment

SchemaQuench takes a schema package — a directory of JSON and SQL files representing your desired database state — and applies it to a live target. It compares what the database is right now against what your package declares, computes the minimal DDL needed to close the gap, and executes it. No hand-written ALTER scripts. No guessing what changed. You run the same package against dev, staging, and production and get the same predictable result every time.

The process is straightforward: SchemaQuench reads your package, connects to the target server, diffs the live schema against the declared schema, generates the necessary DDL, and applies it in order. Run-once migration scripts are tracked in a migration table so they execute only on their first deployment, while scripts marked to run every deployment execute on each pass. Table operations run in parallel by default — up to 10 concurrent threads — so quenching completes quickly even on large schemas.

One SchemaQuench executable runs on three platforms: SQL Server, PostgreSQL, and MySQL. The tool works identically on all three; what changes is the adapter underneath. Set your Platform value to SqlServer, PostgreSQL, or MySQL and SchemaQuench picks the right DDL dialect, helper procedures, and platform-native metadata.

Long deployments fail — network blips, transient timeouts, a migration script that trips on bad data partway through. SchemaQuench handles this with checkpointing: as the quench progresses, every completed step and migration script is recorded to a checkpoint file on disk. If the deployment fails at step 14 of 20, the next run can resume from where it left off using the --ResumeQuench flag, skipping all the work that already succeeded and picking up at the first incomplete step. Checkpointing is automatic — you don't configure it — and opt-in via the flag; without --ResumeQuench, every step runs regardless of prior state. On a successful clean run, SchemaQuench deletes checkpoint files automatically so no residue remains. For platform-specific details on checkpoint recording and CheckpointDirectory location, see the SQL Server reference.