Apache Sedona is a cluster-computing system for processing large-scale geospatial data. It extends Spark (and Flink and Snowflake) with spatial data types, spatial indexes, and spatial query operators, so you can run joins and aggregations over billions of points, lines, and polygons that a single-machine GIS tool could never hold. It began life as GeoSpark and is the standard answer for distributed spatial analytics.

Spatial types and functions

Sedona adds geometry types and a large library of spatial SQL functions that follow the same conventions as PostGIS, so analysts moving from a spatial database find familiar operators. You can construct geometries from coordinates or WKT, then filter and measure them with predicates like ST_Contains and ST_Distance.

SELECT r.name, COUNT(*) AS pickups
FROM rides p JOIN regions r
ON ST_Contains(r.geom, ST_Point(p.lng, p.lat))
GROUP BY r.name;

Spatial joins and indexing

The hard part of distributed spatial work is the spatial join - matching rows by geometric relationship rather than by key. Sedona partitions data spatially (so nearby geometries land on the same node) and builds in-memory spatial indexes such as R-trees and quad-trees, so a join like "which region contains each GPS point" runs in parallel instead of comparing every point against every region. This is what lets it scale to datasets that don't fit on one machine.

Where it fits

Sedona is the tool for geospatial analytics at a scale beyond PostGIS or a desktop GIS - mobility data, telemetry, satellite imagery footprints, location analytics. It runs as a library on top of an engine you already operate, so a team running Spark can add spatial capability without a new cluster. For smaller spatial datasets, a single-node spatial database is simpler.

Frequently asked questions

What does Sedona add to Spark? Geometry data types, PostGIS-style spatial SQL functions, spatial partitioning, and spatial indexes (R-tree, quad-tree) so spatial joins and range queries run in parallel across a cluster.

Why are spatial joins hard to distribute? They match rows by geometric relationship, not by key, so naive approaches compare every pair; Sedona's spatial partitioning and indexing avoid that.

When should I use Sedona over PostGIS? When the data is too large for one machine; for datasets a single node can handle, PostGIS or a desktop GIS is simpler to run.