A bounding box is a cheap necessary-condition test. The engine takes the envelope of the query shape, compares it against the box recorded for each file, and drops the file when the two do not overlap [3]. A miss is final; a hit only means the file might contain a match, so those shapes still get parsed. That asymmetry is the entire value, and it means the win depends on something no spec can hand you: files whose contents are spatially close together. Append by ingest time across a national delivery network and every file's box covers the whole country, at which point every box overlaps every query and nothing prunes.
The example the piece opens with is 40 million stops scanned to return 200,000 rows for one metro polygon [6]. That works out to 200 rows read per row returned [7]. It is also the one case the old workaround already handled: min/max statistics on two double columns give crude bounding-box pruning for point data, which is why teams stayed on that pattern for years [8]. If your spatial data is points and your predicates are envelopes, the scan-time gain here is small and the schema hygiene is the reason to move.
The real delta lands on everything that is not a point. A polygon, a route, or a service boundary does not fit in two numbers [8], so those tables went into a binary column as Well-Known Binary, the OGC byte encoding every spatial library reads and Iceberg saw as bytes [9]. The manifest then dutifully recorded byte-wise min and max for that column, bounds that are meaningless for location, so no engine skipped a file on them and every spatial predicate became a full scan followed by row-by-row parsing [10].
The coordinate reference system is the half I would actually migrate for. A CRS decides what a pair of numbers means: longitude 30, latitude 10 is one place under WGS84 and somewhere else under a projected national grid [11]. In a plain binary column that fact lived in a wiki page, a column comment, or someone's memory, and two teams writing the same table under different assumptions produced silent corruption no validation caught [12]. Format v3 puts the CRS in the schema, where it travels with the column [3]. It also splits the type in two, because flat-plane and spherical coordinates are different computations and mixing them returns wrong answers [17]. Geometry is the flat one: Euclidean distance, straight lines in coordinate space, correct for a projected CRS such as a state plane or UTM zone [18].
The provenance reads like engineering rather than announcement. The Wherobots team ran these ideas in production from 2022 as Sedona's Havasu fork, which bolted CRS metadata, bounding-box statistics and format annotations onto Iceberg and stopped being spatial the moment another engine opened the table [13][14]. Upstreaming cost more than 400 review comments on the Parquet logical type and 240 on the Iceberg type spec, at least 640 between them [15][16], which the author reads as a count of the decisions hiding inside "just add a geometry type" [20]. He discloses he works at Dremio, which ships v3, and keeps the argument at spec level [19].
In my context the case for adopting is the CRS and the cross-engine portability. The pruning is a bonus I would measure on my own file layout before promising it to an analyst.
