Documentation

Export Data - JSON, CSV, SQL

MongoSync

MongoSync copies and migrates data between any two connections you have saved — local to Atlas, one cluster to another, or across databases on the same server. Pick a source and a destination, choose exactly what to move, reshape fields on the way, and run it as a one-time copy or a continuous sync. Everything happens in a single guided flow without leaving the app.

Quick Start

Set up and run your first sync in a few steps:

  1. Open MongoSync from the command palette, or right-click a database/collection in the sidebar and choose Sync.
  2. On the Source step, confirm the source connection and database.
  3. Add one or more targets (a saved connection + database) and define sync rules mapping each source collection to a target.
  4. Optionally add a filter, a transformation mapping, and pick a mode (full or continuous).
  5. Review the plan and click Save changes to start. Watch progress live in the Monitor tab.

What You Can Do

MongoSync is built around moving a slice of data, not just whole databases. Common jobs:

Job How MongoSync handles it
Promote local → Atlas Point the source at your local replica set and the target at your Atlas connection; collections, indexes, and documents copy in one pass.
Keep dev / staging / prod in step Run a continuous sync so inserts and updates on the source flow to the target as they happen.
Seed a test environment Apply a query filter to copy only the documents you need, and drop or mask sensitive fields with a transformation mapping.
Rename or merge collections Map a source collection to a new target name, or merge it into an existing collection.
Migrate MongoDB → SQL Choose a SQL connection (PostgreSQL, MySQL, and more) as the target and MongoSync flattens documents into rows.

The Sync Wizard

A sync job is configured across four steps at the top of the editor — Source, Rules, Options, and Review — with a live Topology panel on the right showing the source, the number of rules, and each target as you build. Switch between Setup and Monitor at any time.

1. Source

Pick the connection and database the data comes from. A live preview shows the source cluster type (for example, a local replica set) and how many collections are available to sync.

2. Targets & Rules

Add one or more targets — each is a saved connection plus a destination database. Then add sync rules, one per collection you want to move. Each rule has:

Field Meaning
Source The collection to read from (e.g. visits).
Target The target and destination collection/table (e.g. T1 · mongo_visits). Map to a new name or an existing one.
Trans An optional transformation mapping applied as documents move (see below).
Filter An optional query that limits which documents are synced.

3. Options

Job-wide settings: the sync mode (full copy vs. continuous), auto-start behavior, disk-use allowances for large scans, and per-rule conflict handling.

4. Review

A summary of everything the job will do — source, every target, and each rule — plus an estimate of the documents involved before you commit. Click Save changes to start.

Filtering Documents

You rarely need to move everything. Each rule can carry a filter so only matching documents sync. The filter editor has two modes:

  • JSON — a raw MongoDB query, e.g. {"status":"active"}. Leave it empty to sync the whole collection.
  • Visual — a point-and-click query builder for the same filter, no syntax required.

When the source is a SQL connection, the filter is expressed as a SQL WHERE predicate instead (for example, status = 'active' AND region IN ('eu','us')), applied server-side in the SELECT.

On Filter Mismatch

For a continuous sync, documents can stop matching the filter after they've already been copied (for example, an order changes from active to archived). Each rule decides what happens to those documents on the target:

  • Keep on target — leave the already-synced document in place (default).
  • Delete from target — remove it so the target only ever holds documents that currently match the filter.

Transformation Mappings

Reshape data as it moves. Point MongoSync at a collection and it auto-detects every field — nested paths and BSON types included — so a 45-field document maps itself in one click. From there you can fine-tune each field: cast types on the fly, compute values with scripts, and control how each field lands. Save a mapping once and reuse it across every sync.

Field Mapping

The mapping editor is a grid of field rules. Use Generate Field Mappings to sample source documents and auto-populate the table, or Add Field to build rules by hand. Each row defines:

Column Description
Source Path The field to read, including dotted nested paths (e.g. address.city).
Type (source) The detected BSON type of the source field.
Value Script An optional expression to compute or transform the value in flight.
Target Path Where the value lands on the target document/row.
Type (target) The type to cast to as it's written.
Map Mode How the value is applied to the target field (see below).

Turn on Include unmapped fields to pass through any source fields not listed in the mapping as-is; leave it off to write only the fields you've explicitly mapped. A Timeout caps how long a single document's transformation may run.

Map Modes

Map modes give per-field control over how a value is written to the target — for example, only setting a field when it doesn't already exist, or always overwriting. This lets one mapping both create new documents and top up existing ones without clobbering data you want to keep.

Value Scripts

A value script transforms a field as it moves — concatenate names, convert units, reformat dates, derive a status, or redact a value. Scripts run per-document during the sync, so the transformation applies to every row that passes through the rule.

Data Source & Script Variables

Beyond individual fields, a mapping can define data source variables (values looked up or pulled in from elsewhere) and script variables (reusable values available to your value scripts) so common logic is defined once and shared across every field rule.

Sync Modes

Mode Behavior Use when
Full A one-time copy of every matching document from source to target, then the job finishes. Migrations, seeding a new environment, or a one-off snapshot.
Continuous An initial full copy followed by ongoing capture of inserts, updates, and deletes as they happen on the source. Keeping two environments in step over time.

With Auto-start enabled the job begins syncing as soon as it's saved, rather than waiting for a manual start.

Conflict Handling

When a document already exists on the target, MongoSync decides whether to insert it as new, upsert (update on match), or skip it. Combined with map modes and the on-filter-mismatch setting, this lets you choose between a clean overwrite and a careful merge that preserves target-only data.

Monitoring a Sync

Switch to the Monitor tab to watch a running job live — per-rule progress, counts, and status update as documents move. Because the sync runs in the background, you can close the editor and come back to it; the job keeps going. For a continuous sync the monitor stays active, showing changes as they stream through.

Cross-Engine Sync (MongoDB → SQL)

A target doesn't have to be MongoDB. Choose a SQL connection — for example a PostgreSQL database — and MongoSync flattens each document into a row, using your field mapping to cast BSON types into SQL columns and map nested paths onto flat column names. Filters on a SQL source are written as WHERE predicates; mappings handle the shape conversion in both directions.

Pro Tips

  1. Start with a Full sync and a tight filter to validate the mapping on a small slice before switching a rule to Continuous.
  2. Use Generate Field Mappings first, then tweak only the fields that need casting or scripts — it's far faster than building the grid by hand.
  3. For continuous syncs, decide the On Filter Mismatch behavior deliberately: Delete from target keeps the target an exact mirror of the filter, while Keep on target preserves history.
  4. Turn off Include unmapped fields when seeding non-production environments so sensitive fields never leave the source unless you've mapped them.
  5. Save reusable transformation mappings — the same mapping can be applied across multiple rules and jobs.
  6. The Review step's document estimate is your last checkpoint before data moves — read it before saving a large job.

Ready to try VisuaLeaf?

Download and start managing your MongoDB databases with ease.

Download Free Trial