An archives network needs to combine an oral-history transcript dataset with heavy PySpark transformations that write large new derived tables, and the result must be physically stored inside the destination Lakehouse rather than left dependent on the original source location. Why would a pipeline copy be favored here over a OneLake shortcut?

A OneLake shortcut is a lightweight reference to data stored somewhere else; it does not move or duplicate the underlying bytes, which is exactly why it's cheap and instant to create, but also why it remains dependent on the referenced location staying available and unchanged. When a workload involves heavy PySpark transformation producing large new derived tables that must be physically stored in the destination Lakehouse, independent of the original source, a pipeline copy is the right tool, because it writes new, standalone data into the destination rather than pointing back at something else. Claiming a shortcut is always slower to query mischaracterizes shortcuts; query performance depends on the underlying storage and network path, not on the shortcut mechanism being inherently slow, and that isn't the actual reason to prefer a copy here anyway. Claiming shortcuts only work against a data warehouse is incorrect; shortcuts are a OneLake capability that can reference various supported storage locations, including other Lakehouses and external Data Lake Storage accounts. Claiming a copy is required before Spark can read any data at all is false, since Spark notebooks can read directly from shortcut-referenced data without any prior copy step. When choosing between the two, weigh whether downstream consumers need an independent, durable table versus a live reference, since that dependency question, not raw performance, drives the copy-versus-shortcut decision.