Contents
- "We solved this with CI/CD"
- Three structural differences between code and a database
- Seven paths that skip the pipeline
- Why pipeline silence reads as "nothing happened"
- Validation in the pipeline is not the decision
- Does governance slow the pipeline down
- Measure it with a single number
- Frequently asked questions
A team that has built a delivery pipeline on the application side is rightly proud of it. Repository, review, automated tests, release tags, rollback; all in place. The same maturity has been applied to the database: schema changes are versioned, the pipeline carries them, environments stay consistent. This article does not criticise that setup. It asks one question: what share of the work reaching your production database actually goes through that pipeline?
"We Solved This With CI/CD"
For the application layer this statement is true. For the database layer it is partly true, and how partly varies by organisation. The gap does not come from a weak pipeline; it comes from a database behaving differently to code.
Three Structural Differences Between Code and a Database
1. Code can be rolled back, data cannot
Rolling back a bad release means redeploying the previous package. Rolling back a bad update means knowing the old values, and those values are gone. With a table truncation there is no way back at all. A pipeline's rollback button does not distinguish between these two cases; it treats them alike.
2. Code is stateless, a database carries state
Running the same deployment twice is harmless in an application. Running the same script twice can double the outcome in a database. That is why writing idempotent database scripts is a separate discipline, and the pipeline itself does not police it.
3. A correct script can still stop production
This is the most overlooked difference. A review looks at whether the script is correct. What stops production is how the script behaves. Adding a column with a default to a large non empty table, rebuilding an index offline, updating millions of rows in one transaction, validating a constraint: every one of these can be perfectly correct and every one can cause locking. Dropping an index or a statistic shows its effect the next day; the deployment looks successful and the problem arrives in the morning.
An honest boundary
No product can tell you in advance how long a script will hold a lock, and any story that promises this is not true. What can be done is different: deriving the risk from the content (which object, which statement type, does it match a critical object, is there a predicate), preparing the rollback script in advance, and recording the affected row count after execution.
Seven Paths That Skip the Pipeline
None of these paths is a rule violation. Each has a reason that makes sense at the time. What the organisation experiences is not a breach of rules but a gap in scope.
| Path | The reason at the time | What it leaves behind |
|---|---|---|
| Emergency fix | Customers are affected, this cannot wait | A record exists; the post review usually does not |
| Data correction | One row, not worth a release | No schema changed, so it enters no release record |
| Permission change | A new team member needs access | Who can reach what quietly widens |
| Maintenance work | Routine, done every month | Scheduled jobs whose content nobody has read in years |
| Vendor updater | The product's own tool does it | The organisation did not make the change but still carries the responsibility |
| A script hidden in a release | The release is already approved | The approval covered the release; the database change was never separately assessed |
| Reading production data | A business unit asked for a report | A pipeline never carries read requests; the file stays on someone's machine |
Why Pipeline Silence Reads as "Nothing Happened"
A pipeline only knows what it carried. It says nothing about what it did not carry, because it has no data to say it with. That is where the trouble begins: when the pipeline report looks clean, it reads as "nothing else happened in production". What the report actually means is only "nothing else went through the pipeline".
The same misreading happens in audits. The line "no unauthorised changes detected" can mean two different things: none occurred, or none was visible where you looked. Both produce the same line and cannot be told apart.
Validation in the Pipeline Is Not the Decision
Mature teams put validation steps in the pipeline: unqualified updates are blocked, naming conventions are checked, scripts must be idempotent. Those steps have real value and part of what they do overlaps with a governance layer.
The part that does not overlap is this: validation is a technical gate, the decision is a governance record. Validation says "this script breaks a rule" and stops. The record says: this script triggered that rule, because it triggered it an extra approval was required, that approval came from this role, the rule set in force that day was this one, and the decision was taken for this stated reason. Months later, the second one is what gets asked.
There is one more difference: a pipeline rule lives in the pipeline configuration and changes over time. Explaining a decision from six months ago using today's rule is misleading. The rule a decision rested on has to be frozen next to that decision, exactly as it stood on the day.
Does Governance Slow the Pipeline Down
A badly designed approval process does slow things down, that is true. Sending every change to a central board is not framework compliance either but a departure from it: ITIL 4 names this an anti pattern explicitly and explains why. When the board becomes a bottleneck, people route around it, changes pass without review and visibility into what changed is lost.
The right design is risk based. ITIL 4 defines three change types and states that a standard change has its procedure pre authorised and needs no approval per instance. The same framework also says a change authority may be a person, a team or an automated mechanism. So a rule engine making the decision is not a departure from the framework; it is what the framework anticipates.
In practice this means: a low risk script that triggers no rule waits for nobody. A script that touches a critical object, contains an unqualified update or cannot be rolled back asks for an extra step. The only thing that slows down is risky work, which is the entire point.
Measure It With a Single Number
One measurement ends this discussion, and most organisations have never computed it:
What percentage of the schema and data changing statements that ran in your production database last month went through the delivery pipeline?
Computing it means looking at the database's own records, not the pipeline's. The pipeline gives you the numerator, never the denominator. Only the database side can produce the denominator.
If the number is close to a hundred per cent, you need a governance layer less, and we will say so plainly. If you do not know the number at all, measure it first. In most organisations the first calculation comes out lower than expected, and the tone of the discussion changes.
Let your pipeline stay where it is
We will show how the paths your pipeline does not carry enter the same record model, working from your current setup.
Book a Demo →