An archives network's collection-management system stamps every catalogue record with a reliable LastModifiedUtc column whenever a record is re-described or corrected. The catalogue holds millions of records, but only a small fraction change on any given day. Which loading pattern is the best fit for refreshing the Lakehouse copy?
Select an answer to reveal the explanation.
Short Explanation
Think of a watermark like a bookmark: it tells you exactly where you stopped reading last time, so you only pick up the new pages. With a trustworthy LastModifiedUtc column and a catalogue this size, an incremental load reads far less data than reprocessing millions of records that mostly didn't change.
Full Explanation
An incremental load uses a reliable change-tracking column, here a last-modified timestamp, to pull only the rows that changed since the previous successful run, which is the efficient choice when the source can prove which records moved and the changed fraction is small relative to the total volume. This keeps ingestion time and compute proportional to daily change volume instead of table size. A full load rewrites the entire catalogue every run; that is wasteful and slow at millions of rows when a trustworthy watermark already exists to avoid it, and it was the right answer only in the earlier scenario where no such signal existed. A one-time mirrored snapshot misunderstands mirroring, which in Fabric is a continuous, low-latency replication feature for supported operational databases, not a single static copy, and it also drops the requirement for an ongoing refresh cycle entirely. A manual, curator-initiated export is not a loading pattern at all; it introduces unpredictable latency and no auditability, which fails any operational analytics need. In practice, confirm the watermark column is populated on every insert and update path, including bulk corrections, because a code path that bypasses the timestamp silently breaks the incremental load without raising an error.