The official source for Apache Sedona news, technical insights, release updates, and best practices in large-scale spatial data management.
Where are the trees in Washington State? The answer is spread across 10.4 billion pixels, one byte each. ESA mapped the land cover of the whole planet in 2021, one pixel for every 10 meters of ground, and 8 files of that map cover Washington. SedonaDB 0.5.0, written in Rust, reads the 8 files as one table. One SQL statement joins that table to the 39 counties and returns the tree cover of every county in 45 seconds, on one machine.
Draw a line around Australia and close it. On a globe that ring has two sides, and both are real polygons: the Australian mainland, 7.6 million km², and everything else on Earth, about 502 million km². The coastline is the same in both. The only thing that says which one you meant is the direction you drew it.
So which direction means "the land"? It depends on whom you ask. The standards have disagreed for decades, and two of them call their opposite answers by the same name.
Transform a building footprint to a projected coordinate system, buffer it by ten meters, then calculate its area. Three spatial operations, written as one SQL expression. There is also work hidden between those operations: converting each intermediate geometry to bytes, only for the next function to turn it back into an object.
Apache Sedona avoids those conversions by passing objects directly between functions that support it. The mechanism is small, and its effect depends on the workload. The measurements below show where it matters, where other work dominates, and what interrupts it.
SedonaDB, GeoParquet, and a story that started at VLDB 2016, now in Rust.
Parquet has stored a minimum and a maximum for every column in every row group since September 2013. PostgreSQL 9.5 added BRIN in January 2016: one small summary per range of blocks, cheap to update, useful when the data is clustered. In the same year the original creators of Apache Sedona, Jia Yu and Mohamed Sarwat, published Hippo at VLDB, the top database conference: a sparse index 25 to 30 times smaller than a B+-tree, built for data that is not sorted.
Ten years later, data skipping is how every lakehouse engine reads a file, and the question from 2016 is still open. Below: 3.82 million Washington buildings in one GeoParquet file, written three ways. Sorted by geometry, sorted by another column, and shuffled.
SedonaDB 0.4.1 supports raster analysis in SQL and Python on a single machine. This example uses eleven PlanetScope satellite images to estimate the area burned in the Gironde and Landes wildfire of July 2026. SQL selects and aligns the images, NumPy identifies vegetation loss, and raster functions convert the result into polygons and area estimates by municipality.
Many raster analyses need one result for each polygon. Examples include mean elevation by canton, forest cover by district, and flood depth by parcel. A raster stores values in a grid of pixels. A polygon defines an area, also called a zone.
Zonal statistics summarize the raster pixels inside each zone. A spatial join matches data by location. Apache Sedona performs both steps in one query. This example reads 7,006,027 elevation pixels from Amazon S3 and summarizes all 26 Swiss cantons in 56 seconds.
In a flat spatial query the world is only its noon shadow on the ground. Two objects whose shadows touch can be four hundred feet apart, and from a flat predicate the answer is the same for both.
The questions put to spatial engines have stopped being flat. Drones under FAA ceilings, aircraft over towers, apartments above restaurants, mineral deposits below mining leases: each one comes down to whether two volumes meet, and until now the SQL answer was the shadow version. Sedona 1.9.1 adds the missing axis. There is a Box3D type with constructors and accessors, 3D predicates and distances, a 3D extent aggregate, and query plans that account for the third axis.
The Mississippi wanders. Between the two edges of a single Sentinel-2 scene it travels 147.6 km to cover 103 km of ground, and its width swings from 131 m to almost 3 km. Every one of those numbers came out of raw pixels: Apache Sedona's raster operators built the river polygon, and ST_ApproximateMedialAxis drew the line down the middle of it.
Those deep-green grids are California's Central Valley — some of the most intensively farmed land on Earth, not as a camera sees it but as the NDVI vegetation index does: computed, pixel by pixel, by seven lines of NumPy. Sedona ran those seven lines on 484 satellite tiles in parallel, straight out of a public S3 bucket, and wrote the answer back as Cloud Optimized GeoTIFFs. That's the new move in Sedona 1.9.1: a plain Python UDF can take raster columns and return rasters. If the raster function you need isn't built in — your index, your QA rule, your model — write it.
Every raster team has the bucket. Thousands of GeoTIFFs accumulated from surveys, vendors, and pipelines — and no catalog. Which files cover this area? Which CRS are they in? Which ones were never converted to Cloud Optimized GeoTIFF? Until now, answering meant crawling the bucket with one-off scripts — or pulling rasters down just to inspect them.
