https://nalar.dev/tags/schema-migration/ Recent content in Schema Migration on Nalar Hugo en-us Sun, 13 Sep 2026 00:00:00 +0700 https://nalar.dev/schema-changes-are-multi-version-protocols/ Sun, 13 Sep 2026 00:00:00 +0700 https://nalar.dev/schema-changes-are-multi-version-protocols/ <p>A column rename looks atomic in a schema diff. A deployed system rarely experiences it that way.</p> <p>During a rolling release, old application processes can remain active after new processes start. Background jobs may run code built from another release. Replicas can lag behind a primary. Queued work can outlive the binary that created it. Data written before the change remains present after the new schema exists. The migration therefore crosses several versions of code and data at once.</p> https://nalar.dev/expand-and-contract-at-database-schema-boundaries/ Sat, 12 Sep 2026 00:00:00 +0700 https://nalar.dev/expand-and-contract-at-database-schema-boundaries/ <p>A database column can be structurally valid and still be incompatible with the application processes using it. Renaming <code>customer_name</code> to <code>display_name</code>, for example, is trivial as a data-definition operation on many databases. The harder boundary appears when one application process still issues queries against the old name while another process already expects the new one.</p> <p>That overlap is common whenever application replacement is not atomic. Rolling deployments, multiple service instances, delayed workers, and independent consumers can leave more than one application version active at the same time. A schema migration then has two audiences: the database engine and every executable version that can reach the database during the transition.</p>