Snowflake and FME have been a powerful combination for years. FME’s data integration and automation capabilities have helped users tackle complex tasks that aren’t natively possible in Snowflake. Historically, FME workflows ran on the desktop (FME Form), on servers (FME Flow), or in hosted cloud environments (FME Flow Hosted). There’s a new option: running FME in Snowpark Container Services is a powerful evolution that leverages FME’s Remote Engines to bring users even more flexibility, security and performance.
- For a deep dive into this topic and live demos, watch our webinar recording, Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Snowflake
Why use Snowpark Container Services for geospatial data workflows?
Spatial and enterprise data workflows have traditionally followed an inefficient pattern resulting in siloed data: enterprise data lives in cloud warehouses, while GIS, LiDAR, and sensor processing happens elsewhere. Data gets extracted, copied, transformed, and re‑loaded, while security, governance, and performance suffer along the way. This is an unfortunate byproduct of traditional GIS tools being built for offline, file‑based workflows, while data warehouses have lacked the spatial processing depth required for real‑world geospatial use cases. This can result in brittle handoffs and duplicated data.
Snowflake flips this traditional model on its head. Instead of moving data out of the platform for processing, applications come to the data. With Snowpark Container Services, Snowflake can now host containerized applications that run natively inside the Snowflake environment. This means no data egress, native security and governance, elastic compute, and consumption‑based pricing. This architecture is especially powerful for geospatial workloads, where data volumes are large and transformations are complex.
Why deploy FME Flow Remote Engines in Snowflake?
With FME Flow Remote Engines deployed via Snowflake Marketplace, FME’s processing engine runs directly inside Snowflake’s Snowpark Container Services. Your FME Flow instance still orchestrates jobs, schedules workflows, and manages automation, but the heavy lifting happens inside Snowflake.
The result is a tightly integrated architecture:
- FME workflows execute where the data lives
- Snowflake handles compute, scaling, and isolation
- Existing FME licenses and workflows are reused
Running workflows inside Snowflake changes what’s possible in a few ways:
1. Stronger Security and Governance
When data never leaves Snowflake, existing access controls remain in place, data residency and compliance requirements are easier to meet, and there’s no need to manage additional network paths or credentials. Remote engine services are locked down by default, with explicit control over what data they can access and what external services they can reach.
2. Better Performance at Scale
Processing data where it’s stored eliminates unnecessary I/O and network latency. In practice, teams have seen ~30% faster workflows on average, with even larger gains for large spatial datasets like LiDAR and point clouds. In one example, extracting hundreds of thousands of LiDAR points completed in minutes inside Snowflake, compared to nearly an hour on a traditional VM.
3. No‑Code Meets Cloud‑Scale
FME’s visual, no‑code interface lowers the barrier to advanced spatial processing. For example, you can load and transform GIS data, join spatial and business datasets, process sensor streams and time‑series data, extract and filter 3D and point‑cloud data, and more without writing custom pipelines or managing infrastructure.
Use case: Joining GIS and Enterprise Data
Imagine air‑quality sensor readings stored in Snowflake, collected from thousands of devices. Now combine that with polygon boundaries stored in ArcGIS Online. Using FME running inside Snowflake:
- Spatial layers are loaded directly into Snowflake
- Tables are created dynamically from source schemas
- Spatial joins happen natively in Snowflake SQL
The result is a unified dataset that enterprise analysts and GIS specialists can query together.
Use case: Processing Massive LiDAR Datasets
LiDAR files are notoriously large and difficult to manage. With this architecture:
- LiDAR files are indexed and cataloged
- Users define an area of interest
- Only intersecting point clouds are extracted
- Points are loaded directly into Snowflake tables
This makes high‑volume 3D data available for downstream analytics, visualization, and AI — without pre‑processing everything upfront.
Use case: Enabling Digital Twins and AI
Digital twins require context, such as spatial data, sensor readings, business and operational data, and 3D models and simulations. By bringing all of this data together inside Snowflake, FME helps create a clean, interoperable foundation. From there, Snowflake’s AI and ML capabilities can operate over the full picture.
How To Deploy FME in Snowflake
For detailed step-by-step guides to using FME and Snowflake, see our FME and Snowflake tutorials. The basic steps for deploying FME in Snowflake are:
- Install FME Remote Engines from Snowflake Marketplace
- Connect them to your existing FME Flow instance
- Assign engines from your existing FME license
- Run workflows inside Snowflake
There’s no additional FME licensing required. You’re simply choosing where the engines run.
On the Snowflake side, costs follow Snowflake’s standard consumption‑based model: you pay for compute only when workflows run.
The Bigger Picture: Data Strategy Before AI Strategy
AI initiatives live or die by the quality and completeness of their data. Spatial context, such as distances, routes, boundaries, elevation, and proximity, often provides the missing piece that turns raw data into real insight. But only if that data is accessible, governed, and connected.
By combining Snowflake’s scalable AI Data Cloud with FME’s unmatched data integration capabilities, teams can finally bridge the gap between GIS, enterprise analytics, and AI.
