A national archives network loads the previous day's ticketing transactions from each branch's point-of-sale system into a Fabric Warehouse every night. The source system cannot reliably flag which rows changed, but the full table is small and inexpensive to pull each run. Which loading pattern best fits this scenario?

A full load rewrites the entire target table from the source on every run, which is exactly the right trade when the source cannot expose reliable change signals and the data volume is small enough that reprocessing everything is cheap. It avoids building fragile change-detection logic against a system that doesn't support it. An incremental load depends on a trustworthy watermark, such as a last-modified timestamp or an ordered key, that increases monotonically and is present on every row; the scenario states the source cannot flag changed rows, so any incremental design would either miss updates or require guessing, both of which produce silent data quality gaps. Streaming ingestion through an Eventstream is built for continuously arriving events with low latency requirements, not for a nightly batch pull from a point-of-sale extract that already lands once per day. Mirroring replicates a source database's tables into OneLake automatically and continuously; it solves a different problem, near-real-time replication of an entire database, rather than a scheduled, table-level nightly refresh. Before choosing full load in practice, confirm the target table's size and downstream dependencies stay stable over time, since a full load that used to take minutes can quietly grow expensive as the ticketing history accumulates.