Federated Trino Report Joining Postgres and Iceberg with Slack KPIs

Query two systems as if they were one. This blueprint uses Trino's federation to join a live Postgres table with an Iceberg lakehouse table in a single SQL statement, no copy jobs and no staging area. The io.kestra.plugin.jdbc.trino.Query task runs the join twice with two different fetch strategies: once with STORE to persist the full result set as a file in Kestra's internal storage, and once with FETCH_ONE to compute a single KPI row that flows straight into a Slack message.

How it works

1. federated_export (io.kestra.plugin.jdbc.trino.Query, fetchType: STORE) joins postgres.public.orders with iceberg.analytics.events on order_id, filtered to the last day. The full result set lands in internal storage and is exposed as {{ outputs.federated_export.uri }} for downstream tasks, while {{ outputs.federated_export.size }} carries the row count.
2. compute_kpi (fetchType: FETCH_ONE) runs an aggregate over the same join and returns exactly one row with matched_orders, active_customers, and total_amount, addressable as {{ outputs.compute_kpi.row.* }}.
3. notify posts the three KPI scalars and the export row count to Slack.
4. The errors block posts a distinct Slack alert when either query fails, naming the flow and execution.
5. A disabled-by-default Schedule trigger runs the report daily at 07:00.

What you get

• A federated join across an operational database and a lakehouse table with zero data movement.
• The full result set stored as a file output, ready for downstream loads, exports, or audits.
• Headline KPIs delivered to Slack as plain scalars, safe to interpolate into a JSON payload.
• A failure alert so a broken catalog or credential never fails silently.

Who it's for

• Data engineers who need cross-system reporting without building a copy pipeline first.
• Analytics teams joining operational Postgres data with historical Iceberg data.
• Platform teams standardizing on Trino as the single SQL access layer.

Why orchestrate this with Kestra

Trino answers the query, but someone still has to run it on schedule, keep the result somewhere durable, tell the team what it said, and raise a hand when it breaks. Kestra wraps the unchanged SQL with scheduling, internal storage for the full export, output passing into notifications, retries, and a complete execution history, all declared in a few lines of YAML.

Prerequisites

• A Trino cluster with a postgres catalog and an iceberg catalog configured.
• Tables matching postgres.public.orders and iceberg.analytics.events, or adjust the SQL to your schema.
• A Slack incoming webhook for the report and failure alerts.

Secrets

• TRINO_URL: JDBC URL, e.g. jdbc:trino://host:443/postgres/public (use https on 443 in production; password authentication requires TLS).
• TRINO_USERNAME: Trino username.
• TRINO_PASSWORD: Trino password.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Adjust the two SQL statements to your catalogs, schemas, and column names.
3. Execute the flow and check the Slack message plus the stored export in the execution's Outputs tab.
4. Set disabled: false on the daily trigger.

How to extend

• Add more KPI columns to compute_kpi and interpolate them into the Slack payload.
• Feed {{ outputs.federated_export.uri }} into a downstream task to load the export into a warehouse or object storage.
• Join additional catalogs (MySQL, Kafka, MongoDB) in the same statement; Trino federates them all.
• Tighten the time window or parameterize it with a flow input.

Links

• Trino plugin documentation
• Trino documentation