Sync MongoDB to MySQL via n8n MySQL Node and Date Triggers

Designing a reliable database sync requires a flexible n8n automation strategy that handles data mismatches and network retries gracefully. Databases serve different purposes: MongoDB excels at storing unstructured document schemas, while MySQL enforces strict relational integrity. When your application stack requires copying records from MongoDB into MySQL for structured reporting, you must bridge these distinct architectures. Relying on custom scripts often introduces high maintenance overhead, manual error handling, and silent failures. Using dedicated replication pipelines minimizes these risks and keeps your analytical tables fresh.

Why Sync MongoDB to MySQL Using n8n Automation

Using a reliable database sync pipeline provides major architectural benefits. MongoDB is a document database, making it ideal for high-write applications, real-time logging, and flexible web schemas where structural changes happen frequently. However, extracting insights, calculating financial summaries, and generating reports from multi-level nested JSON documents remains complex and slow. MySQL, with its traditional structured query language (SQL) interface, indexes relational data efficiently and connects to standard business intelligence tools.

Bridging this gap requires an intermediate system to poll data, validate schemas, and write updates. Creating a custom Node.js script or Python program to fetch, parse, and load records seems simple at first glance. Yet, this approach introduces technical debt. You must write custom retry logic, manage cron schedules on a server, and configure alert mechanisms for unexpected schema alterations.

Choosing a visual tool solves these operational headaches. You construct workflows visually, handle errors using dedicated failure branches, and view execution histories directly. If your database traffic spikes, hosting your workflow engines on high-quality, dedicated platforms is key. Running your setup on a managed instance from n8nautomation.cloud provides an isolated, performant hosting environment starting at only $4/month. This architecture bypasses standard server management and provides automatic backups, instant setups, and continuous uptime. Your instance is entirely dedicated to your workflows, ensuring heavy data sync jobs do not compete for resources with other web applications.

Prerequisites for Database Replication

Before building your integration, compile the necessary credentials and create matching target schemas. You need direct connection details for both your source MongoDB cluster and target MySQL server.

Ensure you prepare the following prerequisites:

• A valid MongoDB connection URI, including credentials, host addresses, and authentication database details.
• A target MySQL database with a schema configured to store incoming data.
• Network firewall rules allowing your workflow platform to query both databases.
• An active n8n instance. If you run a self-hosted server, you can migrate workflows to a managed n8nautomation.cloud instance within seconds using the included migration tool. This utility safely transfers workflows via the URL and API key of both servers, though security standards require manually pasting your credentials again.

For this guide, we use a sample relational table. Run this DDL statement inside your target MySQL database:

