Position Deletes are one of the two mechanisms introduced in Apache Iceberg Spec v2 to support Merge-on-Read (MoR) architectures. They allow a query engine to mark specific rows in a data file as deleted without rewriting the entire multi-megabyte Parquet file.
How They Work
When an engine performs a batch delete operation (like DELETE FROM sales WHERE status = 'CANCELLED'), it can scan the table to find the matching rows. Instead of rewriting the data files, the engine writes a separate Position Delete File.
A Position Delete File contains two critical pieces of information for every deleted row:
file_path: The absolute URI of the original data file containing the row.pos: The exact row index (position) within that specific data file.
At read time, when a query engine opens the data file, it also reads the associated position delete file. It uses the exact physical row indexes to instantly skip the deleted rows. Because the engine knows exactly which positions to ignore, the overhead of applying the deletes during a read is minimal.
Performance Characteristics
Position deletes are generally highly performant for the reader. They do not require the engine to evaluate complex logical comparisons or execute expensive anti-joins against the data stream; the engine simply drops the specified row indexes from the result set. This makes position deletes the preferred MoR delete mechanism for most analytical query engines.
The primary limitation of position deletes is that the writer must know the exact physical file path and row position of the data being deleted. This is easy for a batch engine (like Spark) executing a DELETE or MERGE statement, because the engine scans the data before writing the delete file. However, for a pure streaming ingestion job (like Flink) that receives a "delete customer 123" event but does not know where customer 123 is stored in object storage, generating a position delete is impossible without an expensive pre-read step. In those streaming scenarios, Equality Deletes are used instead.
