dr-jia-yu

This was written by the Sedona team. And I asked AI to put some colors to the blog post.

You’re absolutely asking the right question. As we noted in Future Work section of the SpatialBench result (https://sedona.apache.org/spatialbench/single-node-benchmark...), this benchmark is focused on geospatial analytical queries. For these workloads, features like columnar layout, vectorized execution, zero-copy, and zero SerDe provide huge performance benefits.

While PostGIS is often used for spatial analytics because of its rich spatial function coverage, it is fundamentally a transactional database. This design makes it less suited for analytical query performance, and including it directly in SpatialBench would risk claims of being an “apples-to-oranges” comparison. That’s why we exclude PostGIS from the published benchmark results.

That said, we do continuously validate against PostGIS. For every single function in SedonaDB, we maintain an automated PyTest benchmark framework (https://github.com/apache/sedona-db/tree/main/benchmarks) that compares both speed and correctness against DuckDB and PostGIS. This ensures we catch regressions early and guarantees correctness. You can even run these benchmarks yourself to see how SedonaDB performs. It is often extremely fast in practice.

A more detailed tech review (from Wherobots) of 2 new Geo types can be found here: Iceberg GEO: Technical Insights and Implementation Strategies

https://wherobots.com/iceberg-geo-technical-insights-and-imp...

Wherobots wrote a detailed tech review of the new types. You can find the definition and reasoning there: https://wherobots.com/iceberg-geo-technical-insights-and-imp...

Sedona website: https://sedona.apache.org/