Files.com Lets Snowflake Read a Hospitality Company’s Large Extracts Without an Azure Blob Copy

A US hospitality company built its business around large resorts, convention centers, and entertainment venues across several cities, with group and convention travel at the center of it.

The company owned the hotels, but partners operated much of what ran inside them. The properties carried an international hotel brand, and the reservation and loyalty systems that generated the company’s most valuable data ran outside its own walls. That data reached the company the way partner data usually does: as files. Providers delivered loyalty enrollment and reservation extracts on daily, weekly, and monthly cycles, and the company’s analytics ran on Snowflake, its cloud data warehouse. Every one of those extracts had to travel from a vendor’s delivery into the warehouse, and the vendor’s delivery network accepted connections only from fixed, whitelisted IP addresses. The company turned Files.com into the Snowflake stage itself, eliminating the Azure Blob copy without asking either third party to change.

Fixed Addresses on One Side, Public Cloud IPs on the Other

Snowflake reads external data through a stage: point the warehouse at a storage location, and it pulls files directly, with no load job in between. The clean design was obvious. Stage the warehouse against the location where the vendor delivered, and the data would never get copied at all.

The vendor’s network policy admitted only fixed, known IP addresses, a standard posture, and Snowflake connected from public cloud IP ranges.

Neither side was the company’s to change. The vendor’s network policy belonged to the vendor, and Snowflake’s addressing belonged to Snowflake. A direct stage against the vendor’s delivery point was off the table, so the company needed a location both systems could use as they were.

Every Feed Paid for a Double Copy

So the data took the long way. Vendor extracts landed on Files.com, the platform the company ran its vendor file deliveries through. From there they were copied onward into Azure Blob storage, and Azure Blob was mounted as the Snowflake stage. Every file was stored twice and moved twice before the warehouse ever read it.

The tax repeated on every feed. Deliveries ran daily, weekly, and monthly, and individual reservation extracts ran to tens of gigabytes, so the double copy meant duplicated storage and a second full transfer of some of the largest files in the pipeline, every cycle.

Even pointing a stage at the landing folder would not have worked on its own. The vendor created a new dated folder for each day’s delivery, so there was no stable path for a stage to target: the folder Snowflake needed to read did not exist until the morning the files arrived.

What the company needed was a staging location that satisfied three parties at once. A place the vendor would deliver to without changing its network policy. An endpoint Snowflake could read as a stage over its own protocol. And a path that stayed put while the folders underneath it changed daily. The company made Files.com that location itself, configuring the platform’s S3-compatible endpoint directly as a Snowflake external stage.

The Delivery Point Became the Stage

Files.com presents a site through its S3-Compatible API, so to Snowflake the platform looks like an S3 bucket: the warehouse authenticates against it, lists it, and reads files from it the same way it reads native cloud storage. The company pointed a Snowflake external stage at the endpoint, validated the connection, and the warehouse began reading vendor extracts at the place they landed.

Files.com turned the changing dated delivery folders into the stable path Snowflake required: a Copy Files automation with Flatten Folders collected each day’s delivery into a single flat folder that never moved. The vendor kept delivering exactly as it always had, Snowflake read from a path that never changed, and the automation bridged the two on every cycle.

Snowflake Reads Extracts Where They Land

With the stage in production, the company replaced a double-copy staging pipeline with a direct read: the warehouse pulls vendor extracts from the same platform the vendor delivers them to.

• The copy to Azure is gone from these feeds, and with it the added cost and added time the company was paying on every delivery: duplicated storage and a second transfer of files running to tens of gigabytes.
• Neither third party touched its network. The vendor delivers where it always delivered, and Snowflake stages from an endpoint built to be read that way.
• Adding a warehouse feed no longer means building a pipeline. A new daily, weekly, or monthly extract is a delivery folder and an automation rule, and the stage reads it like everything else.

A Stage Both Systems Use as They Are

Today, the company’s warehouse feeds do not depend on changes to networks it does not control. Files.com accepts files the way the vendor sends them and presents them the way Snowflake reads them. Neither partner changed anything, and the direct read exists anyway.