{"slug": "geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt", "title": "Geospatial queries are up to 38X faster with Lakehouse//RT", "summary": "Databricks reported that spatial SQL and spatial joins on its Lakehouse//RT real-time data warehouse run up to 38X faster than a traditional cloud data warehouse at 50 concurrent users, and 3X faster on average with up to 20X across the tested queries in SpatialBench benchmarks. Spatial SQL on Lakehouse//RT is available now in Beta, joining Lakehouse, Lakebase and Databricks Apps as the company's four pillars for geospatial workloads.", "body_md": "Lakehouse//RT delivers ultra low latency spatial queries at scale\n\nby  [Kent Marten](https://www.databricks.com/blog/author/kent-martin), [Matt Slack](</blog/author/ matt-slack>)  and  [Kaitlin Baumgardner](https://www.databricks.com/blog/author/kaitlin-baumgardner) \n\nSpatial SQL and spatial joins now run on Lakehouse//RT and they're **up to 38X faster** than traditional cloud data warehouses.\n\nEarlier 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.\n\nOrganizations 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.\n\nDatabricks 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. \n\nThis blog covers what Lakehouse//RT delivers for spatial workloads, driving up to 38X performance improvement under high concurrency.\n\nWe 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.\n\nUnder 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. \n\nTry 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).\n\nTake 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.\n\nThree takeaways:\n\nSpatial 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:\n\nSpatial SQL on Lakehouse//RT is available now in Beta. To get started:\n\nAt 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.\n\nYes. 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.\n\nNo. 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.\n\nIn 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.\n\nSpatial 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.\n\nYes. 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).\n\nYes. 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).\n\nSubscribe to our blog and get the latest posts delivered to your inbox.", "url": "https://wpnews.pro/news/geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt", "canonical_source": "https://www.databricks.com/blog/geospatial-queries-are-38x-faster-lakehousert", "published_at": "2026-10-15 17:31:02+00:00", "updated_at": "2026-10-15 21:56:09.142434+00:00", "lang": "en", "topics": ["ai-infrastructure", "structured-data", "developer-tools"], "entities": ["Databricks", "Lakehouse//RT", "Lakebase", "Databricks Apps", "Apache Spark", "SpatialBench", "PostGIS", "Kent Marten"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt", "markdown": "https://wpnews.pro/news/geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt.md", "text": "https://wpnews.pro/news/geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt.txt", "jsonld": "https://wpnews.pro/news/geospatial-queries-are-up-to-38x-faster-with-lakehouse-rt.jsonld"}}