MongoDB migration in either direction, with both databases in sync until you switch

A MongoDB migration is usually a question of fit, not of failure:

• A relational system has outgrown its tables. Records with many optional parts, or a structure that changes every release, fit documents better, so the team plans to migrate SQL to MongoDB.
• The workload has become relational. Reporting, joins and transactions across many records now dominate, and the move is MongoDB to PostgreSQL.
• A platform decision. One database for key-value and document workloads, or mobile apps that work offline and sync later, leads to Couchbase.
• Consolidation or hosting. Two estates become one, or data must move inside the Kingdom.

Each reason points to a different route. Our SQL or NoSQL decision guide lists what to measure in a workload before choosing a direction.

RelatedSQL or NoSQL decision guide

Copying each table into its own collection is the quickest way to start and usually the slowest way to run. A document store performs well when one read fetches what a service needs, so the work starts with access patterns:

• Embed or reference. Data read together, such as a customer and their addresses, is embedded in one document. Data that grows without limit or is shared, such as order history, is referenced.
• Keys and indexes. Designed for the queries the application actually runs, measured on production-shaped data.
• Transactions. Many multi-table transactions become a single-document write; the rest keep a multi-document transaction.
• Application queries. Rewritten service by service and tested against both databases during the parallel run.

Moving from MongoDB to PostgreSQL turns flexible documents into a schema the database enforces. That is often the point of the move, and also where surprises hide:

• Varying shapes. Documents in one collection rarely share one shape, so the real data is profiled first and the schema covers what is actually there.
• Nested arrays. An embedded array becomes a child table with a foreign key, or stays as a jsonb column where it is read as a whole. PostgreSQL's documentation describes both json and jsonb types; jsonb supports indexing.
• Types and missing values. Identifiers, dates and numbers are mapped to PostgreSQL types, and a missing field is told apart from one set to null.
• New constraints. NOT NULL and unique rules the old data never had to pass will reject some records; cleansing is planned work.

Our PostgreSQL migration page covers the target side.

Some teams leaving MongoDB want to keep the document model with different capabilities around it. Then Couchbase, which Interkey implements as a Couchbase technology partner, is worth assessing. According to Couchbase's documentation, it keeps key-value data and JSON documents in one store, queries documents with SQL++, holds data in memory and on disk, and synchronises with Couchbase Lite on mobile and edge devices. Couchbase Capella, its managed service, lists Google Cloud's Dammam region (me-central2).

Because the data usually stays JSON, remodelling is often smaller than a move to tables, though keys, indexes, queries and drivers still change. Our document database page has the detail.

Relateddocument database page

iblync is Interkey's own data migration and replication platform. Its website lists MongoDB, Couchbase, PostgreSQL, MySQL, SQL Server and Oracle among its connectors; which direction, version and edition your project needs is confirmed in the assessment, and a custom connector is built where a system is not yet covered.

• Initial load, then changes. Existing data is loaded once, then every insert, update and delete is copied while the source stays in service.
• Transformation in flight. Rows reshaped into documents, or documents flattened into rows, to the agreed model.
• Flow control. Throttled so it does not compete with production; if the target is down, changes queue rather than fail.
• Both sides live. Where both must accept writes for a period, iblync supports bi-directional sync with agreed conflict rules.

We publish no throughput figure: the pace of a NoSQL migration is set by how far the two models diverge, the data volume and the change rate, measured on your estate.

Relatediblync

Many Saudi organisations must keep certain data inside the Kingdom, under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa). A migration is a residency decision too: where the bridge runs, where staging copies sit and where backups land. The bridge, the target and the tooling can run on in-Kingdom infrastructure, and our data residency guide lists the questions to settle.

Interkey is a Google Cloud partner and an AWS partner; the target platform is chosen in the assessment. Support comes from Riyadh, through cutover and after.

Relatednca.gov.sasdaia.gov.sadata residency guide

We do not publish a price or a duration, because both are decided by the estate. The drivers are:

• how far the source model is from the target, and how much remodelling that needs;
• the number of services whose queries change;
• data volume, and how much of it changes while the migration runs;
• the downtime window the business will grant, and where the target must run;
• who carries the application changes, and who operates the database afterwards.