Enterprise Delivery Explained
Enterprise delivery for a database is the discipline of getting schema and data changes into production without turning routine work into an incident.
This page builds the mental model behind that discipline, the reasoning that connects risk classification, migration technique, and rollback planning into one coherent process rather than a checklist followed by rote.
Summary
- Enterprise delivery is risk management applied to schema and data changes, matching review depth and rollout technique to how much a given change could hurt if it goes wrong.
- Insight: A database has no undo button once data has moved, so the safety of a change has to be engineered in before it ships, not discovered after.
- Key Concepts: risk tiering, expand/contract, blast radius, rollback plan, maintenance window, change ticket.
- When to Use: Any schema migration, data backfill, or infrastructure change touching a shared production database, from a nullable column add to a major version upgrade.
- Limitations/Trade-offs: Rigorous process adds real lead time to every change, and an org that over-applies high-risk process to low-risk changes will simply route around it.
- Related Topics: DDL locking behavior, change ticket ownership, uptime error budgets, incident response.
Foundations
Every change to a production database carries some chance of causing an outage, and enterprise delivery exists to make that chance visible before the change ships rather than after.
The first move is risk tiering, sorting a change into a category like low, medium, high, or sev-worthy based on what it touches and how it locks.
A nullable column add on a small table is a fundamentally different risk than a type change on a 40-million-row table that takes an exclusive lock for the duration.
Tiering matters because review effort is a scarce resource, and spending a DBA's full attention on every single migration means less attention for the ones that could genuinely hurt.
The second core idea is the expand/contract pattern, which turns one risky step into two safer ones separated by a deploy.
Expand adds new structure, such as a nullable column, without removing or renaming anything the running application still depends on.
Contract removes the old structure only after the application has fully stopped using it, which is why the two steps must never collapse into one migration.
A rollback plan is not an afterthought bolted onto a change ticket, it is a design constraint the migration has to satisfy from the start.
The honest test of a rollback plan is whether it can actually be executed by someone other than the author, at 2 AM, without improvising.
A maintenance window is a scheduling tool that reduces blast radius by moving risk to a low-traffic period, not a technique that removes the underlying risk itself.
Mechanics & Interactions
Risk tiers interact directly with approval gates, so a low-risk change might need only a peer review while a sev-worthy change needs a DBA, a change advisory board, and often an executive sign-off.
That gating exists because a single missed review on a high-risk change costs far more than the aggregate cost of slower low-risk changes, which is the core trade-off the whole system is tuned around.
Locking behavior is the mechanical reality underneath every tier decision, since ALTER TABLE statements vary enormously in what lock they take and for how long.
A CREATE INDEX CONCURRENTLY avoids the exclusive lock a plain CREATE INDEX would take, at the cost of a slower build and a small chance of leaving an invalid index if it is interrupted.
NOT VALID constraints add enforcement for new rows immediately while deferring the expensive full-table validation to a separate, later step that takes a lighter lock.
These are not independent tricks, they are all instances of the same underlying idea: separate the part of a change that must happen instantly from the part that can happen gradually.
Migration tooling like Flyway or Liquibase enforces sequencing and auditability, but it does not know about lock behavior on its own, which is why session-level guards matter just as much as the migration content itself.
-- Guardrails set at the start of a migration session, not left to defaults.
-- These bound how long a migration is allowed to wait or run before it aborts.
SET lock_timeout = '5s';
SET statement_timeout = '30min';A migration that fails fast on lock_timeout is a safe failure, because it aborts before it can hold a queue of blocked sessions behind it.
The interaction between change process and incident response is direct: a change that skips its lock timeout guard is exactly the kind of event that later shows up as a lock storm in the troubleshooting playbooks.
Advanced Considerations & Applications
At enterprise scale, the hardest part of delivery is not any single migration, it is sequencing many concurrent changes against one shared database without them colliding.
A schema council or equivalent forum exists to surface that collision risk before two teams's migrations land in the same window and interact badly.
Major version upgrades deserve their own category of rigor, since they touch extension compatibility, connection behavior, and sometimes on-disk format all at once.
Treating a major upgrade like a product launch, with a dedicated window, a tested rollback path, and staged validation, reflects how much more can go wrong compared to an ordinary column add.
Zero-downtime patterns like dual writing and blue-green cutover exist for the subset of changes where even a maintenance window's brief downtime is unacceptable, at the cost of meaningfully more application complexity during the transition.
Automation increasingly enforces tiering itself, blocking a deploy pipeline from shipping a high-risk migration outside its approved window rather than relying on a human to remember the policy.
The table below compares the delivery models a team might operate under, since the right one depends on traffic pattern, team size, and how much downtime the business can tolerate.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Continuous small changes | Low blast radius per change, fast feedback | Requires strong tooling and discipline to avoid drift | Teams with mature CI/CD and expand/contract habits |
| Batched maintenance windows | Concentrates risk into a known, staffed period | Slower to ship, still causes a visible blip | Regulated or low-tolerance-for-surprise environments |
| Big-bang major upgrades | Simpler to reason about as one event | High blast radius if anything goes wrong | Infrequent, well-rehearsed events with dedicated staffing |
| Blue-green / dual-write cutover | Near-zero downtime for the cutover itself | Significant added application complexity during transition | High-traffic systems where any downtime has real cost |
No single row in that table is universally correct, and mature organizations typically run more than one of these approaches at once depending on the change's tier.
Common Misconceptions
- "Process is just friction that slows engineers down." - Well-tuned process is friction applied selectively to the changes that could actually hurt, which is what makes the fast lane for low-risk changes possible in the first place.
- "Rollback always means dropping the column you just added." - A rollback plan for an expand step is usually cheap, but a rollback plan for a contract step, where old structure is already gone, has to be designed well before that step runs.
- "A maintenance window makes a risky change safe." - A window only reduces the number of people affected if something goes wrong, it does not change the underlying probability of the change failing.
- "CAB approval means the change is technically sound." - Approval gates check governance and communication, not lock behavior or index validity, which is why technical review and approval review are separate, complementary steps.
- "High-risk changes always have to be slow." - A well-rehearsed high-risk process, like a team that has done ten major upgrades, can move faster than a poorly run low-risk process that skips its own guardrails.
FAQs
What is risk tiering and why does every change need one?
Risk tiering sorts a change into a category, such as low, medium, high, or sev-worthy, based on what it locks and how much data it touches.
It exists so review effort, the scarcest resource in the process, is spent where it actually reduces the chance of an outage.
What problem does the expand/contract pattern actually solve?
It turns one risky, all-at-once schema change into two smaller, safer steps separated by an application deploy.
The expand step adds new structure without breaking anything currently running, and the contract step removes old structure only once nothing depends on it.
Why can't expand and contract happen in the same migration?
Collapsing them removes the safety window where the application can be verified against the new structure before the old one disappears.
If something is wrong, there is nothing left to roll back to.
What makes a rollback plan actually usable during an incident?
It has to be executable by someone other than its author, without improvising, under time pressure.
A plan that only the original engineer understands is not really a rollback plan yet.
Does a maintenance window make a change safe?
No, a window reduces blast radius by moving risk to a low-traffic period, it does not reduce the underlying probability the change fails.
The technical safety of the change still has to be engineered separately.
Why does CREATE INDEX CONCURRENTLY matter for delivery process, not just performance?
It avoids the exclusive lock a plain index build would take, which is exactly the kind of lock that turns a routine migration into an incident.
The trade-off is a slower build and a small risk of an invalid index if the build is interrupted.
How does approval gating relate to lock behavior?
They are separate, complementary controls: gating handles governance and communication, while lock behavior is a purely technical property of the SQL being run.
A change can pass every approval and still be technically unsafe if its locking was never reviewed.
Why do major version upgrades get treated differently from ordinary migrations?
They touch extension compatibility, connection behavior, and sometimes on-disk format all at once, which is a much wider blast radius than a single column change.
That is why they warrant a dedicated window and staged validation rather than routine change process.
What is the trade-off with blue-green or dual-write cutovers?
They achieve near-zero downtime for the cutover itself, at the cost of meaningfully more application complexity while both paths are live.
That complexity is worth it only when even a maintenance window's brief downtime is unacceptable to the business.
Is continuous small-batch delivery always better than scheduled windows?
Only for teams with mature tooling and consistent expand/contract discipline.
Without that discipline, small continuous changes can drift into the same risk a big batched change would carry, just spread out.
How does enterprise delivery process connect to incident response?
A migration that skips a lock timeout guard is exactly the kind of event that later shows up as a lock storm needing incident triage.
Good delivery process is largely preventive troubleshooting applied before a change ships rather than after.
Related
- Change Management Basics - the concrete risk-tier matrix and ticket template this model underpins
- Maintenance Windows - when and how to schedule the riskier tier of changes
- Rollback for Failed Migrations - the mechanics of executing a rollback plan under pressure
- Uptime SLOs for Datastores - how error budgets decide how much delivery risk is acceptable
- Troubleshooting Foundations - the evidence-based method this page's rollback and stabilization ideas draw on
- Tech Leadership Key Points - how a tech lead balances delivery speed against correctness and cost
Stack versions: This page was written for PostgreSQL 18.4 (stable line 18, maintenance line 17); the locking and migration behaviors described here are stable across recent major versions.