DuckDB has become a serious option for geospatial work, but the experience of running heavy spatial workloads is not what PostGIS users expect. This talk is a practitioner's field report after putting DuckDB through real production pipelines, including multi-million-polygon flood layers and GeoParquet services served over the network.
The core problem is structural. DuckDB's query planner reasons about columns and statistics, but in spatial data the real cost lives inside the geometry field, which the planner treats as an opaque blob. The result is that intuitions carried over from PostGIS, where a GiST index quietly does the heavy lifting, often lead you astray. There is no equivalent reflex to fall back on, and the optimizations that matter are different.
The session is built around concrete examples. We will read actual EXPLAIN and EXPLAIN ANALYZE output, look at where time and memory actually go, and connect that back to the query as written. The goal is to make the planner legible so attendees can diagnose their own slow queries rather than guess.
A key thread is that the right strategy depends on where your data lives. Querying GeoParquet directly over httpfs is a fundamentally different problem from working inside a native DuckDB table, and each demands its own adjustments. As I want to keep this talk technical but digestible, I will only be using one representative example from each case, we will see how choices like row ordering, bounding-box pre-filtering, or row-group layout play out very differently depending on the storage layer, and how the planner output reveals which adjustment actually matters. I will provide awareness, not a fully packaged cookbook.
Attendees will leave able to read the DuckDB planner, recognize when geometry complexity is the bottleneck, choose the right approach for their storage layer, and apply specific changes that produce measurable speedups on their own data.
Intended audience: GIS practitioners, data engineers, and anyone moving spatial workloads from PostGIS or PostgreSQL to DuckDB.