GCP Pub/Sub Push vs Pull: Differences, Throughput, and When to Use Each

Simple explanation

Push means Pub/Sub sends messages to you. You give Pub/Sub an HTTPS URL. When a message arrives on the topic, Pub/Sub makes an HTTP POST to that URL with the message in the request body. Your service processes the message and returns an HTTP success response to acknowledge it.

Pull means you ask Pub/Sub for messages. Your code opens a connection to the Pub/Sub API and requests messages when it is ready. You control how many messages to fetch, how fast to process them, and when to acknowledge each one.

Both modes deliver the same messages from the same subscription. The difference is who initiates the delivery and how much control the consumer has over the process.

How push delivery works

When you create a push subscription, you provide an HTTPS endpoint URL. Pub/Sub takes responsibility for delivering messages to that endpoint.

1. Pub/Sub initiates delivery. When a message is published to the topic, Pub/Sub sends an HTTP POST request to your endpoint with the message data in the request body.
2. The endpoint must use HTTPS. Pub/Sub does not deliver to plain HTTP endpoints. The TLS certificate must be valid and signed by a trusted certificate authority.
3. Acknowledgement is based on the HTTP response. Your endpoint returns an HTTP 2xx status code (200, 201, 202, 204, or 102) to acknowledge the message. Any other status code tells Pub/Sub the delivery failed.
4. Failed deliveries are retried with exponential backoff. If your endpoint returns a non-2xx response or does not respond within the ack deadline, Pub/Sub retries. The backoff starts short and increases with each retry, up to a configurable maximum.

Push delivery works well for webhook-style consumers. A Cloud Run service can sit idle with zero instances, and Pub/Sub wakes it by sending an HTTP request when a message arrives. The service processes the message, returns 200, and scales back down. You pay only for the time the service runs.

How pull delivery works

In pull mode, the subscriber connects to the Pub/Sub API and requests messages. The subscriber decides when to fetch, how many to fetch, and when to acknowledge.

Modern Pub/Sub client libraries use streaming pull by default. The client opens a long-lived bidirectional gRPC stream to Pub/Sub. Messages flow over this stream as they become available, without the subscriber polling repeatedly. The client library handles connection management, flow control, and lease extension automatically.

The subscriber controls concurrency by configuring how many messages the client library fetches ahead (the flow control setting). If processing slows down, the client stops pulling more messages until the backlog clears. This built-in backpressure prevents the subscriber from being overwhelmed.

Pull is the standard choice for long-running consumers. A Dataflow pipeline reading from a Pub/Sub subscription uses pull. A GKE deployment with multiple worker pods uses pull. A Compute Engine application processing a high-volume event stream uses pull. In all these cases, the consumer is already running and gains nothing from having Pub/Sub initiate delivery.

Side-by-side comparison

When to use push

Push works best when your consumer is a serverless service that should respond to events without running continuously.

Cloud Run service reacting to order events. An e-commerce platform publishes order events to a Pub/Sub topic. A Cloud Run service receives push deliveries, validates the order, and writes it to a database. Between bursts, the service scales to zero. The team pays only for request processing time.

Cloud Functions handling lightweight triggers. A Cloud Function resizes uploaded images when a notification arrives from a Cloud Storage bucket via Pub/Sub. The function runs for a few seconds per image and scales to zero between uploads.

Intermittent workloads where cost matters. A notification service sends emails when specific events occur. Traffic is bursty: a few messages per minute during quiet periods, hundreds during peak. Push to a Cloud Run service keeps costs proportional to actual usage.

Push is also useful when your consumer is behind a load balancer that distributes incoming Pub/Sub requests across multiple backend instances. The HTTP delivery model integrates naturally with standard HTTP infrastructure.

When to use pull

Pull works best when your consumer is a long-running process that needs control over how messages are consumed.

Dataflow streaming pipeline. A streaming pipeline reads events from Pub/Sub, applies windowing and aggregation, and writes results to BigQuery. Dataflow manages parallelism, checkpointing, and scaling internally. Pull gives the pipeline full control over consumption rate.

GKE worker deployment. A Kubernetes deployment runs 10 worker pods, each pulling messages from the same subscription. Pub/Sub distributes messages across the pods. Each pod controls its own concurrency and batch size. Horizontal pod autoscaling adds or removes pods based on subscription backlog metrics.

Compute Engine or VM-based processing. A data enrichment service runs on Compute Engine VMs. Each VM opens a streaming pull connection and processes messages at its own pace. The service needs to call external APIs with rate limits, so it uses flow control to avoid exceeding those limits. For help choosing between Cloud Run, GKE, and Compute Engine, see the comparison page.