CREATE TABLE IF NOT EXISTS users (
    mongodb_id VARCHAR(24) PRIMARY KEY,
    first_name VARCHAR(100),
    last_name VARCHAR(100),
    email VARCHAR(255),
    purchase_count INT,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Ensure the corresponding document structure in MongoDB looks similar to this:

{
  "_id": {"$oid": "64f3c0b0a1d4b2e88a3f9e1a"},
  "personal": {
    "firstName": "John",
    "lastName": "Doe"
  },
  "contact": {
    "email": "john.doe@example.com"
  },
  "stats": {
    "purchases": 12
  },
  "lastModified": "2026-08-05T14:30:00.000Z"
}

Preparing these target structures guarantees that mapping dynamic documents into rigid tables does not throw index or data type errors.

Setting Up the Schedule Trigger Node

The first block in our replication sequence is the Schedule Trigger node. Because databases constantly process operations, syncing everything continuously degrades network and query performance. A scheduled, polling interval minimizes computational waste.

Add a Schedule Trigger to your n8n workspace. To configure this node, follow these configurations:

1. Set the 'Trigger Interval' parameter to 'Hours'.
2. Input '1' into the hours input box to repeat the sync hourly.
3. Choose a specific minute offset, such as five minutes past the hour, to avoid peak high-load intervals on shared databases.

To avoid missing any documents during a brief API freeze or server delay, configure a rolling chronological window. Instead of checking exactly for documents updated within the last 60 minutes, query records updated within the last 65 minutes. This creates a five-minute data overlap.

While this overlap fetches some records twice, our downstream MySQL execution query uses upsert rules to handle duplicates cleanly. This preventative mechanism prevents silent sync omissions.

Calculate the dynamic start time using n8n expressions. In your query parameters, use this syntax:

{{ $today.minus({ minutes: 65 }).toISO() }}

This expression evaluates during run time to generate a standard ISO 8601 date string, ensuring your MongoDB query targets the correct time range relative to the execution timestamp.

Retrieving New Documents from MongoDB

After the schedule executes, the workflow queries MongoDB for updated records. Drag a MongoDB node onto your canvas and link its input to the Schedule Trigger output.

Configure the MongoDB node with the following credentials and parameters:

• Set 'Resource' to 'Document'.
• Set 'Operation' to 'Find'.
• Input your collection name, such as 'customers', into the collection input field.
• Insert a query selector to isolate records modified during our overlap window.

In MongoDB, document dates are often stored as BSON Date types. To query these dates within n8n, you must construct a valid JSON statement containing MongoDB-specific query operators. Put this exact expression inside the 'Query' block:

{
  "lastModified": {
    "$gte": {
      "$date": "{{ $today.minus({ minutes: 65 }).toISO() }}"
    }
  }
}

This query requests all documents where 'lastModified' is greater than or equal to the ISO string calculated by n8n.

By using the built-in expression parser, you guarantee that MongoDB translates the string into a valid query representation.

Make sure the query runs successfully by adding a dummy document with a recent timestamp to your collection. Click 'Listen' or 'Test step' on your MongoDB node to verify the output. The node returns an array of JSON objects containing nested attributes, dynamic field structures, and MongoDB’s default hexadecimal object identifier. This payload requires structural normalization before writing it to a relational table.

Transforming Data with the Code Node

MySQL expects structured, single-level columns. It will reject objects containing arrays or deeply nested sub-documents unless you map them specifically. To bridge this structural divide, place a Code node after your MongoDB node.

Set the Code node mode to 'Run Once for All Items'. This mode takes the complete collection array and processes it in a single JavaScript block, saving execution overhead compared to running individual operations.

Paste this JavaScript script to flatten the incoming MongoDB document schema into clean key-value pairs:

return items.map(item => {
  const raw = item.json;
  
  // Extract MongoDB hexadecimal ID safely
  const mongoId = raw._id && typeof raw._id === 'object' 
    ? raw._id.$oid || Object.values(raw._id)[0] 
    : raw._id;

  return {
    json: {
      mongodb_id: mongoId || '',
      first_name: raw.personal && raw.personal.firstName ? raw.personal.firstName : '',
      last_name: raw.personal && raw.personal.lastName ? raw.personal.lastName : '',
      email: raw.contact && raw.contact.email ? raw.contact.email : '',
      purchase_count: raw.stats && typeof raw.stats.purchases === 'number' ? raw.stats.purchases : 0,
      updated_at: raw.lastModified || new Date().toISOString()
    }
  };
});

This script performs vital verification routines:

1. It processes the MongoDB `_id` structure, whether it arrives as an object with an `$oid` string or a raw string value.
2. It evaluates nested structures like `personal.firstName` and `contact.email` using logical operators to prevent execution crashes if those values are undefined or null.
3. It formats numeric elements and timestamps, satisfying MySQL column constraints.

The output of this node is a flattened, tabular JSON array. Each element contains direct key-value pairs that map straight to your MySQL relational schema columns.

Upserting Records with the MySQL Node

Now that the dataset is completely flat and validated, add a MySQL node to execute the database upsert logic. This node will write newly created documents or update existing rows where the keys match.

Set up your MySQL node using the following parameters:

• Select your target MySQL credentials.
• Choose 'Execute Query' as the primary operation.
• Construct a query that handles duplicate key violations using an upsert strategy.

To update records that already exist in MySQL without throwing database errors, use the `ON DUPLICATE KEY UPDATE` clause. Enter this SQL query in the 'Query' field:

INSERT INTO users (mongodb_id, first_name, last_name, email, purchase_count, updated_at)
VALUES (:mongodb_id, :first_name, :last_name, :email, :purchase_count, :updated_at)
ON DUPLICATE KEY UPDATE
  first_name = VALUES(first_name),
  last_name = VALUES(last_name),
  email = VALUES(email),
  purchase_count = VALUES(purchase_count),
  updated_at = VALUES(updated_at);

By using colon notation (like `:mongodb_id`), the MySQL node binds values automatically from the incoming JSON keys produced by your Code node. This automated binding protects your relational database against standard SQL injection vulnerabilities.

For high-performance data operations, execute this query for all incoming items in a single step. The MySQL node handles iterating through the incoming JSON list, executing the SQL statement for each row sequentially.

If a user record changes in MongoDB, the script finds the matched `mongodb_id`, updates the modified fields, and adjusts the updated timestamp accordingly. New profiles are added as fresh rows directly.

Monitoring and Optimizing Your Database n8n Automation Syncs

Running data-heavy sync processes requires careful performance tuning and oversight to avoid operational failure. When managing large volumes of rows, you must plan for network disconnects, schema modifications, and memory exhaustion.

To construct a complete error containment policy, attach an Error Trigger node to your replication workflow. Connect it to an alternative sub-workflow that fires notifications to your messaging channels if any step fails.

If a database credential expires or a server loses connection, the Error Trigger catches the failure, halts the sync, and logs the specific error message.

Inspecting exact execution traces is critical for advanced developers troubleshooting performance lags or network timeouts. Managed options from n8nautomation.cloud let users view execution logs within the system dashboard. This interface displays detailed system outputs and backend logs directly, resolving performance mysteries without complex terminal command configurations.

Additionally, the dedicated hosting plan lets you change your custom domain name at any point. This makes it easy to align your automation services with evolving branding or security requirements. Setting up your data synchronization tasks on an isolated virtual machine guarantees that your business automations run reliably without maintenance friction.

\