Full Sync vs. Partial Sync
Why This Matters
The decision to do a full sync vs. partial sync has major performance implications. Understanding the factors that drive this decision helps you design efficient integrations and debug sync performance issues.
What You'll Learn
- Full sync: fetching all records for an entity from the PMS every cycle
- Partial sync: fetching only records modified/added since the last sync cycle
- The ideal model: full sync once (first onboarding), partial sync forever after
- Factors driving sync frequency decisions: data change rate, API throttling, slow APIs, data volume, single-threaded execution
- Why cloud PMSs generally support partial sync but on-prem PMSs often don't
Watch Video
Lesson Summary
Full sync fetches all records; partial (delta) sync fetches only what's changed since the last run. The ideal: full sync once at onboarding, partial sync every cycle thereafter. But this isn't always possible. Factors that prevent partial sync: PMS APIs that don't support modified-time queries, on-prem tables without last-modified columns, or tables where the column isn't updated properly. SyncApp runs in a single thread — a slow entity can delay others. Cloud PMSs almost always support partial sync for patients and appointments. On-prem PMSs commonly require full syncs due to schema limitations.