How Sync Works
This guide explains the core concepts behind Sync or Swim’s synchronization technology. Whether you’re evaluating the platform or getting started with your first sync, this overview will help you understand what’s happening under the hood.
What is Bidirectional Sync?
Section titled “What is Bidirectional Sync?”Most data integration tools only move data in one direction—from a source to a destination. When you need changes to flow both ways (like keeping a database and CRM in sync), you typically need to build two separate pipelines and handle conflicts manually.
Sync or Swim is bidirectional by default. When you update a customer record in PostgreSQL, the change appears in Salesforce. When your sales team updates that same record in Salesforce, the change flows back to PostgreSQL. Both systems stay in sync automatically.
How Changes Are Detected
Section titled “How Changes Are Detected”Sync or Swim detects changes in real-time using the fastest method each data source supports:
| Data Source | Detection Method | Typical Latency |
|---|---|---|
| PostgreSQL | Logical replication | Sub-second |
| MySQL | Binary log (binlog) | Sub-second |
| Salesforce | Streaming API | ~1 second |
| Other sources | Smart polling | Configurable (seconds to minutes) |
You don’t need to configure triggers, write change capture logic, or worry about performance impact on your production databases. Sync or Swim handles all of this automatically.
How Conflicts Are Resolved
Section titled “How Conflicts Are Resolved”When the same record is modified in two places at once, a conflict occurs. Sync or Swim provides two strategies for handling this:
System of Record Mode
Section titled “System of Record Mode”You designate one system as the “source of truth.” When conflicts occur, that system’s version wins. This is ideal when:
- One system is the authoritative source for certain data
- You want predictable, automatic resolution
- Your workflow has a clear primary system
External ID Mode
Section titled “External ID Mode”Both systems maintain their own identities, linked by a shared identifier. Changes are merged based on timestamps or custom rules. This is ideal when:
- Both systems are actively used for data entry
- You need more granular control over conflict resolution
- Records may be created independently in either system
How Relationships Are Preserved
Section titled “How Relationships Are Preserved”Real-world data isn’t flat—customers have orders, orders have line items, contacts belong to accounts. Sync or Swim understands these relationships and handles them automatically:
-
Dependency ordering: Parent records sync before children. If you’re syncing customers and their orders, customers are created first so orders have somewhere to link.
-
Reference resolution: Foreign keys in your database map to lookup relationships in your CRM. Sync or Swim maintains these links as data moves between systems.
-
Cascade handling: When related records are updated together, changes are applied in the correct order to maintain data integrity.
This means you don’t end up with orphaned records, broken references, or data that only makes sense when you squint at it.
Monitoring and Recovery
Section titled “Monitoring and Recovery”Every sync operation is logged with full context:
- What changed: The specific fields and values that were updated
- When: Precise timestamps for when changes were detected and applied
- Why: The source of the change and any transformation applied
- Status: Success, pending, or failed with detailed error information
If something fails—network blip, temporary API limit, schema mismatch—Sync or Swim automatically retries with exponential backoff. For persistent issues, you can investigate in the dashboard and retry manually with one click.