Query icon
Assert icon
If icon
Loop icon
Queries icon
Schedule icon

Refresh PostgreSQL materialized views in dependency order

Refresh PostgreSQL materialized views in dependency order, checking indexes, population and privileges before changing any view.

Categories
Data

A downstream materialized view can stay stale if it refreshes before its upstream view. This flow orders an explicit refresh set using PostgreSQL dependencies, including dependencies reached through ordinary views. It uses native JDBC tasks.

How it works

  1. Run manually or hourly. Read pg_rewrite and pg_depend to build a refresh plan.
  2. Reject duplicates, missing upstream materialized views, unpopulated views, unsuitable unique indexes and missing MAINTAIN privileges before any refresh.
  3. With dry_run: false, a serial Loop runs REFRESH MATERIALIZED VIEW CONCURRENTLY. Each view commits before its dependants start; ordinary SELECT readers remain available.

What you get

  • An ordered plan and actionable preflight problems in outputs.plan.row.
  • Per-view completion results and bounded lock/statement waits.
  • No index creation, initial population, blocking-refresh fallback or base-table writes.

Who it's for

  • Analytics engineers maintaining layered PostgreSQL reporting views.

Why orchestrate this with Kestra

Kestra records each refresh separately and stops dependent work after a failure. One queued execution prevents this flow from overlapping itself. A failed later refresh does not roll back earlier views: fix the cause and rerun the full flow. Separate refreshes use separate database snapshots; this is not a globally atomic refresh.

Prerequisites

  • PostgreSQL 17+ and the PostgreSQL JDBC plugin; no Docker task runner is needed.
  • Every requested materialized view must already be populated and have a valid, immediate UNIQUE index covering all rows using plain columns.
  • MAINTAIN privilege and access needed by each view's query. Keep definitions, indexes and privileges unchanged during the run; coordinate other refresh jobs.
  • An explicit list of 1-25 views, including all upstream materialized views.

Secrets

  • POSTGRES_JDBC_URL: JDBC URL of the reporting database.
  • POSTGRES_USERNAME: Database role used for planning and refreshes.
  • POSTGRES_PASSWORD: Password for that role.

Quick start

  1. Configure the secrets and replace the example views defaults with your schema/name pairs.
  2. Execute with dry_run: true; inspect the plan and resolve any reported problems.
  3. Execute with dry_run: false, check downstream results, then enable the hourly trigger.

How to extend

  • Add domain-specific data checks after refreshes or alert on failed executions.

Links

Orchestrate with Kestra
Orchestrate Postgres with Kestra
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.