Deep dive on pruning

Dewey Dunnington’s latest blog post dives deep into how pruning, the selective reading of relevant data, makes #GeoParquet blazing fast in both local and #cloudnative contexts. Featuring hands-on comparisons across #SedonaDB, #DuckDB, #GeoPandas, #GDAL, and #Sedona #Spark, it’s a must-read for anyone exploring efficient cloud-native geospatial workflows.
Author

Ralph Straumann

Published

December 16, 2025

Dewey Dunnington has an outstanding blog post for those who are interested in the technical side of the cloud-native data paradigm. The post looks into how pruning1 works with GeoParquet 1.0 and 1.1. Pruning is what makes cloud-native data especially fast to view and query – over the internet (using so-called HTTP range requests), but also when used locally.

Dewey’s blog post compares different approaches to efficiently querying GeoParquet files, using:

The post also provides the Python code – with interspersed SQL, of course – for each approach.

The support of the two GeoParquet versions and also the ease-of-use varies slightly between what Dewey calls the “don’t worry, we take care of the details” solutions and solutions “that need a little help”.

Highly recommended for anybody interested in cloud-native data7, very interesting details in this post!

Footnotes

  1. In essence, when querying data, pruning refers to skipping or not transferring or reading data that does not affect a query’s result. Cloud-native data excels at enabling pruning.↩︎

  2. SedonaDB is an open-source single-node analytical database engine with geospatial as a first-class citizen.↩︎

  3. Sedona Spark is a distributed batch analytics and processing engine on Apache Spark clusters.↩︎

  4. DuckDB is an open-source column-oriented Relational Database Management System (RDBMS) designed for analytics use-cases.↩︎

  5. GeoPandas is an extension to the popular data science library Pandas that enables support for geospatial data.↩︎

  6. GDAL, short for “Geospatial Data Abstraction Library” is a translator library for raster and vector geospatial data formats that underpins much of the modern geospatial data stack.↩︎

  7. Let me quote Dewey’s blog post to emphasize that many people should be interested: “Basically, GeoParquet was designed to allow traditional GIS software to take advantage of a decade plus of heavy investment in the Parquet format and the software that reads and writes it. Two spot examples are that (1) software that reads traditional GIS formats is not particularly good at splitting the work up so that all the cores on your computer are put to good use and (2) most formats are not particularly good at being plonked onto a web server and have sections of them selectively queried (which can often save data producers from standing up a 24/7 web service).”↩︎