Grafana Cloud k6 to Snowflake: How to Move Your Data
Move Grafana Cloud k6 into Snowflake with Airbyte. Why the connector carries the catalogue rather than results, and how appended snapshots reveal deletions.
Moving Grafana Cloud k6 into Snowflake gives you a record of your performance testing estate beside everything else you measure. How many tests exist, who owns them and how that has changed are governance questions, and the interface is built for running tests rather than auditing them.
This guide covers the managed path with Airbyte, and one thing has to be said before anything else: this connector carries the catalogue, not the results. Beyond that, every stream is full refresh, which decides whether you end up with a snapshot or a history.
Grafana Cloud k6 to Snowflake at a glance:
Why move data from Grafana Cloud k6 to Snowflake?
Two situations account for most of these pipelines, and both are narrower than people expect.
The first is governance of the testing estate. Which projects hold tests, how many have accumulated and which were quietly deleted are questions nobody can answer from inside the tool, and they matter once performance testing is spread across several teams.
The second is joining that catalogue to the delivery data around it. Be clear that this is not performance analysis, since no results come through this connector. If you want to search the catalogue rather than model it, Grafana Cloud k6 to Elasticsearch covers that shape instead.
What do you need before you start?
Four things, and the first is a scoping conversation rather than a credential:
Agreement that results are out of scope. Three streams are available and none of them carries metrics or run outcomes. The Grafana Cloud k6 source documentation lists what exists, and it is worth showing to whoever asked for this.
A stack token rather than a personal one. Both authenticate, and a personal token is tied to an individual, so it leaves with them and takes your pipeline with it.
Snowflake objects and a role. A warehouse, database, schema and a role that can create tables. The smallest warehouse is ample for a dataset this size.
A decision about keeping history. Because syncs are full refresh, whether these tables show current state or accumulate a record is something you choose rather than something the pipeline provides.
If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.
How do you build a Grafana Cloud k6 to Snowflake pipeline in Airbyte?
Step 1: Use a token that outlives its creator
Create a stack token rather than reaching for the personal one you already have. They behave identically until the day the person who created the personal token changes role or leaves, at which point a pipeline nobody is watching stops and the reason is not obvious from the failure. This is a two-minute decision that saves an afternoon of confusion a year from now.
Step 2: Configure the Grafana Cloud k6 source
Click Sources in the left navigation, then New Source, and select Grafana Cloud k6, following adding a source. Supply the API token, which is essentially the whole configuration. Three streams appear, describing your organisations, projects and the tests defined within them.
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. Give this its own schema so a catalogue of testing metadata is not mixed into general reporting tables.
Step 4: Create the connection and choose append over overwrite
Click Connections, then New connection, select your streams and a sync mode. Only full refresh is available, and the variant decides everything: overwrite gives you a current inventory, while append accumulates a snapshot per run and is what makes the interesting questions answerable.
Daily is generous for a catalogue that changes when somebody creates a test, and the dataset is small enough that frequency costs nothing either way.
How do you turn repeated snapshots into history?
By appending, because the source only ever describes the present. Every sync reads all three streams from scratch, so overwrite leaves you with a table that is permanently current and permanently without memory. That is fine for an inventory and useless for the governance questions that usually motivate this.
Full refresh append builds the record instead, adding a complete copy of your organisations, projects and tests on each run. Because the dataset is tiny, doing that daily for years costs almost nothing, which makes this one of the cheapest historical records you will ever assemble.
Then build the views that make it legible. One selecting the most recent extraction, which is the current inventory. One deriving when each test first appeared and when it stopped appearing, which is how you detect deletions the source itself will never report. A test that vanished between two snapshots is exactly the kind of thing an estate review wants to know about, and it is invisible without the accumulated copies.
What can you do with half a testing dataset?
Rather more than it first appears, provided nobody expected performance figures. What you have is the structure of your testing effort: which projects exist, how tests are distributed across them, and how that has changed. What you do not have is whether anything passed, how long anything took, or what any percentile was.
That division is worth stating plainly to whoever commissioned the work, because performance testing data sounds like it means results. Handing over a catalogue when somebody expected response time trends is a disappointing end to a technically correct project, and the conversation is much easier before the pipeline exists than after.
The productive move is joining it to what you do have elsewhere. Set the test catalogue against your delivery data, so you can ask whether teams shipping most often are the ones maintaining tests, or against incident records, to see whether services suffering outages had any performance coverage at all. Those are real questions, and they need a warehouse precisely because the answer lives in two systems.
Frequently asked questions
Can I get test results or metrics?
No. The three available streams describe organisations, projects and tests, and none of them carries run outcomes, metrics or percentiles.
Why is there no incremental sync?
The connector supports full refresh only. Choose append rather than overwrite if you want a record of how the estate changed.
How do I find deleted tests?
From accumulated snapshots, by finding identifiers present in an earlier extraction and absent from later ones. Overwrite discards exactly that evidence.
Which token should I use?
A stack token, since a personal one is tied to an individual and stops working when they move on, in a way the failure does not explain.
Can I do this without writing code?
The pipeline, yes, and the setup is one field. The views over accumulated snapshots are modest SQL and they are what makes the data worth having.
Get your Grafana Cloud k6 data into Snowflake
Establish first that this is the catalogue rather than the results, because the word performance makes people assume otherwise. Use a stack token so the pipeline survives staff changes. Choose append over overwrite, since the source describes only the present and your snapshots are the only history that will exist. Then expose a current view and a historical one, and join the catalogue to delivery or incident data, which is where the real questions live.
Airbyte's connector catalog includes 600+ pre-built connectors, so engineering tooling can be governed alongside everything else. For error tracking into the same destination, see Sentry to Snowflake, and for source control activity into the same destination, Github to Snowflake.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.