Batch Syncer — Cloud vs. On-Prem Storage
Why This Matters
Knowing where batch files live — and why they live there — helps you understand what happens during pod restarts, deployments, and on-prem machine reboots. It also introduces you to PVC (Persistent Volume Claims) as a concept.
What You'll Learn
- Why batch files can't be stored in pod memory for cloud SyncApps (pod restarts lose in-memory data)
- How cloud SyncApps use Persistent Volume Claims (PVCs) to store batch files persistently
- Why on-prem SyncApps store batch files on the customer's machine (network optimization)
- Why storing on-prem batch files in the cloud would defeat the purpose of the Batch Syncer
- Brief introduction to Cursor Syncer — a newer approach for very high-volume data (mid-market, multi-office)
Watch Video
Lesson Summary
Cloud SyncApps store batch files in a Persistent Volume Claim (PVC) — cloud storage attached to the Kubernetes pod but independent of it. Pod crashes or restarts don't affect the batch files. On-prem SyncApps store batch files on the customer's machine: moving them to the cloud would require sending data over the network just to compare hashes, defeating the optimization. The Cursor Syncer is mentioned as a newer alternative for high-volume scenarios (mid-market, multi-office accounts with massive data), but is beyond the scope of this KT.