Files.com Lets Snowflake Read Ryman’s 40 GB Extracts Without an Azure Blob Copy

Ryman Hospitality Properties built its hospitality business around Gaylord-branded resorts, convention centers, spas, and auditoriums across several U.S. cities. Its business is group and convention travel at a scale few hotel operators reach.

Ryman 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 Ryman’s own walls. That data reached Ryman the way partner data usually does: as files. Providers delivered loyalty enrollment and reservation extracts on daily, weekly, and monthly cycles, and Ryman’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 one vendor’s security posture put a wall across that path. Ryman turned Files.com into the Snowflake stage itself, eliminating the Azure Blob copy without asking either third party to change.

The Vendor Would Not Let Snowflake In

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 refused. Snowflake connected from public cloud IP addresses, and the provider would not add public IPs to its whitelist.

“They don’t want to because the IP is not a private IP on Snowflake.”

Neither side of the impasse was Ryman’s to change. The vendor’s network policy belonged to the vendor, and Snowflake’s addressing belonged to Snowflake. The two companies Ryman needed to connect had, between them, ruled out a direct connection.

Every Feed Paid for a Double Copy

So the data took the long way. Vendor extracts landed on Files.com, the platform Ryman 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.

“I have the data coming into Files.com, and then I’m having to copy it to Azure, and then I’m having to mount Azure as a stage, so I have added cost and added time.”

The tax repeated on every feed. Deliveries ran daily, weekly, and monthly, and individual reservation extracts ran past 40 GB, 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 Ryman 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. Ryman 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. Ryman 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, Ryman 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 Ryman was paying on every delivery: duplicated storage and a second transfer of files running past 40 GB.
• The whitelisting impasse is dissolved without either third party touching 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.

An Impasse Removed, Not Negotiated

Today, Ryman’s warehouse feeds no longer depend on an agreement between two companies whose networks Ryman does not control. Files.com accepts files the way the vendor is willing to send them and presents them the way Snowflake is able to read them. The impasse was never resolved. It was removed.