Turn every Pub/Sub message into a pipeline.

Pub/Sub moves the messages. Kestra runs the work each one should trigger: start an execution per message, validate and load it, fan it out to a database or API, or publish events from a finished pipeline, all with retries and one execution history.

Blueprints for Pub/Sub orchestration.

Pub/Sub delivers a message and acks it, but it runs no multi-step pipeline, keeps no execution history, and coordinates no sinks. Kestra supplies all of it: a realtime trigger starts one governed run per message, micro-batches events into BigQuery, fans messages out to Postgres or an API, and publishes completion events back to a topic. If your events live in Kafka instead, the same patterns apply there.

Micro-batch Pub/Sub messages into BigQueryOpen blueprint
One execution per message, upserted to PostgresOpen blueprint
Emit a Pub/Sub event when a pipeline finishesOpen blueprint
Browse all 19 Pub/Sub blueprints

A pipeline layer on top of Pub/Sub.

Pub/Sub runs the topics, the delivery, and the acks. Kestra runs the steps around the message: what each one triggers, how it is validated and loaded, where it fans out, and how it is replayed.

One execution per message

Pub/Sub delivers a message; it does not run a transform, a load, and a notification per message. io.kestra.plugin.gcp.pubsub.RealtimeTrigger starts one execution for each message, with the payload at {{ trigger.data }}, so a message becomes a governed run that fans out to a database, an API, or a warehouse, with step retries.

Streaming loads into BigQuery

Per-row streaming into the warehouse hits DML and quota limits fast. The Pub/Sub Trigger micro-batches messages on a short interval, and Kestra converts them with serdes.json.IonToJson and appends them to BigQuery in one load job, staying under quotas while keeping latency low.

Publish events from a pipeline

Other systems need to know when work finishes. io.kestra.plugin.gcp.pubsub.Publish emits a structured completion event (run id, status, row count) plus attributes to a topic, so a finished Kestra flow becomes a fan-out signal that downstream consumers and other flows react to.

Fan out to databases and APIs

A message often needs to land in more than one place. Kestra validates each message with an If, then upserts it into Postgres, writes it to Firestore, or calls a downstream API with core.http.Request, isolating failures per sink so one bad target never blocks the others.

Retries and replay with history

Pub/Sub redelivers on nack and dead-letters after N attempts, but gives no per-message execution record. Kestra logs one execution per message, retries individual steps with backoff, and lets you replay from a point, so a transient sink outage is recoverable with full visibility instead of a lost message.

Bridge Pub/Sub with the rest of the stack

Pub/Sub does not own the dbt model, the warehouse load, or the Kafka topic next to it. Kestra chains consume, transform, load, and notify in one flow, so a Pub/Sub event drives a real cross-tool pipeline rather than ending at the subscriber boundary.

How teams use Pub/Sub and Kestra

Patterns data platform teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.

Streaming ETL

Stream Pub/Sub events into BigQuery

Events flow in continuously and need to land in the warehouse. The Pub/Sub Trigger micro-batches messages on a short interval, Kestra converts them to newline-delimited JSON, and appends them to a raw BigQuery table, staying under per-row DML limits while keeping data fresh.

Micro-batch, not per row

One load job per batch stays under BigQuery's per-row DML quotas.

Land raw, parse later

Autodetect captures the envelope; model the data field downstream.

Tune latency vs batch

Lower the interval for freshness or raise maxRecords for bigger batches.

Trigger icon
pubsub trigger
micro-batch
IonToJson icon
to json
serialize
Load icon
bigquery load
append batch
SlackIncomingWebhook icon
slack
on load
Per-message

Process each message into Postgres in real time

Each message needs validation and a durable write. The RealtimeTrigger starts one execution per message, an If validates the payload, and a Postgres Query upserts it with safe named parameters. Microsoft Teams is alerted if a message fails to land.

Governed run per message

Each message gets its own execution history with step-level retries.

Safe parameter binding

Named parameters bind values rather than concatenating into SQL.

Validate before writing

An If skips or routes messages that fail the check.

RealtimeTrigger icon
realtime trigger
per message
If icon
validate
branch
Query icon
postgres upsert
named params
TeamsIncomingWebhook icon
teams
on failure
Publish

Publish a completion event after a pipeline

Downstream systems should react when a pipeline finishes. Kestra runs a BigQuery aggregation, then Publish emits a structured event (run id, status, row count) to a topic, so consumers and other flows pick it up. Email confirms the publish.

Finished pipeline, fan-out signal

A completion event lets many consumers react to one run.

Attributes for filtering

Source and flow attributes ride alongside the JSON payload.

JSON messages

serdeType: JSON publishes the payload consumers parse directly.

Schedule icon
schedule
daily
Query icon
bigquery query
aggregate
Publish icon
pubsub publish
emit event
MailSend icon
email
on publish
NoSQL sink

Push events into Firestore in real time

Operational events need a low-latency document store. The RealtimeTrigger starts one run per message and firestore.Set writes the parsed document keyed by an id from the payload, so application state stays current the moment an event arrives. Discord confirms.

Document per event

Each message becomes a Firestore document keyed from the payload.

Millisecond freshness

State updates the instant the message arrives, not on a cron tick.

Parse with jq

Pull fields out of trigger.data to build the document.

RealtimeTrigger icon
realtime trigger
per message
Set icon
firestore set
write document
DiscordIncomingWebhook icon
discord
on write
Bridge

Bridge a Pub/Sub event to a downstream API

An event in Pub/Sub needs to reach a system that does not subscribe to it. The RealtimeTrigger starts a run per message, an If filters on the payload, and core.http.Request calls the target API, so two systems that do not natively connect are bridged through one governed flow.

Connect the unconnected

Bridge Pub/Sub to any HTTP API without a custom subscriber service.

Filter before calling

An If only calls the API for messages that matter.

Retries on the call

A transient API error retries the request, not the whole pipeline.

RealtimeTrigger icon
realtime trigger
per message
If icon
filter
branch
Request icon
http request
call API
SlackIncomingWebhook icon
slack
on call

Kestra vs the orchestration alternatives Pub/Sub teams evaluate

Capability
Cloud Workflows
Cloud Composer
Temporal
Start a pipeline per message
Native RealtimeTrigger
Eventarc + step graphCustom sensor, PythonWorker code
Micro-batch events into BigQuery
Trigger + Load tasks
Connector callsOperator, PythonActivity code
Publish events from a pipeline
Publish task
Connector callOperator, PythonActivity code
Retries and replay with history
Per-task, built in
LimitedYes, Python configYes, in code
Coordinate with databases and APIs
Native plugins
HTTP and connectorsOperators, PythonActivity per sink
Declarative YAML, no code
Pure YAML
GCP-only YAMLPython DAGsGo, Java, or TS code
Self-hosted or air-gapped option
Open source, self-hosted
GCP-managedGCP-managedOSS or cloud

Pub/Sub & Kestra: common questions

Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.

See How

Ready to orchestrate your Pub/Sub events?

Start a flow per message, micro-batch into BigQuery, fan out to databases and APIs, and publish completion events in one flow. Open source, self-hosted, event-driven.