The data platform practice
Database modernisation in Saudi Arabia
Nobody wakes up wanting a new database. They want out of the one they have: the latency that grows with concurrency, the licence renewal that arrives like a ransom note, the schema change that takes a quarter. This practice exists for that moment, including the times when the right answer is to stay and tune.
Triggers
What actually justifies a data platform change
Platform changes are bought under pressure, and pressure invites bad diagnosis. Match the symptom to the honest response before any vendor conversation, and note how many rows do not end in a migration.
| The symptom | What it usually means | The honest response |
|---|---|---|
| Latency degrades as concurrency grows | The workload has outgrown a single-node design | A genuine trigger, once tuning and read replicas are exhausted. This is the core case for a distributed platform. |
| The licence renewal is punitive | A commercial problem wearing a technical costume | Sometimes a migration; sometimes a negotiation. Run the numbers on both before letting a renewal date design your architecture. |
| Schema changes take months | Process and coupling, at least as much as technology | A document model genuinely helps some of this; it fixes none of the organisational half. Diagnose before prescribing. |
| Caching layers keep multiplying | The read path has outgrown the database, and invalidation bugs are the tax | A real signal: a memory-first distributed platform collapses cache and store into one layer with one consistency story. |
| Mobile and field apps need offline | A requirement the current platform simply does not have | One of the few clean cases: sync-capable platforms exist for exactly this, and bolting sync onto a relational core does not go well. |
| “We should be on NoSQL” | Fashion, unless a row above is also true | Stay. A working relational system serving its load is an asset, and the assessment will say so in writing. |
The boundary
What this practice is, honestly
A boundary worth stating
Interkey works across relational and NoSQL platforms: database administration, data modelling and data engineering are core practice, and the distributed document platform it implements and operates as a partner is Couchbase. That is a boundary worth stating, because a page that claims neutrality across every database on earth is claiming to be shallow everywhere.
There are two different kinds of thing in that sentence, and the difference matters when you are deciding who is accountable for what. Couchbase is another company’s platform, which Interkey implements and operates. Iblync is Interkey’s own product, built in Saudi Arabia, and it is what moves and replicates the data between whatever you are on and whatever you are moving to. A migration engagement usually involves both: the destination is frequently a partner platform, and the mechanism that gets you there is not.
What keeps the advice honest is the shape of the practice, not a neutrality badge: the assessment is paid to produce a recommendation, including “stay where you are” and “this wants a relational tune-up, not a migration”, and the workload table on the Couchbase page lists the cases where that platform is the wrong answer, in public. A practice that cannot name a bad-fit workload for its own partner platform should not be trusted with a good-fit one.
The Saudi layer
Residency decides the deployment model before features do
For regulated Saudi workloads the first platform question is not features but geography: managed database clouds run in published regions, and for the major document platforms those regions, as of August 2026, sit near the Kingdom rather than in it. Hyperscaler regions inside Saudi Arabia have been announced across the industry; announced is not live, and a procurement decision deserves the current map, checked on the day, not a roadmap slide.
The practical consequence: workloads whose data must stay in-Kingdom point to self-managed platforms on infrastructure you control, and self-managed means somebody designs, patches, monitors and upgrades the cluster for years. That somebody is the real price of the residency requirement, and pricing it early is kinder than discovering it at go-live. It is also, not coincidentally, the operations work this practice sells, so weigh that disclosure as you read it.
Go deeper
The data platform library
Iblync: migration and replication
Interkey’s own platform for moving and replicating data between systems that were never designed to talk to each other.
Migration guideHow enterprise database migrations actually run
Assessment, modelling, dual-run, cutover and rollback: the sequence that keeps a migration from becoming an outage.
ImplementationCouchbase implementation in Saudi Arabia
The partner platform: migration engineering, in-Kingdom deployment, and the honest table of when it is the wrong answer.
Technical guideData residency thinking, applied to telemetry
The same in-Kingdom reasoning one layer up: a useful companion for the same compliance conversation.
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
What does a data platform assessment produce?
A written recommendation with its reasoning: whether the workload justifies a platform change at all, which platform class fits if so, the impact list for the application team, the deployment model the residency position allows, and a migration sequence with the do-nothing option costed alongside. It is designed to be defensible in front of your own architects, which is why “stay put” is a real possible outcome.
When is NoSQL the wrong answer?
When the workload is analytical rather than operational, when the core logic is genuinely relational and transactional, when the current platform is simply not in trouble, or when nobody will own a distributed system in production. The disqualification table exists so that conversation happens before scoping, not after go-live.
Can a migration run without downtime?
Without meaningful downtime, yes, and that is the only way this practice plans them: continuous sync from the legacy system, dual-running, traffic moved in reversible increments, and a rehearsed rollback. The migration guide walks the whole sequence.
Who operates the platform afterwards?
A named owner, decided before go-live: your DBAs, trained and handed a documented platform, or Interkey’s team operating it on the Saudi working week from Riyadh. The unacceptable answer is silence, which is how distributed databases become outages with a delay on them.
Next step
Put a workload in front of the engineering team
Name the system, the database under it, and the incident or limit that started this conversation — that is enough for a first opinion on whether change is justified.
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
Elsewhere