Browse the docs
Output node

Snowflake output

Load rows into a Snowflake table, creating it if it doesn't exist.

Category
Output
Connection
Snowflake

What it does

Loads the incoming rows into a Snowflake table through a saved Connection. Rows are sent in large batches as a single bound payload that Snowflake unpacks server-side, so there is no file staging to configure and no cloud bucket required. The table is created automatically if it doesn't exist.

Inputs and outputs

InputsOne.
OutputsNone. This node ends a pipeline.

When to use it

  • Land prepared data in the warehouse for reporting
  • Refresh a reporting table on a schedule
  • Move data from a database, a file or an API into Snowflake

Examples

Load staging, then merge

Pre-SQL: TRUNCATE TABLE STG_ORDERS · Post-SQL: MERGE INTO ORDERS t USING STG_ORDERS s ON t.ID = s.ID WHEN MATCHED THEN UPDATE SET t.TOTAL = s.TOTAL WHEN NOT MATCHED THEN INSERT (ID, TOTAL) VALUES (s.ID, s.TOTAL)

Snowflake has no upsert write mode, so a MERGE in post-SQL is how a load becomes safe to repeat.

Append

ANALYTICS.PUBLIC.EVENTS

Adds rows to whatever is already there.

Full refresh

Write mode: truncate

Empties the table first, then loads.

Tips

  • Each pre- and post-SQL statement has its own ⤢, the SQL Studio, with the connection's tables and columns beside the statement. It has no Run button: a Test run executes none of these statements.
  • Pre-SQL and post-SQL run on this same connection, around the load. Pre-SQL runs and commits BEFORE the load starts; post-SQL runs only AFTER it has finished successfully, so a failed load never fires the merge.
  • One statement per row, run in order. If one fails the run stops there, and the message names which statement it was and what the database said.
  • A Test run (Run to here) writes nothing and executes none of them, so testing stays safe on a pipeline whose pre-SQL truncates a table.
  • No staging bucket or stage is needed: the rows travel with the statement, so there's nothing to set up and nothing left behind.
  • Every value travels as a bound parameter, never pasted into the SQL text, so a whole number past 2^53 keeps every digit.
  • The load is not all-or-nothing: a truncate and the load that follows are separate steps, so a failure in between can leave the table partly loaded. Re-running fixes it.
  • An auto-created table gets column types derived from the incoming data. If the table already exists, its own types win.
  • There is no upsert mode: merging is a MERGE against a staging table, which is better built explicitly as its own step.