# Geospatial queries are up to 38X faster with Lakehouse//RT > Source: > Published: 2026-10-15 17:31:02+00:00 Lakehouse//RT delivers ultra low latency spatial queries at scale by [Kent Marten](https://www.databricks.com/blog/author/kent-martin), [Matt Slack]() and [Kaitlin Baumgardner](https://www.databricks.com/blog/author/kaitlin-baumgardner) Spatial SQL and spatial joins now run on Lakehouse//RT and they're **up to 38X faster** than traditional cloud data warehouses. Earlier this year, we brought [Spatial SQL to General Availability](https://www.databricks.com/blog/geospatial-unbounded-spatial-sql-ga-aibi-maps-delta-sharing-and-iceberg-v3) on Databricks: this included support for the GEOMETRY data type, 100+ spatial functions, high-performance spatial joins, AI/BI maps, Delta Sharing. The GEOMETRY and GEOGRAPHY data types are part of the open lakehouse, available in Apache Spark, and supported in the same underlying parquet files used by Delta and Iceberg v3. Customers across insurance, agriculture, energy, telecom, retail, logistics and more have adopted it to consolidate geospatial workloads onto a single governed platform. Organizations with both spatial OLAP workloads and real-time location-based applications want great performance and high concurrency. Many of these organizations still rely on traditional data warehouses and build out specialized architectures for spatial applications, sometimes managing a separate stack centered on PostGIS for every use case just to meet latency requirements. Separate stacks lead to more copies of data, more synchronization pipelines, and more governance overhead. Databricks now supports 4-pillars for geospatial workloads: [Lakehouse](https://www.databricks.com/product/databricks-lakehouse) for long-running spatial OLAP workloads, [Lakebase](https://www.databricks.com/product/lakebase) for spatial OLTP, apps, and agents, [Databricks Apps](https://www.databricks.com/product/databricks-apps) for purpose-built experiences, and now the [Lakehouse//RT warehouse](https://www.databricks.com/product/lakehouse/real-time-lakehouse) for real-time analytics.  This blog covers what Lakehouse//RT delivers for spatial workloads, driving up to 38X performance improvement under high concurrency. We benchmarked Lakehouse//RT against a traditional cloud data warehouse across a suite of spatial queries using [SpatialBench](https://sedona.apache.org/spatialbench/). By comparison, Lakehouse//RT delivers **3X faster on average, and up to 20X faster** across the tested queries. Under heavy load, the performance differences are even more significant. At 50 concurrent users, Lakehouse//RT delivers **up to 38X** on the queries where the traditional warehouse could keep up.  Try it for yourself: Follow the SpatialBench documentation to generate the synthetic data used in the benchmark queries from this [page](https://github.com/apache/sedona-spatialbench/blob/main/docs/quickstart.md). Take a look at query #8. To follow best practices, it is recommended to remove the ST_GeomFromWKB call that converts data stored as well-known binary and instead use the native GEOMETRY data types. Using the native data types allows query optimizations and file-skipping to provide the best performance. Three takeaways: Spatial SQL on Databricks already serves a wide range of industries. With Lakehouse//RT, workloads can run with the real-time speed applications demand. Here are a few examples: Spatial SQL on Lakehouse//RT is available now in Beta. To get started: At Data + AI Summit 2026, we [introduced Lakehouse//RT](https://www.databricks.com/blog/introducing-lakehousert-real-time-performance-unified-lakehouse), Databricks' new [real-time data warehouse](https://www.databricks.com/product/lakehouse/real-time-lakehouse) built to deliver millisecond query performance at massive concurrency directly on your [lakehouse data](https://www.databricks.com/product/databricks-lakehouse). Lakehouse//RT was designed to solve a specific problem: as organizations expand data access across users, applications, dashboards, and AI agents, they need real-time responsiveness without copying data into a separate serving layer. Preview customers have seen significantly better performance overall with Lakehouse//RT vs. real-time serving layers, with latency as low as 10ms and concurrency as high as 12,000 queries per second. Yes. Spatial SQL and spatial joins now run on the Lakehouse//RT, so you can serve geospatial queries with low latency and high concurrency directly on your governed Delta and Iceberg tables. There is no need to copy data into a separate geospatial system or real-time analytics serving layer. No. The same spatial functions and spatial joins you run on Databricks SQL Serverless today run on Lakehouse//RT with no code changes. You get the speedup by creating a Lakehouse//RT warehouse and pointing your existing queries at it. In head-to-head benchmarks against a traditional data warehouse, Lakehouse//RT runs spatial queries up to 38X faster under heavy load. On average, benchmark queries are 3.5X faster even when you exclude the largest increase. Spatial SQL and spatial joins are available on Lakehouse//RT in Beta. To get started, create a Lakehouse//RT warehouse from the SQL Warehouses page and run your existing spatial queries with no code changes. Yes. All H3 expressions supported by Databricks Lakehouse are supported today with Lakehouse//RT. Read more about H3 [here](https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-h3-geospatial-functions). Yes. You can create maps that use native geometry and geography data types in AI/BI dashboards. Read more [here](https://docs.databricks.com/aws/en/dashboards/manage/visualizations/maps#custom-geographic-data). Subscribe to our blog and get the latest posts delivered to your inbox.