Azure Table Storage to Snowflake: How to Move Your Data

Moving Azure Table Storage into Snowflake puts non-relational rows somewhere you can join and aggregate them. Table Storage is built for fast key-based access at scale and answers almost nothing else, so anything shaped like how many or grouped by needs the data elsewhere.

There is a mismatch to plan for. Table Storage has no schema, and there is no efficient way to read one, so the connector does not try: every stream lands with the same generic shape, a single data property holding all the properties of each row.

Azure Table Storage to Snowflake at a glance:

Why move data from Azure Table Storage to Snowflake?

Two situations account for most of these pipelines.

The first is analysis Table Storage cannot do. Joins, aggregations and ad hoc filters are what a warehouse is for, and unlike a relational destination there is no volume ceiling to design around, which matters because Table Storage is usually chosen precisely when data gets large.

The second is a cross-cloud reality. Application data sitting in Azure while your analytical estate runs on Snowflake is common, and this is the bridge. If your querying already happens in Azure Synapse or Fabric, moving it may be work you do not need.

What do you need before you start?

One of these will disappoint a security-minded colleague and one determines whether the result is usable:

Your storage account name and access key. Found in the Azure portal under your storage account. Airbyte recommends creating a restricted key specifically for its access so you control what it can reach. The Azure Table Storage source documentation covers where to find them.

Acceptance that shared access key authentication is not supported. The connector does not support it yet, so if your organisation's policy is to issue scoped, time-limited shared access signatures rather than account keys, have that conversation before you build rather than after.

Knowledge of what your rows actually contain. Since no schema is read and no type mappings are applied, nothing in the pipeline will tell you. Ask whoever writes to these tables what the properties are and what types they hold, because that conversation becomes your casting layer.

Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. Airbyte creates one table per stream with its own metadata columns alongside your data.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.

How do you build an Azure Table Storage to Snowflake pipeline in Airbyte?

Step 1: Document what each table holds

Sit down with whoever owns the application writing to these tables and list the properties each one uses, including optional ones and any that changed type over the years. Nothing in this pipeline discovers that for you, so this list is the specification for your casting layer and the only documentation the dataset will ever have.

Step 2: Configure the Azure Table Storage source

Click Sources in the left navigation, then New Source, and select Azure Table Storage, following adding a source. Supply the storage account name and the restricted access key you created, then run the connection test.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role with your authentication method. The smallest warehouse is usually ample, since the work here is transferring rows rather than computing anything.

Step 4: Select tables and a sync mode

Click Connections, then New connection, select the tables from step 1 and choose a sync mode for each. Both full refresh and incremental are available. Rate limits are unlikely to constrain you here, so schedule against how often the data actually changes.

Run one table first and look at the result before extending. The generic schema means every table looks alike, so confirming that the data object contains what you expect is worth doing once per table shape rather than assuming.

Why is every stream the same shape?

Because Table Storage does not have a schema to read, and there is no efficient way to derive one. Rather than sampling rows and guessing, the connector uses a data property holding all the properties for any given row, which produces the same generic schema for every stream.

That is an honest design rather than a limitation, and it avoids a real failure mode: a connector that sampled rows to infer a schema would miss properties present on only a fraction of them. Nothing is dropped here, because nothing is inferred.

The cost lands on you, and a warehouse is a comfortable place to absorb it. Snowflake handles semi-structured data natively, so the landed object is queryable immediately rather than opaque, and building a typed layer over it is ordinary modelling work rather than a rescue operation.

How do you turn a data object into real columns?

With a view, and Snowflake is well equipped for it. Its semi-structured support lets you extract properties out of the data object and cast them in the same expression, so a modelled view sitting over the landed table is short to write and does the whole job.

Anchor that view on Table Storage's own keys. Every entity carries a partition key grouping related entities and a row key identifying it within that partition, and together they are the natural unique identifier. The partition key is usually meaningful too, since applications choose it to group entities read together, which makes it worth promoting to a proper column.

Decide per column how a bad value should behave. Snowflake gives you both options, since a try cast returns null on failure while a plain cast raises an error, and the loud version is right for anything a report depends on. Keeping the landed table underneath means either way you can reprocess once you know.

Frequently asked questions

Why do all my tables have the same schema?

Because Table Storage has no schema to read efficiently, so the connector uses a generic one where a data property holds all properties for each row. Extract and cast it in a view.

Can I use a shared access signature instead of the account key?

Not currently. Shared access key authentication is not supported by this connector yet, so plan on a restricted storage account key.

Are data types converted for me?

No. The connector applies no explicit data type mappings, so casting values into the types Snowflake should hold is work for your downstream view.

Is there a volume limit?

Not in practice. A warehouse scales with the source, which suits Table Storage because it is often chosen precisely when data outgrows a relational database.

Can I do this without writing code?

The Airbyte setup is entirely UI-driven. Extracting the data object into typed columns is SQL, and on this source it is the step that makes the dataset usable.

Get your Azure Table Storage data into Snowflake

Raise the authentication constraint early, document what each table holds because nothing else will, and treat the landed table as a staging layer. Then write the view that extracts and casts, promote the partition key to a real column, and choose per column whether a bad value should fail loudly.

Airbyte's connector catalog includes 600+ pre-built connectors, so application data can reach a warehouse and a lakehouse at once. For the lakehouse version, see Azure Table Storage to Databricks, and for another Azure source in a warehouse, Azure Blob Storage to BigQuery.

Start syncing now →