Run Geospatial Workflows Directly Inside Snowflake — No Data Movement Required

Run FME’s geospatial processing engine directly inside Snowflake using Snowpark Container Services, with tips on architecture and 4 common workflow patterns.

Snowflake has become the center of gravity for enterprise data, but geospatial workflows still often run elsewhere. GIS teams process Shapefiles and geodatabases in desktop tools; engineers work with point clouds and BIM on specialized servers; sensor data from field devices is staged in object storage; and on it goes. When any of that data needs to join the conversation happening in Snowflake, teams fall back on the same pattern: extract, copy, transform, and reload. This approach introduces latency and weakens governance by duplicating data across systems.

Snowflake has expanded its geospatial support, such as its GEOGRAPHY and GEOMETRY types and native spatial functions like ST_DISTANCE and ST_INTERSECTS to provide analytical power in SQL. But many real-world spatial workflows include coordinate system transformations, format conversions across GIS standards, point cloud or 3D building model processing, and other steps that require a processing layer that natively understands spatial data.

With FME running inside Snowpark Container Services, you can execute complex spatial transformations directly where your data lives. Let’s walk through how this architecture works and explore common patterns for running geospatial workflows entirely inside Snowflake.

How the Architecture Works

FME’s core processing engine can run as a containerized service directly inside your Snowflake environment through Snowpark Container Services.

Here’s what the execution flow looks like in practice: FME Flow, which handles orchestration and scheduling, triggers a job. That job runs on an FME Remote Engine deployed inside Snowpark Container Services. The engine reads from and writes to Snowflake tables and stages without data leaving the Snowflake perimeter. Results are returned to Snowflake, ready for downstream analytics, dashboards, or further processing.

So FME Flow handles orchestration externally, while Remote Engines execute workloads inside Snowflake.

This architecture has a few practical benefits for data engineers:

• Governance stays intact. Your existing Snowflake role-based access controls apply automatically to FME’s processing, with no separate permissions model to manage or audit.
• No data egress, lower latency. Because processing happens inside Snowflake, you avoid data egress costs and the latency penalty of moving large spatial datasets across network boundaries. Processing times are faster compared to running the same workflows on external engines.
• Aligned, predictable costs. Compute follows Snowflake’s consumption model, while FME licensing applies to the processing engine.

FME Remote Engines brings the full library of over 500 transformers into Snowflake, embedding advanced spatial operations like coordinate reprojection, topological cleaning, raster processing, and schema mapping.

Scenario 1: Loading and Transforming Geospatial Data at Scale

A common challenge is getting spatial data into Snowflake in a consistent, usable format.

Consider a retail company that needs to consolidate store locations and trade-area polygons from regional GIS teams. Each team delivers data differently: one delivers Shapefiles in NAD83 State Plane, another sends GeoJSON in WGS 84, and a third exports from a local PostGIS database in a custom projection.

FME reads all of these natively, reprojects everything to WGS 84 (EPSG 4326, the coordinate system Snowflake’s GEOGRAPHY type expects), standardizes schemas, and writes directly to Snowflake GEOGRAPHY columns. The entire pipeline runs inside Snowflake, with no staging bucket, no intermediate database, and no manual coordinate math.

Scenario 2: Fusing LiDAR, 3D, and Sensor Data with Business Intelligence

Some of the most valuable spatial data doesn’t come in formats Snowflake can read natively. LiDAR point clouds (LAS/LAZ), Cloud-Optimized GeoTIFFs, NetCDF and HDF5 scientific datasets, and BIM models (Revit, IFC) all require specialized processing before they can be analyzed alongside business data.

Consider a utility company that flies drones over transmission corridors, capturing LiDAR scans to monitor vegetation encroachment. The raw point cloud data must be classified, filtered, and converted into metrics such as canopy height, then joined with asset management records already in Snowflake.

With FME processing inside Snowpark Container Services, the point cloud ingestion and feature extraction occur in the same environment as the asset data. The output, a table of corridor segments with encroachment risk scores, sits alongside maintenance schedules and inspection histories and is queryable in SQL.

Scenario 3: Keeping Snowflake and Esri in Sync

