Targets and load methods

The fastest load is rarely reading rows and inserting them. It’s letting the warehouse bulk-load files: straight from your bucket or folder when the data is already in files, or from a stage that SQLLoad fills with Parquet. SQLLoad picks that route wherever it loads the data exactly, and plan names the route for every table.

How data gets in

Into	Parquet files in S3 or a folder	CSV, JSON, NDJSON files	Postgres or Python rows
DuckDB	DuckDB reads them with read_parquet	Read by SQLLoad, appended as Arrow	Appended as Arrow
MotherDuck (beta, from 0.33.0)	Read by SQLLoad, appended as Arrow	Read by SQLLoad, appended as Arrow	Appended as Arrow
Snowflake	COPY from an external stage over the bucket	COPY from an external stage over the bucket	Written as Parquet to the load_method’s stage, then COPY (or streamed or inserted, if the load_method says so)
Databricks	Staged by SQLLoad in the volume, then COPY INTO	Read by SQLLoad, staged as Parquet in the volume, then COPY INTO	Written as Parquet to the volume, then COPY INTO
BigQuery (preview)	Read by SQLLoad, streamed as Arrow into a staging table, then one query job	As for Parquet files	Streamed as Arrow into a staging table, then one query job
ClickHouse (preview)	In S3: ClickHouse reads them with s3() into a staging table. In a folder: read by SQLLoad, sent as Arrow	Read by SQLLoad, sent as Arrow into a staging table	Sent as Arrow into a staging table, then swapped in by table or partition
Postgres	Read by SQLLoad, then binary COPY into a temporary staging table	As for Parquet files	Binary COPY into a temporary staging table, then one transaction per commit

There are no silent fallbacks. If the route a table needs can’t be used, plan fails for that table and says how to fix it.

Targets

A target is where loaded tables go. It names a connection and where tables are placed in it. A project can have several targets, for example one per environment; each source loads into its destination, or the project’s default_target.

Connection kind	Target writes	Places tables with
snowflake	Snowflake tables	loader_schema, and optionally database
databricks	Unity Catalog tables	loader_schema, in the connection’s catalog
bigquery (preview)	BigQuery tables	loader_schema as the dataset, in the connection’s project
clickhouse (preview)	ClickHouse tables	loader_schema as the database
postgres	Postgres tables	loader_schema, and optionally database
duckdb	DuckDB tables	loader_schema
motherduck (beta, from 0.33.0)	MotherDuck tables	loader_schema, and optionally database
s3, filesystem	Parquet or CSV files, one folder per table	path

Warehouse targets

A Snowflake, Databricks, BigQuery, ClickHouse, Postgres or DuckDB target places tables in a schema (a dataset in BigQuery, a database in ClickHouse):

[connections.warehouse]
kind = "duckdb"
database = "shop.duckdb"

[targets.local]
connection = "warehouse"
loader_schema = "raw"

Key	Meaning
connection	A snowflake, databricks, bigquery, clickhouse, postgres or duckdb connection, or from 0.33.0 a motherduck connection.
loader_schema	The schema for tables whose source sets no schema. Required.
database	Overrides the connection’s database. Not for ClickHouse.

A source’s schema overrides loader_schema for its tables. A DuckDB connection’s database is a file path, or :memory:. A Snowflake connection also needs a load_method; see Snowflake. A Postgres target uses the same connection kind as a Postgres source.

Each kind has its own page: Snowflake, Databricks, BigQuery, ClickHouse, Postgres, DuckDB, MotherDuck and Parquet files.