New to Kestra?
Use blueprints to kickstart your first workflows.
Orchestrate an idempotent, transactional MERGE upsert into SQL Server with Kestra. Stage changed rows, MERGE with dedup, and advance a watermark atomically.
An incremental load into SQL Server is rarely one statement. It is stage the delta, dedupe it, MERGE it into the target, then move the watermark forward, and if any one of those steps fails partway, the target table needs to end up exactly where it started. This blueprint runs the MERGE and the watermark update inside a single io.kestra.plugin.jdbc.sqlserver.Queries transaction, so a failure anywhere in that block rolls back completely instead of leaving a half-applied batch or a watermark that has drifted ahead of what actually committed.
read_watermark (io.kestra.plugin.core.kv.Get) reads the inventory_merge_watermark key, falling through to the epoch on the first run.stage_new_rows (io.kestra.plugin.jdbc.sqlserver.Query) selects every row from dbo.inventory_updates changed since the watermark and stores it with fetchType: STORE.merge_and_advance_watermark (io.kestra.plugin.jdbc.sqlserver.Queries) runs a MERGE statement that updates matched rows and inserts new ones by sku and warehouse_id, then an afterSQL statement advances a watermark tracking table, both inside the same transaction (transaction defaults to true), so a failed MERGE rolls back the watermark update too.row_check (io.kestra.plugin.core.flow.If) flags the unusual case where rows were staged but the MERGE reported no output, which usually means a schema mismatch between the staging and target tables.advance_watermark (io.kestra.plugin.core.kv.Set) persists the new watermark to the KV Store only after the transactional MERGE has already committed downstream.notify confirms the row count and watermark; the errors block alerts separately on any failure.sku, warehouse_id), collapsing late or duplicate rows instead of letting them accumulate downstream.INSERT loop cannot provide.A stored procedure can run a MERGE, but coordinating the watermark update, the failure rollback, and the alerting all inside one transaction usually means hand-writing TRY/CATCH and XACT_ABORT logic in T-SQL, with no execution history outside the database itself. Kestra wraps the MERGE and the watermark advance in one Queries transaction, gives the whole run a versioned YAML definition and full execution history, and separates the success and failure notification paths declaratively instead of embedding them in the stored procedure.
dbo.inventory_updates), a staging table (dbo.inventory_staging), a target table (dbo.inventory_current), and a watermark tracking table (dbo.merge_watermarks).SQLSERVER_URL: JDBC URL, for example jdbc:sqlserver://your-host:1433;trustServerCertificate=true.SQLSERVER_USERNAME / SQLSERVER_PASSWORD: database credentials.SLACK_WEBHOOK_URL: Slack incoming webhook URL.every_15_minutes schedule.inventory_merge_watermark key after each run to confirm it advances.MERGE statement's match keys with your own natural or surrogate key.merge_and_advance_watermark succeeds.row_check to catch an unexpectedly large batch before it commits.Schedule trigger for a Flow trigger so the merge fires the moment an upstream load finishes instead of on a fixed interval.