Many organizations use Snowflake for analytics and Esri’s ArcGIS for field operations and map-based visualization. The challenge is keeping both systems aligned without fragile, one-off ETL scripts.

FME enables bi-directional synchronization between Snowflake tables and ArcGIS Feature Services using built-in change detection, so only modified records are moved in either direction.

For example, a city government can maintain Snowflake as the single source of truth for infrastructure data while field crews update assets in ArcGIS Field Maps. FME Flow keeps both systems in sync automatically on a schedule or in response to an event trigger, such as a webhook fired when a field inspection is completed. Attachments, versioned edits, and complex geometry types all transfer cleanly because FME understands the data models in both systems.

Scenario 4: Pushing Spatial Analytics Down to Snowflake SQL

In many cases, the most efficient approach is to let Snowflake’s native spatial functions do the work and use FME to orchestrate the query and route the results.

With FME’s SQLCreator and SQLExecutor transformers, you can push spatial SQL directly into Snowflake.

For example, an insurance company might need to identify all active policies within 500 meters of an updated flood zone boundary. Rather than extracting both datasets, running the spatial join externally, and loading results back, FME can execute an ST_DWITHIN query inside Snowflake and route the matching policy records to a BI dashboard or notification system. The data stays in place, and only the results move.

The Step-by-Step Workflow

Prerequisites

Snowflake account with ACCOUNTADMIN privileges, FME Flow version 2025.1+, and the FME Remote Engines Service listing from Snowflake Marketplace.

1. Deploy the Remote Engine.

Install the FME Remote Engines Service from Snowflake Marketplace into your Snowpark Container Services environment. Configure permissions, network rules, compute pool configuration, and connectivity to FME Flow. Once deployed, the engine registers itself with FME Flow and appears as an available execution target.

2. Build a workspace.

In FME Form, create a new workspace using the Snowflake Spatial Reader/Writer. Point the Reader at your source — this could be a directory of Shapefiles in cloud storage, a REST API returning GeoJSON, or another database. Configure the Writer to target a Snowflake GEOGRAPHY column, setting the coordinate system to LL-WGS84. Using FME’s visual interface, add transformation steps between the read and write operations: reprojection, attribute mapping, geometry validation, or any of the 500+ available transformers.

3. Query Snowflake’s spatial SQL with FME.

For operations that Snowflake handles natively, including proximity searches, spatial joins, and area calculations, use a SQLCreator or SQLExecutor transformer in your workspace. Write your spatial SQL (using functions like ST_INTERSECTS, ST_AREA, ST_BUFFER), and FME will run it directly in Snowflake. This hybrid approach lets you use FME for what it’s best at (format translation, complex geometry operations, multi-system orchestration) and Snowflake for what it’s best at (massively parallel SQL on large datasets).

4. Automate.

Publish your workspace to FME Flow and assign it to the Remote Engine running in Snowpark Container Services. From there, you can schedule it to run on a timer, trigger via webhook, or run when new files land in a Snowflake Stage. FME Flow handles logging, retry logic, and notifications.

Why This Matters for the Snowflake Ecosystem

Snowflake’s geospatial capabilities have expanded significantly, with spatial data becoming a core part of the Data Cloud. While Snowflake excels at spatial analysis in SQL, many real-world workflows still require more — especially when dealing with diverse formats, coordinate systems, and complex transformations.

That’s where FME fits.

Running inside Snowflake, FME acts as a processing layer that handles ingestion, transformation, and interoperability, complementing Snowflake’s native spatial functions rather than replacing them.

For data teams, this means spatial workflows can follow the same governance, security, and cost model as every other workload in Snowflake.

As organizations bring more spatial data types into their analytical environments, including 3D city models, real-time sensor feeds, climate datasets, indoor mapping, and more, having a flexible processing engine that runs where the data lives becomes a critical advantage.

Learn more

• FME Remote Engines Service on Snowflake Marketplace
• [Tutorial] Getting Started with FME Remote Engines Service in Snowflake
• [Blog] How to build next-gen spatial & sensor workflows in Snowflake
• [Webinar] Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Snowflake
• [Blog] 5 Key Benefits of Running FME Remote Engines Inside Snowflake
• Snowflake Marketplace: FME Remote Engines Service (Trial)