SedonaDB brings single-node spatial SQL to Python and Rust on DataFusion

What it is

SedonaDB is an Apache Software Foundation subproject: a single-node analytical database engine written in Rust whose whole reason for existing is spatial data. Rather than bolting geometry functions onto a general-purpose query engine, the project treats geospatial as a first-class citizen — columnar datasets carry spatial indexes, coordinate reference system (CRS) tracking, and Arrow-native storage with zero serialization overhead.

The workspace at apache/sedona-db is large: 26 MB across roughly 1,500 files. The Rust crates under rust/ form the engine core — sedona-geo, sedona-functions, sedona-spatial-join, sedona-raster, and a dedicated sedona-query-planner. Workspace members under c/ include GEOS, GDAL, PROJ, GeoArrow C, and libgpuspatial crates. Python and R interfaces sit on top.

The README is explicit about scope: SedonaDB is meant for smaller to medium datasets on local machines or cloud instances. For distributed workloads you move up to SedonaSpark, SedonaFlink, or SedonaSnow.

What it does

At the query level, SedonaDB supports spatial range queries, KNN (k-nearest neighbor) queries, spatial joins, and KNN joins, plus raster operations like map algebra, NDVI, mask, and zonal statistics. The README notes that full raster function parity with SedonaSpark is expected soon; the code already carries RS_* functions.

The engine maintains CRS information through a query — the docs describe "CRS propagation" as an invariant. It reads legacy and modern formats: GeoParquet, WKT, WKB, Shapefile, and GeoJSON. The README says it supports all formats GeoPandas supports; in practice the context auto-registers single-file OGR formats via pyogrio/GDAL — .fgb, .gpkg, .shp, and .geojson are listed — so SELECT * FROM 'file://...' works on those without a manual register call.

Getting started

Installation is one of two ways:

pip install "apache-sedona[db]"

or with conda:

conda install sedonadb

The quick start in the README is short:

import sedona.db

sd = sedona.db.connect()

result = sd.sql("SELECT ST_Point(0, 1) as geom")
result.show()

On import, sedonadb/__init__.py attempts to configure PROJ and GDAL automatically. If either can't be found it issues a ConfigurationWarning rather than failing — most functionality works without them. Set the environment variable SEDONADB_AUTO_CONFIGURE=false to skip that step entirely.

The README's Overture buildings example shows the intended workflow: read a Parquet dataset lazily with sd.read_parquet(...), register it as a view, then run SQL against it — filtering tall buildings in New York by bounding box and computing centroids. Reads are lazy; SedonaDB fetches only what a query needs.

How a query flows

The Python package is a thin layer over a Rust extension (_lib). sedonadb.context.SedonaContext.sql() hands SQL to the engine, which builds on DataFusion's SessionContext. From there the work splits into two halves that mirror how the codebase is organized.

Optimization. The rust/sedona-query-planner crate registers logical optimizer rules. A notable one is EnsureLoadedOptimizerRule, documented in ensure_loaded.rs: it rewrites raster UDF calls so that out-of-database byte materialization happens explicitly in the logical plan — a call like RS_Value(raster, x, y) becomes RS_Value(RS_EnsureLoaded(raster), x, y). DataFusion's common-subexpression elimination then deduplicates identical loads. Other rules handle CRS reconciliation across unions and push down leaf projections.

Execution. Spatial joins get their own physical planner (DefaultSpatialJoinPhysicalPlanner) in rust/sedona-spatial-join, producing a SpatialJoinExec that partitions, probes, and refines using spatial indexes. The README describes both heuristic-based and cost-based spatial-aware optimization, plus automatic disk spilling for large-scale joins.

Memory is managed through DataFusion's runtime environment. By default no limit is enforced; set one to get spill-to-disk:

sd.options.memory_limit = "4gb"

The docs in memory-management.md are explicit that all runtime options — memory_limit, memory_pool_type, temp_dir, unspillable_reserve_ratio — must be set before the internal context is created, which happens on the first sql() or read call, not at .execute(). After that they become read-only.

Interfaces beyond Python

The workspace ships more than the Python package. There are R bindings under r/sedonadb, described in its README as an R interface to SedonaDB built on DataFusion's single-node engine. A DBAPI layer (python/sedonadb/python/sedonadb/dbapi.py) wraps the ADBC driver manager, marked experimental. There is a sedona-cli crate and Rust examples under examples/. The c/ workspace members include GEOS, GDAL, PROJ, and libgpuspatial crates.

The release profile in Cargo.toml is tuned for distribution: codegen-units = 1 and lto = true, with a comment noting this matters especially for the Python extension. The workspace pins Arrow at version 59.3.0 across its crates, requires Rust 1.94.0, and uses edition 2021.

Who it's for

A developer who wants spatial SQL on their own machine — analysis over GeoParquet or Shapefile data with range queries, KNN, and joins — without standing up a cluster. The Python API is deliberately small ("a minimal subset of functionality derived primarily from Ibis and DuckDB's relational APIs," per the DataFrame docstring), so it fits alongside PyArrow-compatible tools like GeoPandas, DuckDB, and Polars rather than replacing them.