Loading the documentation…
A reload is what each Lake run does to the data already stored: it replaces the days the run covered, or swaps the whole table, depending on the table's sync type. Use this page to see exactly what a run replaces, why reloads work in whole days, and why a swap is sometimes refused.
| Sync type | What the run replaces |
|---|---|
| Full Reload (Truncate Insert) | The whole stored table, in one swap. If the load fails midway, the old data stays. Before the swap, the run checks the table's data safety guards. |
| Incremental Reload (Truncate Insert) | Only the days the window covers, each day as one whole block. Days outside the window keep the rows they had. |
| Incremental Reload Loop (Truncate Insert) | The same days, walked one day range at a time. The steps cover every window day exactly once: no gaps, no overlaps. |
| Full Reload (Upsert) and Incremental (Upsert) | The run merges by key into a new copy of the table, then swaps the whole table at once. Keys missing from the extract keep their rows. |
| Full Snapshot and Incremental Snapshot | Nothing is replaced. Each run adds its copy as a new version; read a past version with Snapshot From and Snapshot To. |
| Onetime | The whole table, in one swap, and only while the table is empty. |
On a table whose incremental type has Full Reload When Empty on, the first load into an empty table replaces everything in a single swap; later runs go back to replacing their window days. See Choose a sync type for how that first load is sized.
To compare the patterns before you pick one, see Choose a sync type and the Sync patterns guide.
A load never writes into the table while it reads the source. It collects the extract on the side and publishes it at the end:
The run's Sync Log entry records the publish as steps such as Table Replaced, Partitions Replaced or Partitions Cleared; Run logs and step messages explains each one.
Full Reload (Upsert), Incremental (Upsert) and Onetime rebuild the table's new state from the rows already stored and the fresh extract, then publish it in one swap:
An upsert run refuses to publish, and leaves the table unchanged, when it cannot be sure that newer rows win: the table has no primary key, its insert timestamp column is missing, the database clock looks older than the stored rows, or a change to the table is still being applied. The run ends Failed, and Lake troubleshooting lists each message with what to do.
An incremental reload works in whole days. Each day inside the window is one block, and the swap replaces the block as a unit instead of editing single rows. That is what makes updates and deletes inside the window land cleanly with the swap.
You can see a table's blocks on its Settings tab. The Storage card shows a Partitions count, and Truncate Partitions lists the days when you choose partitions to remove. See Run, stop and troubleshoot loads.
Each run replaces the days its window covers, day by day. Before a swap, the run checks that the fresh data lands inside those days. If the fresh data shares no day with the window, replacing would clear the window and put nothing back, so the swap is refused instead: the run ends, the days are not replaced, and the table keeps its data.
The refusal is recorded on the run; open its Error Stack in the Sync Log to read it (see Run, stop and troubleshoot loads). Check the table's date column settings and the run's Current Date. If the refusal repeats, redeploy the table so it is partitioned by its incremental column.
A Full Reload of a table that was created partitioned is refused as well, because a Full Reload replaces the whole table as one block. A Full Reload whose extract and table are both empty publishes nothing and records Table Replaced with The extract and the table are both empty; nothing to publish.
For other load failures, see Lake troubleshooting.
They stay exactly as they were. A run replaces only the days inside its window; changes older than the window are never picked up. See Choose a sync type.
The fresh data shared no day with the window the run was replacing, so the swap would have cleared those days and put nothing back. The run was stopped instead, and the table kept its data. Check the table's date column settings and the run's Current Date; if it repeats, redeploy the table so it is partitioned by its incremental column. Read the refusal in the run's Error Stack (see Run, stop and troubleshoot loads).
No. A load collects its rows on the side and publishes them at the end, as whole blocks: a full reload or an upsert run swaps the table as one operation, and each day of an incremental reload is replaced as a whole block, never single rows. If a load fails before it publishes, the table keeps exactly what it had.
No. A key the extract does not contain keeps its row, so deletes in the source never reach the Lake. An empty extract leaves the table unchanged. See How an upsert run merges.
No. The run collects the extract on the side and swaps the whole table at the end, so queries see the old data until the new data is complete. See What a query sees during a load.
When Full Reload When Empty is on and the table is empty, the first load runs as one full swap; later runs go back to replacing their window days. See Choose a sync type for how that first load is sized.
No. The loop type walks the window one day range at a time, and the steps cover every day of the window exactly once: no gaps, no overlaps. Each step replaces its own days as whole blocks. Set the step size with Loop Increment; see Choose a sync type.
No. A snapshot run attaches its copy as a new version instead of replacing days, and a past version stays readable with Snapshot From and Snapshot To. See Choose a sync type.
Because an incremental reload keeps its data in day blocks and swaps each block as a unit. That is what makes updates and deletes inside the window land with the swap; days outside the window are not read at all.
On the table's Settings tab. The Storage card shows a Partitions count, and Truncate Partitions lists the days when you choose partitions to remove. See Run, stop and troubleshoot loads.