# How to Build a Geospatial Lakehouse on Snowflake A service-by-service architecture for governed geospatial workloads on Snowflake. Foundations - [The Geospatial Lakehouse](https://lakegeo.ai/architecture/) - [Geospatial Lakehouse Stack](https://lakegeo.ai/architecture/models/) - [Geospatial medallion architecture](https://lakegeo.ai/architecture/medallion/) Platform guides - [Build on Databricks](https://lakegeo.ai/architecture/databricks/) - [Build on Snowflake](https://lakegeo.ai/architecture/snowflake/) - [Build on Google Cloud](https://lakegeo.ai/architecture/google-cloud/) Publication contents Foundations - [The Geospatial Lakehouse](https://lakegeo.ai/architecture/) - [Geospatial Lakehouse Stack](https://lakegeo.ai/architecture/models/) - [Geospatial medallion architecture](https://lakegeo.ai/architecture/medallion/) Platform guides - [Build on Databricks](https://lakegeo.ai/architecture/databricks/) - [Build on Snowflake](https://lakegeo.ai/architecture/snowflake/) - [Build on Google Cloud](https://lakegeo.ai/architecture/google-cloud/) On this page 1. [Platform fit](#platform-fit) 2. [Native raster support](#raster) 3. [Geospatial Lakehouse Stack](#stack) 4. [Geospatial medallion](#medallion) 5. [Strengths and constraints](#assessment) 6. [Frequently asked questions](#faq) Platform fit ## 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. **Architecture rule.** Use Snowflake spatial SQL and H3 for vector workloads. Assign Snowpark, container, or external-engine ownership wherever the design requires raster, point clouds, graph processing, topology, or routing. Raster support ## 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. Architecture ## The Geospatial Lakehouse Stack on Snowflake Six layers connect source acquisition to governed data products and the applications that use them. ![Six-layer Geospatial Lakehouse Stack on Snowflake, with native vector and H3 capabilities and operated raster and graph workflows.](https://lakegeo.ai/_astro/snowflake-stack.4BBcSLiL_1eks3x.webp) **Figure 1** The six layers of the Geospatial Lakehouse Stack on Snowflake. L1 ### Ingestion Snowpipe for files, Snowpipe Streaming for live records, COPY INTO for batch loads, and Openflow for managed connectors and change data capture. L2 ### 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. L3 ### Spatial compute Native spatial SQL and H3. Snowpark Python or Container Services provide raster processing. Graph analytics run in Snowpark or an external engine. L4 ### Machine learning and AI Snowflake ML Feature Store and Model Registry, Container Services for custom training and inference, Cortex AI functions, and Cortex Search. L5 ### Orchestration Dynamic Tables for incremental transformations, Tasks and Streams for imperative pipelines, and Snowpipe Streaming for continuous ingestion. L6 ### Consumption Streamlit in Snowflake, Snowsight, Cortex Analyst and Snowflake Intelligence, Hybrid Tables for operational lookups, and Secure Data Sharing. Data lifecycle ## 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. ![Five-stage geospatial medallion on Snowflake from acquisition through bronze, silver, gold, and serving.](https://lakegeo.ai/_astro/snowflake-medallion.DSrS_Aet_ZQF2tY.webp) **Figure 2** Snowflake services assigned to each stage of the geospatial medallion. Assessment ## 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. See more LakeGeo in your Google Search and AI results. [Make LakeGeo a preferred source on Google](https://www.google.com/preferences/source?q=lakegeo.ai) Questions ## 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. Publication details Identifier LGP-PLT-002 Version 0.1, public draft Published July 2026 License [CC BY-SA 4.0](https://creativecommons.org/licenses/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 v0.1 July 2026 First public draft covering platform fit, the six-layer stack, the geospatial medallion, strengths, and constraints. Canonical URL: https://lakegeo.ai/architecture/snowflake/