A software update needs a transition phase.

During the update, two versions work

When you evolve custom software, the transition between two versions is part of the development task itself. That becomes especially important once the database structure also changes. Our recommendation: plan explicitly which combination of application and database must work during each stage.

Kubernetes describes for rolling updates how old application instances are gradually replaced by new ones. Different versions can run at the same time. If both use the same database, its structure must fit both during that transition. For planning that means: also check the intermediate state where new software already runs and the old one still handles requests.

Example: a required field in several stages

Example flow: a custom service application should store a category with every case going forward. So far that field does not exist. In the first step the team adds a database column that may stay empty. The new application captures categories for new cases and can still display existing entries without a category.

Existing cases are then assigned. Clear cases can be handled by defined rules; unclear ones go to business review. As long as old programme versions can still create cases without a category, the database must not require that field. Only when all writing programmes are switched and every missing assignment is clarified does the binding database rule follow.

This order matches the approach GitLab documents for adding a NOT NULL condition: first roll out the required application changes, then the stricter database rule. The benefit for you is separately checkable steps. The prerequisite is a complete overview of every programme that writes to the affected table.

A short change can keep the database busy

The technical execution also needs planning. PostgreSQL 17 requires an exclusive table lock for many ALTER TABLE changes. Which lock is actually needed depends on the concrete operation. The brevity of a change command therefore says little about its effect in live operations.

For certain rules the work can be split: foreign-key and CHECK constraints can first be created with NOT VALID. New or changed rows must then already satisfy the rule; existing data are checked later with VALIDATE CONSTRAINT. That is not a general switch for interruption-free changes. Have lock behaviour and runtime examined for your concrete database version.

Large datasets need checkable partial steps

With large datasets, separate planning of the data conversion is advisable. GitLab documents background migrations in batches for that. Individual work steps should be small and repeatable: a retry after an error must preserve data integrity. The documentation also names data volume, runtime, and extra database load as important checks.

For the example flow we recommend a progress view with processed cases, open assignments, and errors. Decide who resolves conflicting categories and under which conditions processing pauses. Before completion, check the actual data state. This extra work pays especially when a large dataset should stay in use during the conversion.

The way back has a technical limit

On deployment rollback Kubernetes restores the pod template, meaning the template for the running containers. Database changes already made are not automatically undone. Our conclusion: a successful application rollback does not yet prove that the previous version can work with the data state now reached.

Therefore document for each stage up to which application version a rollback was checked. In the example that includes a write attempt with the old version after introducing the required field. Once that version cannot satisfy the new rule, merely swapping the application is not a sufficient way back.

Start with one concrete change

Our suggestion for the first step: pick an upcoming database change in your own application. On one page record the programmes involved, the order of stages, completion criteria, and responsible people. Rehearse the flow with synthetic data at a realistic scale. Explicitly check an interruption and subsequent continuation.

An open database such as PostgreSQL provides traceable technical foundations for that. The decision about effort remains project-specific: for a small internal application an agreed maintenance window can be more appropriate than costly parallel operation. An interruption-free conversion cannot be guaranteed from the approach described alone.

Research as of 23 September 2026. PostgreSQL statements refer to version 17. The linked Kubernetes and GitLab pages are updated continuously; concrete flows must match the version in use.