Query data in Snowflake

Run SQL against a Snowflake data warehouse directly from a Kestra workflow and make the results available to downstream tasks. This blueprint connects to Snowflake over JDBC, executes a query, and returns rows you can pass into reporting, transformation, or export steps. It solves the common problem of stitching Snowflake queries into a reliable, observable pipeline instead of running them ad hoc from a worksheet or a brittle script.

How it works

• The query task uses io.kestra.plugin.jdbc.snowflake.Query to connect to your Snowflake account.
• The url points at your Snowflake JDBC endpoint and selects a warehouse (for example warehouse=COMPUTE_WH).
• Authentication uses username plus a password resolved from the SNOWFLAKE_PASSWORD secret, so no credentials live in the YAML.
• The sql property holds the statement to run. The example selects from SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER.
• fetchType: FETCH_ONE returns only the first row. Use FETCH to return all rows in memory, or STORE to write results to Kestra internal storage as a downloadable file for large result sets.

What you get

• A single, declarative task that runs any Snowflake SQL statement.
• Query results captured as workflow outputs for downstream consumption.
• Credentials kept out of code via Kestra secrets.
• A flexible fetch model (FETCH_ONE, FETCH, STORE) tuned to result size.

Who it's for

• Data engineers building Snowflake ingestion and transformation pipelines.
• Analytics engineers automating scheduled extracts and reports.
• Platform teams who want Snowflake queries under version control and observability.

Why orchestrate this with Kestra

Snowflake tasks and streams can schedule SQL inside the warehouse, but they cannot coordinate work beyond it. Kestra adds event and schedule triggers, automatic retries on transient failures, full execution lineage and logs, and declarative YAML that lives in Git. You can chain the Snowflake query to upstream loads and downstream exports, branching, and notifications, filling the cross-system orchestration gap Snowflake's own scheduler leaves open.

Prerequisites

• A Snowflake account with an accessible warehouse and a user that can run the query.
• Network access from Kestra to your Snowflake JDBC endpoint.

Secrets

• SNOWFLAKE_PASSWORD: the password for the Snowflake user in the username property.

Quick start

1. Add the blueprint to your Kestra instance.
2. Set the SNOWFLAKE_PASSWORD secret in your environment.
3. Update url with your account identifier and target warehouse, and set username.
4. Adjust the sql to your table or query.
5. Execute the flow and inspect the query output in the execution view.

How to extend

• Switch fetchType to STORE and feed the output file into a downstream load or export task.
• Add a Schedule trigger to run recurring extracts or reports.
• Parameterize the SQL with inputs to make the query reusable across tables or date ranges.
• Chain additional tasks to transform, validate, or ship the results (for example to cloud storage or a notification channel).

Links

• Plugin docs
• Snowflake orchestration