Output node
Snowflake output
Load rows into a Snowflake table, creating it if it doesn't exist.
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
| Inputs | One. |
| Outputs | None. 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.