Any workload needing batching or concurrency control. If your processing logic benefits from accumulating messages and processing them in batches (bulk database inserts, batch API calls), pull gives you direct control over batch size and timing.

When not to use this pattern

Push and pull cover most Pub/Sub consumption patterns, but two alternatives are worth knowing about.

Cloud Tasks is a better fit when you need per-task controls: scheduled delivery at a specific time, rate limiting to protect a downstream API, deduplication by task name, or explicit task-level retry configuration. Pub/Sub distributes events to subscribers. Cloud Tasks dispatches individual units of work to an HTTP endpoint with task-level guarantees. If your workload is “execute this specific HTTP request reliably, at this rate, at this time,” Cloud Tasks is the right tool.

Pub/Sub push vs pull vs Cloud Tasks

These three options overlap enough to cause confusion. Here is the distinction.

Pub/Sub pull is for consumers that control their own consumption. The subscriber decides when to fetch, how much to fetch, and when to ack. Best for streaming pipelines, worker pools, and high-throughput processing.

Pub/Sub push is for event-driven delivery to an HTTPS endpoint. Pub/Sub sends messages as they arrive. Best for serverless consumers that scale to zero.

Cloud Tasks is for queued HTTP task execution with per-task controls. You create a task with a target URL, and Cloud Tasks dispatches it with rate limiting, scheduled delivery, and task-level retry configuration. Best for job queues, webhook delivery with rate protection, and deferred work.

The key question: are you distributing events to subscribers, or dispatching individual tasks to a worker? Events go through Pub/Sub. Tasks go through Cloud Tasks. For a deeper comparison, see Pub/Sub vs Cloud Tasks.

Security and authentication

Push and pull use different authentication models, and each has its own security considerations.

Push authentication

When OIDC is configured, Pub/Sub generates a signed JSON Web Token (JWT) and includes it as a Bearer token in the Authorization header of each HTTP POST. Your endpoint validates this token against Google’s OIDC certificates to confirm the request is genuinely from Pub/Sub and intended for your service.

Cloud Run handles token validation automatically when you configure the push subscription’s service account with the roles/run.invoker role on the Cloud Run service. For custom endpoints, validate the token in your handler code.

# Create a push subscription with OIDC authentication
gcloud pubsub subscriptions create order-push \
  --topic=order-events \
  --push-endpoint=https://order-service-xxxx-ew.a.run.app/events/orders \
  --push-auth-service-account=pubsub-invoker@my-app-prod.iam.gserviceaccount.com \
  --project=my-app-prod

Pull authentication

In pull mode, the subscriber authenticates to the Pub/Sub API using IAM credentials, typically a service account key or workload identity. The subscriber needs the roles/pubsub.subscriber role on the subscription. There is no inbound endpoint to protect because the subscriber initiates the connection outbound.

# Pull messages from a subscription (useful for testing and debugging)
gcloud pubsub subscriptions pull order-processor \
  --limit=5 \
  --auto-ack \
  --project=my-app-prod

Performance, batching, and throughput

Pull generally achieves higher throughput than push. A pull consumer controls its own fetch rate, batch size, and parallelism. With streaming pull and multiple threads or processes, a single consumer can handle tens of thousands of messages per second.

Push delivers messages as individual HTTP requests by default. Each request carries the overhead of an HTTP connection, TLS handshake (or reuse), request parsing, and response handling. At very high message rates (tens of thousands per second), this per-request overhead becomes the bottleneck. Configuring batching on the push subscription helps but does not close the gap with an optimized pull consumer.

Neither mode is universally better. Push trades throughput ceiling for operational simplicity and scale-to-zero. Pull trades operational simplicity for throughput and control. Match the mode to your workload characteristics.

When to choose push or pull

Use this checklist to make a quick decision.

• Need scale to zero? Lean push. Pub/Sub wakes your endpoint when messages arrive.
• Need maximum throughput? Lean pull. The subscriber controls parallelism and batch size.
• Need strict control over batching and concurrency? Lean pull. The client library gives you flow control settings.
• Consumer is a Dataflow pipeline or GKE worker? Use pull. These runtimes are already running and manage their own consumption.
• Consumer is a Cloud Run service or Cloud Function with intermittent traffic? Use push. The webhook model maps directly to these runtimes.
• Consumer is a Cloud Run service with sustained high traffic? Consider pull. Set minimum instances and use the client library for better throughput.
• Want the simplest possible setup for moderate traffic? Use push to a serverless endpoint. Less code, less infrastructure to manage.