Download icon
CsvToIon icon
Queries icon
Split icon
Loop icon
Batch icon
Query icon
Assert icon
Schedule icon

Publish CSV snapshots to PostgreSQL after bounded parallel staging

Load CSV snapshots with bounded Kestra Loop concurrency, duplicate checks, and a PostgreSQL transaction that preserves the last good dataset on failure.

Categories
Data

Load a CSV export without exposing a partially loaded PostgreSQL table. This Kestra 2.0 pattern uses Split and Loop, with no custom script or subflow.

How it works

  1. Download an immutable CSV export and parse it into binary ION. Quoted commas and newlines are parsed before records are split.
  2. Split the ION file into bounded chunks. Loop loads at most three chunks at once into staging rows owned by this execution.
  3. Compare the unique staged row count with the CSV record count. Reject duplicate order IDs and empty exports unless explicitly allowed.
  4. Lock the live table, recheck counts through database constraints, and publish all rows in one transaction. Record the execution and row count.

What you get

  • csv_snapshot.orders: one complete snapshot, including source deletions.
  • Typed, constrained staging that leaves live rows untouched on bad input.
  • Bounded database parallelism and per-chunk task history.
  • A publication ledger, row counts and staging rows for investigation.

Who it's for

Data engineers loading recurring full exports that are too large for one in-memory template or one task per CSV row.

Why orchestrate this with Kestra

Native tasks separate parsing, chunk loading and publication. Loop controls database pressure; a failed chunk cannot publish a partial snapshot.

Prerequisites

Kestra 2.0, CSV Serdes and PostgreSQL plugins, network access to the source URL and database, and a role that can create tables in csv_snapshot. The CSV header must be order_id,customer_name,customer_email,product_id,price,quantity,total. IDs are integers; price and total are nonnegative numbers; quantity is positive. This flow owns the destination table. Use a dedicated schema and one publisher.

Secrets

  • SNAPSHOT_JDBC_URL: target PostgreSQL JDBC connection URL.
  • SNAPSHOT_USER and SNAPSHOT_PASSWORD: database credentials.

Quick start

  1. Set the secrets, import the flow, and keep the schedule disabled.
  2. Execute with the public sample or your immutable export URL.
  3. Check row counts, loop tasks and csv_snapshot.orders before scheduling.
  4. Set chunk size for your database capacity. Empty exports fail by default.

How to extend

Adapt the seven columns and constraints to your export. Add business checks before publication. Archive staging rows, then delete old execution rows after your recovery window. Staging is retained; plan storage accordingly. Restart a failed staging task for the same downloaded file, or run a new execution for a new source version. Do not resume an old snapshot after a newer publication.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.