How to Build a Geospatial Lakehouse on Snowflake
A service-by-service architecture for governed vector, raster, machine learning, and application workloads on Snowflake.
Publication contents
Platform guides
On this page
Snowflake as the governed geospatial platform
Snowflake provides a strong governed center for vector geospatial workloads. Native spatial types, spatial SQL, H3, sharing, and incremental pipelines cover the common analytical path. Raster, point-cloud, graph, and routing workloads require Snowpark, containers, or external engines.
Open table support through Iceberg can connect the warehouse to an open-format data estate. The architecture still depends on Snowflake services for much of its governance and execution model, so teams should choose that boundary deliberately rather than treating format compatibility as platform independence.
Technical foundation
- Native GEOGRAPHY and GEOMETRY columns with spatial constructors, predicates, measurements, transformations, and aggregates.
- Native H3 functions for grid assignment, coverage, neighbors, hierarchy, and grid-prefiltered joins.
- Snowpark Python functions and Snowpark Container Services for raster processing, custom libraries, and graphics processing unit workloads.
Does Snowflake have native raster support?
Snowflake has no native raster type. Raster processing runs through governed files and distributed Python or container workflows, with metadata and outputs stored in the platform’s cataloged data layer.
The Geospatial Lakehouse Stack on Snowflake
Six layers connect source acquisition to governed data products and the applications that use them.
Ingestion
Snowpipe for files, Snowpipe Streaming for live records, COPY INTO for batch loads, and Openflow for managed connectors and change data capture.
Storage and governance
Native or Iceberg tables for spatial data, stages for raster and scientific files, Horizon Catalog for governance, and Secure Data Sharing and Marketplace for distribution.
Spatial compute
Native spatial SQL and H3. Snowpark Python or Container Services provide raster processing. Graph analytics run in Snowpark or an external engine.
Machine learning and AI
Snowflake ML Feature Store and Model Registry, Container Services for custom training and inference, Cortex AI functions, and Cortex Search.
Orchestration
Dynamic Tables for incremental transformations, Tasks and Streams for imperative pipelines, and Snowpipe Streaming for continuous ingestion.
Consumption
Streamlit in Snowflake, Snowsight, Cortex Analyst and Snowflake Intelligence, Hybrid Tables for operational lookups, and Secure Data Sharing.
The geospatial medallion on Snowflake
Each lifecycle stage has a specific storage, processing, governance, and serving responsibility.
| Stage | Platform implementation |
|---|---|
| 01 Acquire | Use Snowpipe and COPY INTO for files, Openflow for managed sources, and external access for provider APIs. Marketplace listings can replace file acquisition for some reference datasets. |
| 02 Raw store Bronze | Keep source files in write-once stage paths and preserve tabular sources in bronze tables without modifying the original values. |
| 03 Analysis-ready Silver | Use Snowpark or Container Services to create cloud-optimized raster files. Validate vector geometry and maintain analysis-ready spatial tables with H3 indexes through Dynamic Tables where appropriate. |
| 04 Product Gold | Publish governed gold tables with defined ownership and meaning. Register reusable features and models in Snowflake ML. |
| 05 Serve | Use Snowsight and Streamlit for analysis and applications, Hybrid Tables for operational lookups, and Secure Data Sharing or Marketplace for distribution. |
Strengths and constraints
Strengths
- Native spatial types, spatial SQL, and H3 provide a capable vector analytics foundation.
- Marketplace and Secure Data Sharing simplify access to reference data and distribution of governed products.
- Dynamic Tables provide a concise incremental pipeline model for silver and gold spatial tables.
- Snowpark Container Services provides an execution path for custom raster libraries and graphics processing unit workloads.
Constraints
- Snowflake has no native raster, point-cloud, topology, graph, routing, or linear-referencing engine.
- Raster and graph processing introduce code and operational boundaries outside native SQL.
- Hard sub-second geofencing usually requires a stream processor ahead of Snowflake.
- Search optimization, containers, and repeated large spatial scans require workload-specific cost testing.
Frequently asked questions
Can Snowflake run a complete geospatial platform?
Snowflake can provide the governed center for a production geospatial system. Some workload classes use native services, while others require operated workflows or specialist engines. The stack on this page identifies those boundaries.
Does this architecture eliminate specialist geospatial tools?
No. Specialist tools remain appropriate for capabilities the platform does not supply, including some raster, point-cloud, topology, graph, and routing workloads. They should read and write governed data with clear operational ownership.
Where should implementation begin?
Begin with one governed product tied to a consumer and decision. Map its sources, transformations, quality gates, and serving requirements across the six stack layers and five lifecycle stages before selecting additional services.
- Identifier
- LGP-PLT-002
- Version
- 0.1, public draft
- Published
- License
- CC BY-SA 4.0
Suggested citation: LakeGeo, How to Build a Geospatial Lakehouse on Snowflake, v0.1, public draft, 2026, https://lakegeo.ai/architecture/snowflake/.
Release history
First public draft covering platform fit, the six-layer stack, the geospatial medallion, strengths, and constraints.