Skip to main content
Destination nodes persist or deliver the results of your graph. They define where data lands, how conflicts resolve, and what happens to existing target data on each run.

​
Write

Write is the standard relational or warehouse table writer. Configuration:
  • Connection and target object: Database, schema, table (or equivalent).
  • Write mode: See Write modes below.
  • Key columns (for upserts): Primary or business keys used for merge semantics.
  • Column map: Source to target names and casts.
  • Pre/post SQL (when supported): Run maintenance statements cautiously—document and review.
Typical use: Load curated fact and dimension tables consumed by BI tools or downstream pipelines.

​
Cloud Destination

Cloud Destination writes to object stores (Amazon S3, Google Cloud Storage, Azure Blob) or similar with format options. Configuration:
  • Path template: Partition folders (year=2025/month=03/) for query engines.
  • File format: Parquet, CSV, JSON Lines, Avro—match consumers.
  • Compression: Snappy, ZSTD, gzip—balance CPU vs storage.
  • Credentials: Via connections; avoid embedding keys in paths.
Typical use: Data lake landing zones feeding Iceberg or external tables.

​
Iceberg Destination (professional+)

Iceberg Destination commits Apache Iceberg snapshots with ACID properties when your catalog is wired correctly. Configuration:
  • Table identifier and catalog.
  • Write mode: Append vs overwrite partitions vs merge (per support matrix).
  • Schema evolution: Coordinate with Schema Evolution nodes when columns change.
Typical use: Lakehouse marts where readers expect snapshot isolation and time travel.

​
Webhook Action

Webhook Action POSTs (or otherwise invokes) an HTTP endpoint with a payload built upstream—often from a JSON Builder. Configuration:
  • URL, method, headers: Include auth headers via secret references.
  • Body: Template bound to row batches or single aggregate payloads.
  • Batching: Rows per request to respect API limits.
  • Retry / timeout: Align with partner SLAs.
Typical use: Push alerts or small transactional updates to SaaS APIs that do not warrant a full reverse ETL sync.
Webhooks can duplicate on retries. Use idempotency keys or destination-side deduplication when the API supports it.

​
Write modes

Insert appends new rows only. The run fails on unique-key violations if the target enforces constraints—good for append-only facts with surrogate keys generated upstream.

​
Pre-flight checklist

1

Confirm environment

Verify variables and environments so you do not write to production with dev credentials—or the reverse.
2

Align grain and keys

Upsert keys must match the grain you intend (per line item vs per order). Test with duplicate-source scenarios.
3

Dry run or preview

Preview upstream nodes; for relational targets, run against staging schemas first.
4

Observe first production cycles

Watch row counts, reject files, and warehouse credit usage after go-live.

Sources

Read back what you wrote for reconciliation jobs.

Data quality

Validate before and after loads.