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.
//
Busca en todas las páginas de la documentación
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Revisado por Chris St. John·Última actualización: 15 jul 2026