Execute a Parameterised SQL Query on Postgres

Execute parameterised SQL queries against a PostgreSQL database and capture the full result set as reusable data, without writing custom database scripts or scheduling cron jobs by hand. This blueprint turns an ad hoc Postgres query into a declarative, parameter-driven Kestra flow: you pass the SQL statement at runtime, the connection URL stays safe in a secret, and every returned row is stored so downstream tasks can read it. It is a building block for extractions, health checks, and reporting on top of Postgres.

How it works

1. The flow exposes a single query input of type STRING (default SELECT * FROM sometable) so the SQL statement is supplied at execution time instead of being hardcoded.
2. The query_postgres task (io.kestra.plugin.jdbc.postgresql.Queries) opens a JDBC connection using url: {{ secret('POSTGRES_URL') }} and runs the statement from {{ inputs.query }}.
3. With fetchType: STORE, all result rows are written to Kestra's internal storage and exposed as an output URI, ready to be consumed by later tasks or downstream flows.

What you get

• A reusable, parameterised query template you can call with any SQL statement.
• Every result row persisted via fetchType: STORE rather than truncated or logged.
• Database credentials kept out of the flow definition through a secret.
• A clean output URI that other tasks and subflows can read.

Who it's for

• Data engineers who want a parameterised query block inside larger ETL pipelines.
• Database administrators automating routine health checks and scheduled extractions.
• Analytics teams pulling periodic data snapshots without maintaining bespoke scripts.

Why orchestrate this with Kestra

Postgres has no built-in scheduler or pipeline engine of its own (pg_cron only fires SQL on a timer, with no retries, inputs, lineage, or downstream wiring). Kestra fills that gap: drive the query from event or schedule triggers, add automatic retries on transient connection failures, track inputs and outputs as lineage across executions, and keep everything as declarative, version-controlled YAML. The stored result becomes an input to any downstream task, which raw psql or pg_cron cannot coordinate.

Prerequisites

• A reachable PostgreSQL database and a JDBC connection URL.
• A Kestra instance with the JDBC PostgreSQL plugin available.

Secrets

• POSTGRES_URL: the JDBC connection URL for your Postgres database (including host, port, database, and credentials).

Quick start

1. Add the POSTGRES_URL secret to your Kestra instance.
2. Add this flow to a namespace (the example uses company.team).
3. Execute the flow, supplying your SQL statement in the query input.
4. Open the execution and inspect the stored output of query_postgres to retrieve the result rows.

How to extend

• Add a Schedule or other trigger to run the query on a cadence or in response to events.
• Feed the stored output into a transform or export task (CSV, Parquet, cloud storage).
• Swap the single statement for multiple statements, or parameterise more inputs (table name, filters, limits).
• Chain a notification task to alert teams when a health-check query returns unexpected rows.

Links

• Plugin docs: https://kestra.io/plugins/plugin-jdbc-postgres
• Orchestrate Postgres with Kestra: https://kestra.io/orchestration/postgres