SedonaDB: A new geospatial DataFrame library written in Rust
12 comments
·September 24, 2025WD-42
I’ve been out of the geo loop for a while. I’m struggling to understand why I’d use this over postgis. There used to be the argument that installing extensions was painful, but now that docker exists pulling the postgis image is just as easy as normal Postgres. And RDS has supported it for a while.
What am I missing? The api even looks the same.
paleolimbot
PostGIS is great when your data is already in a Postgres table! SedonaDB and DuckDB are much faster when your data starts elsewhere (e.g., GeoParquet files).
MrPowers
The "DuckDB is probably the most important geospatial software of the last decade" post has a nice related discussion: https://news.ycombinator.com/item?id=43881468
drewda
Interesting, but why share the Sedona name?
I thought Apache Sedona is implemented in Java/Scala for distributed runtimes like Spark and Flink. Wouldn't Rust tooling for interactive use be built atop a completely different stack?
ZeroCool2u
Apache Sedona, not so well loved in the GIS space in my experience, so I don't think it's a huge issue even if it is a bit confusing.
mkesper
Please don't use emojis in titles. Immediately looks like written by AI.
jrozner
Whats the point of this over polars?
MrPowers
There is a project called GeoPolars: https://github.com/geopolars/geopolars
From the README:
> Update (August 2024): GeoPolars is blocked on Polars supporting Arrow extension types, which would allow GeoPolars to persist geometry type information and coordinate reference system (CRS) metadata. It's not feasible to create a geopolars. GeoDataFrame as a subclass of a polars. DataFrame (similar to how the geopandas. GeoDataFrame is a subclass of pandas.DataFrame) because polars explicitly does not support subclassing of core data types.
jedisct1
Was "written in Rust" really necessary?
What does it do besides being written in Rust?
tomtom1337
Look, this article is absolutely excellent, and answers your questions. Please read the article before commenting this sort of thing.
As someone who has had to use geopandas a lot, having something which is up to an order of magnitude faster is a real dream come true.
MrPowers
SedonaDB builds on libraries in the Rust ecosystem, like Apache DataFusion, to provide users with a nice geospatial DataFrame experience. It has functions like ST_Intersects that are common in spatial libraries, but not standard in most DataFrame implementations.
There are other good alternatives, such as GeoPandas and DuckDB Spatial. SedonaDB has Python/SQL APIs and is very fast. New features like full raster support and compatibility with lakehouse formats are coming soon!
Somehow I dont see this applicable for 90% of all current spatial needs, where PostGIS does just right, and same IMHO goes for DuckDB. There perhaps exists 10% of business where data is so immense you want to hit it with Rust & whatnot, but all others do just fine im Postgre.
My bet is most of actually useful spatial ST_ functions are not implemented in this one, as they are not in the DuckDB offering.