Zagru BridgeDatabase migration, sync and consistency proof
Migrate. Sync. Prove it.
Move SQL Server and MongoDB estates to PostgreSQL, keep live systems in step, and prove — to the column — that both sides match. Every fix is a change set someone reviewed, approved and can roll back.
Early access — we are onboarding a small number of design partners.
- rows per project — design target
- ≥ 1 billion
- per project — design target
- ≥ 1 TB
- third-party engines inside
- 0
Illustrative interface
Not sampled. Proven.
The key space is compared segment by segment; any disagreement is halved until one row and one column remain.
Illustration: Bridge splits the key space into segments, compares counts and hashes, narrows the one mismatching segment by halving it until a single row and column differ, then fixes it through an approved change set — consistency 100%.
What it does
Five verbs. One engine.
- 01
Query — one SQL across every source
Query every connected source as if it were one database, with Bridge's own federated engine pushing work down to SQL Server, PostgreSQL, MySQL, Oracle and MongoDB.
- 02
Migrate — billions of rows, resumable
Partitioned, resumable and verifiable loads. Stop a job halfway and it picks up exactly where it left off.
- 03
Sync — two live systems, one truth
Change data capture plus scheduled reconciliation keep an old and a new system aligned while you move over.
- 04
Prove — down to the column
Missing, extra and different records, found exactly — not estimated from a sample, unless you ask for one.
- 05
Align — fixes you can undo
Differences become change sets: reviewed, approved, audited, applied with before-images and reversible.
How it works
Connect. Map. Load. Reconcile. Align.
Data rows stay in your network the whole way; the control plane only ever sees metadata, counts, hashes and masked samples.
Connect
An agent inside your network discovers sources and targets, read-only by default.
Map
Mapping Studio pairs fields visually or in YAML, flags risks and blocks production runs until coverage is fully decided.
Load
Partitioned loads stream into staging and merge — resumable at any point.
Reconcile
Segments are counted and hashed; differing segments are bisected down to the row and the column.
Align
Change sets fix what differs — after review and approval — and continuous sync keeps it that way.
Illustrative interface
Map it. Then change only what was approved.
Mapping Studio flags the risks before the first row moves; every fix is a change set with a before-image.
In depth
The mechanics behind the proof.
Mapping Studio
- Visual mode for business users; expressions, SQL and YAML for experts — always in sync
- Source tree with field paths, types and presence
- Risk flags: collation, empty string vs NULL, datetime precision, truncation
- Suggested mappings with confidence and before/after preview
- No production run until coverage is 100% decided
Reconciliation
- Key space split into segments; count plus order-independent hash
- Bisection narrows differences to row and column
- With push-down, equal tables are proven equal without moving rows
- Results: only in source, only in target, different, duplicate or invalid key, transform error, in flight
- Exact, counts-only or sampled modes
Sources and targets
- MongoDB → PostgreSQL
- SQL Server → PostgreSQL
- MySQL and Oracle
- Excel, CSV and Parquet as sources
Its own engine
- Federated SQL engine, load pipeline, CDC readers and reconciliation — all Bridge code
- Go data plane, a single static binary
- No Trino, Spark, Kafka, Debezium or Airbyte
- Agents for Linux, Windows and macOS
Security and data
Your data never leaves your network.
Bridge was designed for the migrations nobody is allowed to get wrong.
Read-only by default
Sources are connected read-only unless you decide otherwise.
Rows stay home
Outbound-only agents move data inside your network; the control plane sees metadata, counts, hashes and masked samples only.
Deterministic masking
Turkish ID numbers, IBANs, phone numbers and e-mail addresses are masked consistently wherever samples are shown.
Encrypted and mutually trusted
AES-256-GCM for secrets and mutually authenticated agent enrolment.
Nothing dropped silently
Target objects are never dropped without a separate, explicit approval.
Audited end to end
Every change set, approval and rollback is recorded.
In the suite
Sold on its own. Stronger together.
Bridge moves data out of legacy systems into Zagru One — and proves it arrived intact. It migrates and reconciles SQL Server, MongoDB, MySQL and Oracle estates to PostgreSQL for any application, so it is sold on its own.
Questions
What buyers ask us first.
Is the reconciliation sampled?
No. It is exact by default — every key, every column. Counts-only and sampled modes exist for when you choose them.
How large can a project be?
Bridge is designed for at least one billion records and one terabyte per project. We publish performance figures only from measurement; in development, a paused job resumed and finished at exactly 60 million rows.
Does our data pass through your servers?
No. Agents run inside your network and move rows there. The control plane receives metadata, counts, hashes and masked samples only.
Can it write to our source database?
Sources are read-only by default. Changes are applied only through approved change sets, with before-images and rollback.
Does it use AI?
No AI runs in the data path. Every result is reproducible.
Is it available today?
Zagru Bridge is in early access. We are looking for design partners planning SQL Server or MongoDB moves to PostgreSQL.
Tell us what you need to move.
Bring the migration you keep postponing. We'll show you how to prove it.
Or write to hello@zagru.com