Looker to Snowflake: How to Move Your Data

Moving Looker into Snowflake gives you two things most BI connectors cannot: a queryable inventory of your reporting estate, and the ability to pull the results of saved Looks directly. The first answers what exists and who owns it, the second turns a curated Look into a table.

This guide covers the managed path with Airbyte. The thing to settle early is whose API key you use, because on this connector that choice affects not just which dashboards you can see but what data comes back when a Look runs.

Looker to Snowflake at a glance:

Why move data from Looker to Snowflake?

Two situations account for most of these pipelines, and they use different halves of the connector.

The first is BI governance. Once an instance holds hundreds of dashboards, nobody can say which are used, which duplicate each other, or which would break if a table changed. A queryable catalogue answers all three, and the LookML model streams are what let you trace a dashboard back to the tables behind it.

The second is capturing curated logic. A Look encodes filters and definitions somebody agreed, and running it through the pipeline gives you that result as a table rather than reimplementing the logic in SQL and hoping the two agree.

What do you need before you start?

Short list, and one item is a decision with consequences beyond access:

An API3 key and your Looker domain. The key is a client identifier and secret generated for a specific user in the Looker admin panel, and the domain is your instance address. Self-hosted instances are supported. The Looker source documentation points at Looker's own instructions for generating it.

A deliberate choice of which user owns that key. An API3 key belongs to a Looker user and carries their permissions, so it sees the content that user can see. For a governance inventory you want broad visibility; for running Looks you also inherit that user's data access.

A shortlist of Looks worth running. Running a Look executes a query against your underlying database, so this is not free in the way reading a catalogue is. Pick the ones encoding logic you actually want as a table rather than everything saved in the instance.

Snowflake objects and a role. A warehouse, database, schema and a role able to create tables. The catalogue itself is small, so the smallest warehouse is ample unless you are pulling substantial Look results.

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

How do you build a Looker to Snowflake pipeline in Airbyte?

Step 1: Choose the account behind the key

Create a service user in Looker rather than generating a key from somebody's personal account, and decide what it can see. A key made from an individual's login stops working when they leave, and quietly changes what your dataset contains when their permissions change.

Step 2: Configure the Looker source

Click Sources in the left navigation, then New Source, and select Looker, following adding a source. Supply the domain, client identifier and client secret. If you intend to retrieve Look results, specify the Look you want here rather than expecting every saved Look to arrive.

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. Keeping the catalogue streams and any Look results in separate schemas is worth doing, since they are different kinds of data with different audiences.

Step 4: Create the connection and schedule slowly

Click Connections, then New connection, select your streams and a sync mode. Daily is generous for a BI catalogue, which changes when somebody builds a dashboard. Rate limits should not trouble you, since the connector is not expected to hit Looker's limits under normal usage.

Give any Look you run its own schedule if the underlying query is heavy, because that request lands on whatever database Looker sits over rather than on Looker itself.

Why is running a Look different from reading the catalogue?

Because one describes and the other executes. Reading dashboards and models asks Looker about itself, which is cheap and harmless. Running a Look makes Looker issue a query against the database underneath it, so the cost lands on your warehouse or production database rather than on the BI tool.

That is also what makes it valuable. A Look encodes filters, joins and definitions that somebody agreed and other people rely on, and capturing its output means your table and the dashboard cannot disagree. Reimplementing the same logic in SQL is how two numbers with the same name start to drift.

So treat it as a query you are scheduling rather than a stream you are selecting. Pick a small number of Looks that encode logic worth preserving, check what their queries actually do, and schedule them with the same care you would give any recurring job against that database.

Why does the key's owner shape your data?

Because an API3 key grants access on behalf of the Looker user it belongs to, and Looker's permission model covers both content and data. Content permissions decide which folders, dashboards and Looks the key can see at all.

Data permissions matter more, and only when running Looks. If your Looker instance applies row-level restrictions by user attribute, a Look run through this pipeline returns the rows that user is allowed to see, so the same Look can yield different results depending on whose key executed it.

That is worth writing down alongside the dataset, because a table whose contents depend on an invisible attribute is confusing later. Use a service user with clearly documented access, and if your instance relies heavily on user attributes, check a known Look's output against what an unrestricted user sees before trusting it.

Frequently asked questions

Can I get the actual data behind a dashboard?

Through a Look, yes. The connector can run a saved Look and return its results, which is unusual among BI connectors and means the query executes against your underlying database.

Why can the pipeline not see some dashboards?

The API3 key carries the permissions of the Looker user it belongs to, so it sees exactly the content that user can. Use a service account with the visibility your inventory needs.

Does this work with a self-hosted Looker?

Yes. The connector supports self-hosted instances, so supply your own domain rather than a hosted address.

Will this hit Looker's rate limits?

It should not under normal usage. The cost to watch is the database query a Look triggers, rather than the Looker API itself.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want Snowflake views joining dashboards to models so you can trace which reports depend on which tables.

Get your Looker data into Snowflake

Use a service user and document what it can see, because the key's owner decides both your inventory and, for Looks, the rows that come back. Keep catalogue and Look results in separate schemas, run only the Looks that encode logic worth preserving, and schedule those against the database underneath rather than against Looker.

Airbyte's connector catalog includes 600+ pre-built connectors, so your BI estate can sit beside the data it reports on. For another BI catalogue source, see Metabase to BigQuery, and for a lakehouse catalogue, Dremio to PostgreSQL.

Start syncing now →