Hi! Please spare a little time. StarRocks has a rather limited set of functions for working with geospatial data. Its geospatial functionality is still at an early/embryonic stage. I couldn’t find any information about spatial indexes in StarRocks. Will the geospatial capabilities in StarRocks be further developed to the level of PostGIS in terms of geometry object processing and the overall range of geodata features? Are there any alternative options? @Rocky Thank you.

StarRocks' geospatial functionality is currently basic and focused on common analytical needs rather than comprehensive GIS processing. It is not intended to be a complete replacement for PostGIS. 1. Spatial Indexing You are correct: StarRocks does not currently have a native spatial index (such as an R-tree or GiST) for the

GEOMETRY

data type. Standard StarRocks indexes (Prefix, Bitmap, Bloom Filter) do not work on

GEOMETRY

columns. Queries involving spatial functions like

ST_Contains

or

ST_Distance_Sphere

typically result in a full scan unless you apply manual filtering optimizations. 2. Roadmap and PostGIS Parity There is no official roadmap indicating that StarRocks aims for full PostGIS parity. As an OLAP (Online Analytical Processing) engine, StarRocks prioritizes high-speed aggregation and massive data ingestion. Most recent indexing development has focused on: * Vector Search (v3.4+): Support for HNSW and IVFPQ indexes for high-dimensional AI/embedding vectors. * Full-text Search (v3.3+): Inverted indexes for text analysis. While there is community interest in Uber’s H3 indexing (hexagonal grid system), it is not yet a native first-class citizen in the core engine. 3. Alternative Options & Workarounds Since native spatial indexing is missing, users typically implement one of the following "industry standard" workarounds for OLAP: * Prefix Indexing on Coordinates: Instead of relying solely on the

GEOMETRY

type, store

latitude

and

longitude

as separate

DOUBLE

columns. If you place these columns at the beginning of your table's

ORDER BY

(Sort Key), you can perform very fast "bounding box" queries:

sql
    SELECT * FROM points
    WHERE lat BETWEEN 40.0 AND 41.0
      AND lon BETWEEN -74.0 AND -73.0;

* Geohash or H3 Pre-calculation: During data ingestion, calculate a Geohash or H3 index for your points (using your ETL tool or a Java UDF) and store it as a string or integer. You can then use StarRocks' high-performance string/integer filtering to narrow down candidates before applying expensive

ST_

functions. * Java UDFs: If you need specific PostGIS functions that StarRocks lacks, you can implement them via Java UDFs, potentially by wrapping a library like JTS (JTS Topology Suite). * Architectural Split: Use PostGIS for complex geometry processing and "heavy" GIS logic, then sync the processed results (or pre-aggregated grids) to StarRocks for large-scale dashboarding and multi-dimensional analysis. If your use case requires complex topology, 3D geometries, or advanced spatial joins, PostGIS remains the recommended specialized tool. StarRocks is best suited for scenarios where you need to aggregate billions of simple points or perform spatial filtering as part of a larger analytical query. References • sql-reference/sql-functions/scalar-functions/hll_hash.md • sql-reference/sql-functions/bitmap-functions/base64_to_bitmap.md • sql-reference/sql-functions/bitmap-functions/bitmap_to_base64.md • sql-reference/sql-functions/bitmap-functions/bitmap_hash.md • sql-reference/sql-functions/bitmap-functions/to_bitmap.md • sql-reference/data-types/other-data-types/HLL.md