Assessment and drift capture
What is really in each environment, how far apart they have grown, and which differences are deliberate. Short, and it produces the inventory every later decision is argued against.
The database delivery practice
Database DevOps in Saudi Arabia
Most teams have solved application delivery and left the database exactly where it was: a change request, a maintenance window, and one person who knows what is really in production. This practice closes that gap, which is usually the largest single constraint on how often anything ships.
In short
Database changes, delivered like every other change
Interkey does database administration, data modelling and DevOps engineering, and this page is what happens when those three are the same engagement: putting schema and reference data under version control, building the pipeline that deploys them, and designing what happens when a deployment has to be undone.
The scope is deliberately narrow. This is not about which database you should be on — that is data platform modernisation — nor about moving to a different one, which is database migration. It is about the changes you ship against the platform you already have, every week, for years.
The reason it is worth a practice of its own is arithmetic. If applications deploy weekly and the database deploys quarterly, the system deploys quarterly. Every investment in the application pipeline is capped by the slowest thing in it, and in most enterprises the slowest thing is a schema change waiting for a window.
Symptoms
What this looks like before it is fixed
These are the states teams describe, and what each one usually indicates. Note how few of them are described by the people experiencing them as a database problem.
| What you observe | What it actually indicates | Where to start |
|---|---|---|
| Nobody is certain what is in production | The database has no single source of truth; the authority is a running server | A baseline capture and a drift check, before anything else. You cannot automate deployment to a target whose current state is a matter of opinion. |
| Schema changes need a window and a DBA at midnight | Changes are not designed to be applied online | Rework the change patterns first — expand-then-contract, backfill separated from switch. The window is a symptom of change design, not of tooling. |
| Environments drift from each other | They are provisioned by hand, or by a script nobody has run end to end recently | Rebuild a lower environment from source and see what breaks. What breaks is the list of things production depends on that nobody wrote down. |
| Rollback means restore from backup | There is no rollback plan, only a disaster-recovery plan | The most urgent row here. Restoring a backup loses everything committed since it, so in practice teams do not roll back — they fix forward under pressure, which is how a bad deployment becomes an outage. |
| One person reviews every database change | A knowledge concentration, usually mistaken for a quality control | Automate what the review actually checks. Most of it is naming, index presence, blocking-operation detection and permission changes, all of which a pipeline enforces more consistently than a tired human at 2am. |
| Application and database releases must be coordinated exactly | The two are tightly coupled by design rather than by necessity | Decouple with backward-compatible change patterns so a schema version supports the application version either side of it. This is the change that makes everything above possible. |
The order
Why the sequence is not negotiable
Each step is only safe once the one before it holds. Teams that start at automation because that is the visible part end up automating the deployment of changes nobody could describe.
-
Establish the truth
Schema, reference data and permissions captured into version control, and a drift check that reports the difference between the repository and each environment. Until this exists, everything downstream is guessing.
-
Fix the change patterns
Additive and reversible by default: add before removing, backfill separately from switching, never a destructive change in the same deployment as the code that stops using the old shape. This is what removes the maintenance window.
-
Automate the checks
Static analysis on every change — blocking operations, missing indexes, permission grants, naming — run in the pipeline. Consistent, fast, and it frees the human review for the design questions a tool cannot judge.
-
Deploy through the pipeline
The same artefact promoted through environments, with the database change applied by the pipeline rather than by a person with a console open. Applied, verified, recorded.
-
Prove the rollback
Every change ships with its reverse, and the reverse is exercised in a lower environment rather than assumed. An untested rollback is a plan to discover during an incident whether you had one.
The hard part
Rollback is where the discipline is decided
Code rolls back. Data does not.
Application rollback is a solved problem: deploy the previous artefact and the system is as it was. Databases do not work that way, and the difference is not a gap in tooling — it is the nature of the thing. A dropped column cannot be restored by re-running the deployment backwards, because the data that was in it is gone.
The consequence is that safety has to be designed into the change rather than supplied afterwards by a rollback mechanism. In practice this means never making a destructive change in the same release as the code that stops using the old shape: the column is added, the application is switched, the old column is left in place for a defined period, and only then removed — by which point the switch has already proved itself in production.
That sequence is slower per change and dramatically faster per quarter, because it is what makes deployment routine enough to do often. It also removes the argument that produces most database outages: the one where a destructive change is judged safe because the release it belongs to has been tested.
There is a related failure worth naming separately. A long-running migration applied inside a deployment can hold locks for minutes on a large table, and the deployment appears to hang while the application appears to be down. Backfills belong outside the deployment path, run in batches, and monitored — which is a day-two operations concern as much as a delivery one.
Scope
How the work is usually shaped
Four shapes. The first is frequently bought alone, and frequently changes what the buyer thought the problem was.
Pipeline build
Version control for schema and reference data, automated checks, and deployment through the same promotion path as the application — built into the delivery tooling the team already uses rather than beside it.
Change-pattern rework
Retrofitting expand-then-contract and online change patterns onto an existing schema, which is where the maintenance window disappears. Usually the highest-value phase and rarely the one asked for first.
Handover and standards
Written standards, review criteria that are automated rather than remembered, and enough transfer that the practice survives the person who introduced it. A pipeline only one team member understands has moved the bottleneck, not removed it.
The Saudi layer
What is specific to this market
Two things change the shape of this work here.
Non-production data is still regulated data. The ordinary way to get a realistic test environment is to copy production into it, and for databases holding personal data that is a data-protection decision rather than an engineering convenience. Doing it properly means masking or generating test data, which is real work and belongs in the plan from the start — not discovered when someone asks where the lower environments got their contents.
An audit trail is a requirement, and a pipeline produces a better one than a process. Regulated organisations have to show who changed what, when, and who approved it. A manual change process produces that record as paperwork, maintained separately from the change and therefore imperfectly. An automated pipeline produces it as a by-product of the deployment itself, which is both more complete and harder to argue with. This is one of the few cases where the compliance requirement and the engineering preference point in exactly the same direction.
The work is delivered from Riyadh by the same engineering practice that builds custom enterprise applications, which matters here more than usual: database delivery is not a separable specialism, and a pipeline designed by people who do not have to live with the application it serves tends not to survive contact with the release schedule.
Definition of done
What finished actually looks like
A database delivery practice is easy to declare and harder to demonstrate. These are the things that are either true or not, and each of them can be checked by someone who was not involved:
- The repository, not a running server, is the authority for what the schema should be — and a drift check reports any environment that disagrees
- A lower environment can be rebuilt from source, by someone who has not done it before, without asking anyone a question
- Every database change reaches production through the same pipeline as the application, and none reaches it any other way
- Every change ships with its reverse, and the reverse has been exercised somewhere other than production
- Destructive changes are never in the same release as the code that stops using the old shape
- The review criteria are enforced by the pipeline rather than remembered by a person, and the deployment record itself is the audit trail
- Non-production environments contain masked or generated data, and it is documented how they got it
Questions
Questions buyers actually ask
Common question
Which tooling do you use?
Whatever fits the platform and the pipeline that already exists. The migration-tool decision is genuinely secondary: the tools in this space converge on the same primitives, and none of them fixes a team whose change patterns require an outage. Where an estate has no tooling, or is SQL Server and the comparison and monitoring toolset earns its place, Interkey implements Redgate’s tooling; that page maps the tools onto the sequence above. A practice built around a specific product tends to recommend that product, which is a reason to be sceptical of one — including ours, if we ever start doing it.
Common question
Can this work without a maintenance window?
For most changes, yes, and that is largely a property of how the change is written rather than of when it is applied. Additive changes, separated backfills and staged switches apply online. A small residue genuinely needs a window — certain large-table restructures on some engines — and the goal is to make that residue rare and predictable rather than to pretend it is empty.
Common question
What if we do not have version control for the database at all?
That is the common starting point rather than an unusual one. The first step is a baseline: capture the current production schema as the origin, and treat every change from that point forward as a versioned artefact. There is no need to reconstruct the history that was never recorded, and attempting to is a good way to spend a month before delivering anything.
Common question
Does this apply to NoSQL as well?
Yes, with the difficulty moved rather than removed. A document store does not enforce a schema, so there is no migration to run — which means the old shapes remain in the data and the application has to handle every version it has ever written. That still needs versioning, still needs a backfill strategy, and still needs someone to decide when an old shape may finally be assumed gone. Interkey’s document-platform work is on Couchbase.
Common question
How long before this pays back?
The assessment pays back immediately, because knowing what is in production is worth having whatever you do next. The pipeline is a matter of weeks. The change-pattern rework is the long one and the one with the real return, and it is paid down schema by schema rather than in a single programme — which is a feature: it means the value arrives incrementally rather than at the end of something that might be cancelled.
From the insights library
The neighbouring decisions
Practice
Data platform modernisation
Which platform you should be on, including the case for staying exactly where you are.
PracticeDatabase migration
Moving between platforms: a one-off programme, as against the recurring delivery practice on this page.
PracticeCustom software development
The application half of the same delivery pipeline, built by the same engineering practice in Riyadh.
Explore related solutions
Next step
Start with what is actually in production
Describe the platform, how often the application ships, and how database changes reach production today. The gap between those last two numbers is usually the whole conversation.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia