Question 1

What file formats are supported?

Accepted Answer

CSV, JSON including both arrays and newline delimited records, and Parquet. That range covers most of what lands in a bucket, whether it is an export from another system, a partner feed or the output of a job. Parquet carries its own schema, which makes typing more reliable than delimited formats where everything arrives as text until something infers otherwise.

Question 2

How do files map to tables?

Accepted Answer

Three ways, depending on how the bucket is laid out. A single file can become one table. Many files matching a pattern can be concatenated into one named table, which is the usual arrangement for partitioned exports. Directory and expression patterns can also produce multiple tables at once. Values captured from the key path, such as a date or region folder, become columns, so partitioning that exists only in the path survives into the data warehouse, and every row can carry the object key, timestamp and size. That mapping is decided once when you configure the ETL and then applied on every run.

Question 3

Is ingestion event driven or scheduled?

Accepted Answer

Scheduled. Polytomic scans the bucket on the schedule you set rather than subscribing to Google Cloud Storage object notifications, so plan the cadence around how often files land. If you need ingestion driven by file arrival rather than by a clock, that is worth raising before you build around it, because the timing characteristics are different and a tight schedule is not the same thing as an event trigger.

Question 4

What happens when a file or record disappears?

Accepted Answer

There is no object deletion event, so removals are handled by reconciliation rather than by tombstones. A complete scan can remove rows absent from the current file set, but that only works if rows have stable identity, which files do not provide on their own. Either select the object metadata and path fields as part of the key or configure a custom primary key. Two other things to watch: single table mode concatenates every matching file, so schemas have to be compatible, and malformed CSVs with empty or duplicate headers are skipped during discovery rather than failing loudly.

Question 5

Why route files through an ETL pipeline rather than loading them directly?

Accepted Answer

Snowflake can read from object storage itself, so the case here is about the surrounding work rather than the copy. Schema creation and migration are handled, path values become columns without writing extraction logic, format and compression handling is uniform across feeds, and the load sits in the same place as the rest of your ETL with the same scheduling, monitoring and alerting. For one well defined feed the difference is small. Across many feeds maintained by different teams it is the difference between a system and a pile of scripts.

Sync Google Cloud Storage to Snowflake

Sync Google Cloud Storage to Snowflake with Polytomic

CSV, JSON and Parquet

Path values become columns

Three ways to map files

Or sync Snowflake to Google Cloud Storage

Trusted by businesses worldwide

Step-by-step integration guide

Connect Google Cloud Storage in Polytomic

Connect Snowflake in Polytomic

Create a sync between Google Cloud Storage and Snowflake

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect Google Cloud Storage with Snowflake?