Bidirectional Data Sync with n8n: Merge Node & Conflict Resolution

Keeping data synchronised between two systems is one of the most common automation challenges teams face. Whether you are syncing a PostgreSQL database with Google Sheets, keeping a CRM aligned with your marketing platform, or maintaining consistency between a production database and a reporting tool, a one-way sync often falls short. You need bidirectional data sync — changes made in either system flow to the other. n8n's Merge node makes this possible, but building a two-way pipeline requires understanding merge modes, conflict resolution strategies, and scheduling. This tutorial walks through exactly how to build a bidirectional sync workflow using n8n, the Merge node, and a few supporting nodes you already have access to.

Understanding the Challenge of Bidirectional Data Sync

A one-directional sync is straightforward — pull data from source A, transform it, push it to destination B. Bidirectional sync adds complexity because both systems are mutable. A record updated in system A might conflict with a newer update in system B. A record deleted in one system might need to be deleted in the other. Without careful design, you end up with overwritten data, duplicate records, or silent data loss.

The core challenges include:

• Conflict detection — determining which version of a record is the authoritative one when both sides have changed.
• Update propagation — ensuring a change on one side doesn't trigger a loop that writes the same change back to the origin.
• Deletion handling — deciding whether to soft-delete, hard-delete, or flag records for manual review.
• Schema alignment — mapping fields correctly between systems that may name or structure data differently.

n8n handles the plumbing. The Merge node provides the logic that makes bidirectional sync feasible without writing piles of custom code.

The Three Merge Node Modes You Need to Know

Before building the workflow, you need to understand how the Merge node operates. It offers three modes relevant to data sync:

1. Combine — merges two input streams into a single output by matching on a common field (like an ID or email). This is your primary tool for detecting which records exist on both sides and which are new on only one side.
2. Wait — holds one input until the other arrives, then passes both streams together. Useful when you need to fetch data from both systems before comparing them.
3. Merge By Fields — joins data from two inputs based on matching field values, similar to a SQL JOIN. You pick the fields to match on and define how records that don't match on either side should be handled.

Building a Bidirectional Sync: Postgres to Google Sheets

This example syncs a customer table in PostgreSQL with a Google Sheet. Changes made in either location propagate to the other. The workflow runs on a schedule, checks both sides, and applies the necessary updates.

Here are the nodes you will need:

1. Schedule Trigger — set to run every 15 minutes (or whatever interval fits your data freshness requirements). Use a Cron expression like */15 * * * *.
2. PostgreSQL (Select) — query all active records from your customers table. Include a updated_at timestamp and a sync_version field to track changes.
3. Google Sheets (Get All Rows) — pull all rows from the synced sheet. Ensure the sheet has a matching ID column and a last_synced timestamp.
4. Merge Node (Merge By Fields) — match records on the customer ID field. Set "Include unmatched from input 1" and "Include unmatched from input 2" to "Yes".
5. IF Node — route records based on whether they matched (update needed) or were unmatched from one side (insert needed).
6. PostgreSQL (Insert/Update) — for records that exist in the sheet but not in the database, insert them. For records with newer timestamps in the sheet, update the database row.
7. Google Sheets (Update Row / Append Row) — for records that exist in the database but not in the sheet, append them. For records with newer timestamps in the database, update the sheet row.

The Merge node outputs three groups of records:

• Matched records — exist on both sides. Compare timestamps to decide which side has the authoritative version.
• Unmatched from input 1 (Postgres) — records in the database that are not in the sheet. These need to be appended to the sheet.
• Unmatched from input 2 (Sheet) — records in the sheet that are not in the database. These need to be inserted into the database.

Conflict Resolution Strategies for Two-Way Sync

Conflicts happen when a record is updated on both sides between sync cycles. You need a deterministic rule to resolve them. Here are the most practical strategies you can implement inside the IF node:

1. Last-Write-Wins (LWW) — compare updated_at timestamps. The record with the most recent timestamp wins. Simple, but can lose data if two updates happen within the same sync interval.
2. Source Preference — designate one system as the authority. For example, always prefer the PostgreSQL value over the sheet value. This avoids conflicts entirely but means the secondary system is effectively read-only for certain fields.
3. Field-Level Merge — compare individual fields rather than entire records. If the database has a newer email but the sheet has a newer phone, keep both updates. This requires a Code node to implement the per-field comparison logic.
4. Flag for Review — when a conflict is detected, write the record to a review queue (another sheet or a Slack message) instead of applying either update automatically. This trades full automation for safety.

Scheduling Your Sync and Handling Errors

A bidirectional sync workflow should not run too frequently or too rarely. Every 15 minutes is a practical baseline for most business data. If your data changes faster, consider using a Webhook trigger instead of a Schedule trigger — have each system notify n8n when data changes rather than polling on a timer.

Error handling is critical in sync workflows. When a write operation fails halfway through (for example, the database update succeeds but the sheet update fails), you end up with an inconsistent state. Configure an Error Workflow in n8n to catch failures and log them. The Error Workflow can:

• Send a Slack alert with the failing node name and error message.
• Write the error details to a logging sheet for review.
• Stop the workflow from retrying automatically to avoid compounding the inconsistency.

For the sync to be truly reliable, each run should be idempotent — running it twice with no changes in between should produce the same result as running it once. The Merge node's unmatched record detection naturally provides this, but only if you handle the sync version field correctly.

Bidirectional Sync Best Practices in n8n

After building several sync workflows, a few patterns consistently reduce headaches:

1. Always include a unique identifier on both sides — a UUID or a composite key that never changes. Never rely on names or email addresses alone for matching.
2. Add timestamps to every record and update them on every write. Without timestamps, you cannot detect which side changed more recently.
3. Use a staging field to mark records that were written by the sync process. This lets you distinguish between user edits and sync writes, which is essential for breaking update loops.
4. Log every sync cycle — record IDs processed, actions taken (insert/update/skip), and any conflicts encountered. A simple Google Sheet or database table works as an audit log.
5. Test with a subset first. Run your sync workflow against a handful of records before scaling to your full dataset. The Merge node output is easy to inspect in n8n's execution view.

Running a bidirectional sync workflow requires a reliable n8n instance that stays online and executes on schedule. A managed, dedicated setup — like the one provided at n8nautomation.cloud — ensures your sync runs on time every time, with automatic backups and 24/7 uptime.

Bidirectional data sync removes the friction of maintaining two systems manually. With n8n's Merge node handling the diff logic and a well-designed conflict resolution strategy, you can keep your data consistent across databases, spreadsheets, and SaaS tools without writing custom sync scripts. Start with a simple two-system sync, add conflict handling iteratively, and scale the pattern to as many data sources as your workflows require.