iblync · Synchronization
Database synchronization between systems that were never built to share data
Database synchronization keeps two or more databases holding the same data, so a change made in one system reaches the others. iblync is Interkey's own platform for it: continuous real-time replication between heterogeneous systems, including bi-directional synchronization where both sides accept writes. Interkey delivers it with the team that operates it, from Riyadh, and prices it by quotation.
In short
- What it is: iblync keeps a source and a target database in step by applying changes continuously, so neither has to be copied again by hand.
- Modes: one-time and phased migration, continuous real-time replication, and bi-directional synchronization.
- Who it is for: database and platform architects, data engineering teams and the technology leaders who own a modernisation.
- Where it runs: iblync's own site says it deploys on any cloud platform or on-premises. Interkey confirms the deployment for each engagement.
- How it is bought: by quotation, priced by source system, target system and data volume.
One-way, two-way or one-time: which kind of database synchronization you need
| Kind | What moves | Typical use |
|---|---|---|
| One-time or phased migration | The data is moved to the target once, in stages if needed | A database modernisation, a platform consolidation, a move to or from cloud |
| One-way replication | Changes flow from the source to the target; the target is read-only for that data | A reporting or search copy, a standby copy, a bridge during migration |
| Bi-directional synchronization | Both systems accept writes and each side's changes reach the other | Old and new systems used together during a transition, or two live applications |
Choose the simplest kind that meets the need. One-way replication has one source of truth and is easier to run. Use two-way synchronization only where the business genuinely needs both systems to take writes.
What iblync does for database synchronization
iblync is built for the case where a vendor's own tooling stops at the boundary: source and target use different engines and rarely share a data model. It covers three jobs:
- Migration. Moving data to a target that was not designed to receive it. Workflows are configured, not hand-coded, which makes a second migration cheaper than the first.
- Replication. Continuous real-time replication, including bi-directional synchronization. This is what supports parallel running, with old and new systems live and in step for as long as the cutover plan needs.
- Flow control. Throttling and control of resource use, so replication does not compete with production for capacity. When a target becomes unavailable, changes queue instead of failing, and the queue is processed when the target recovers.
iblync's own site also states that an interrupted migration can resume where it stopped, and that validation uses checksums and row counts. Ask us how the acceptance checks for your data would be set.
Systems iblync's website lists
| Role | Systems listed |
|---|---|
| Sources (relational) | Including MySQL, PostgreSQL, SQL Server and IBM DB2 |
| Targets (NoSQL and other) | Including Couchbase and Neo4j, and other NoSQL and search systems |
| Also listed | Apache Kafka, Apache Spark, Amazon S3 |
iblync's site says its connector set is actively extended, and that custom connectors are built for systems it does not yet cover. So an unsupported system is a connector to build, not a reason the project cannot proceed. Which sources and targets are in scope for you is settled in scoping.
Conflict rules: the decision that matters in two-way synchronization
When both sides accept writes, the question is what happens to a record changed in both places. That is a design decision before it is a performance one, and no tool settles it for you. Decide in scoping:
- which system owns each type of record;
- how a conflict is resolved when the same record changes on both sides;
- how much lag between the two systems the business can accept.
Where you can, keep ownership one-way per record type and use two-way synchronization only where it is needed. Our change data capture guide explains how changes are detected and what can go wrong.
Relatedchange data capture guide
How a synchronization project runs
-
Scope.
Source and target systems, data volume, how much of it changes while the work runs, and the downtime window the business will grant.
-
Initial load.
The bulk of the data is moved once, throttled so it does not compete with production.
-
Continuous replication.
Changes since the load are applied continuously, with queueing if the target goes away.
-
Parallel running.
Both systems stay live and in step for as long as validation and the business require.
-
Cutover.
The switch happens on the business's schedule, with the source still there.
How iblync is bought and supported in Saudi Arabia
iblync is an Interkey product, delivered with the team that operates it rather than licensed and left. There is no published price list, because source systems, target systems and data volume move the answer too far for one to be meaningful. Scoping those three produces a number.
A first conversation needs only the source and target systems, a rough data volume and the downtime window you can grant. When this is the wrong fit: if both systems come from the same vendor and that vendor supplies a supported native migration path, that path is usually cheaper and better supported. We will say so.
Questions buyers ask
What is the difference between database synchronization and replication?
Replication usually means copying changes one way, from a source to a target. Synchronization often means both systems accept writes and each side's changes reach the other. iblync supports continuous replication, including bi-directional synchronization.
Can the two databases be different products?
Yes. iblync is designed for systems that were not built to exchange data, for example a relational source and a NoSQL target. Its website lists the sources and targets it connects to.
What happens to a record changed on both sides?
That is a rule you set in scoping: which system owns the record, or how a conflict is resolved. We recommend keeping ownership one-way per record type where you can.
What if the target database is down for a while?
Changes queue instead of failing, and the queue is processed when the target recovers. Throttling also limits how much capacity replication takes from production.
Where does iblync run?
iblync's site states it deploys on any cloud platform or on-premises. For your project, Interkey confirms where it runs and whether data leaves your environment before work starts.
How much does it cost?
By quotation, against the source systems, target systems and data volume in scope. Tell us those three and the downtime window, and we reply with a first scope.
Next
Related pages
Next step
Scope a synchronization project
Tell us the source and target systems, the data volume, whether both sides take writes, and how much downtime the business will grant. The reply comes from the team that would run it.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia