BigQuery vs. Wherobots: What a 23-Second Difference in Spatial SQL Really Reveals

The Real Story Behind Faster Spatial Queries

I’ve been in geospatial long enough to know that performance metrics can be deceptive. When I recently ran a query to enrich drive-time isochrones with population data—something that’s geometry-heavy and computation-intensive—I got results from two powerful engines: Wherobots and BigQuery.

Wherobots returned results in 57 seconds.
BigQuery took 1 minute and 20 seconds.

At first glance, this seems like a minor performance difference. But the real story is in the architecture

Not all engines are built alike

We were doing area-weighted interpolation, a task that requires analysis of how population polygons overlap with other polygons (in this case isochrones). This isn’t a simple spatial join, you’re essentially saying: “Give me the percent of population that falls within a part of a polygon that overlaps with another polygon.” And if you’ve done this at scale, you know this is a computationally expensive (slow) operation.

BigQuery, as powerful as it is, runs spatial SQL on a general-purpose engine. It’s amazing for many workloads, and it is still performant for many operations. That said, BigQuery’s storage layer (Capacitor) isn’t natively interoperable with most geospatial tools. In simple terms, you need to load data into its internal format for any serious performance, and transform spatial data into CSVs, Parquet or other formats. Once it is in Capacitor it is not accessible to any other system, outside of querying with BigQuery.

Why Wherobots feels different

Wherobots is a spatial-first compute layer that is native to geospatial data. It doesn’t try to make spatial work in a general engine, it builds the engine around spatial.

No custom ETL pipelines. No loading delays. No waiting on ingestion. No reformatting data just to get started.

It’s also worth noting that Wherobots can query raw files from cloud storage directly, which means I’m not tied into proprietary formats or workflows. I can spin up queries in a notebook, hit the same storage I use with open-source tools, and scale as needed.

The Developer Experience Matters

I’ve always believed in building workflows that minimize context switching. With Wherobots, I can query data in Apache Iceberg, analyze it with GeoPandas, and visualize it in the same environment. I don’t need to worry about format conversion, storage compatibility, or spinning up extra infrastructure just to debug a spatial join.

BigQuery can do amazing things, especially when paired with its massive ecosystem. But for the kind of spatial work I do, and the audience I teach and build with, the simplicity and openness of Wherobots makes it more than just “faster.”

Final thought

This isn’t a post about performance benchmarks. It’s a post about how deeply the design of your tools impacts your ability to think, iterate, and build.

Fast is fast, but fast with fewer constraints is better.

Follow along for more on modern GIS, spatial SQL, and how we’re building the next wave of spatial infrastructure, one open format at a time.