Cloud Parts

Google Cloud Pub/Sub

Google Cloud’s serverless messaging service: fan-out across subscriptions, work sharing within each one.

What it is
Pub/sub
Used for
Message queues,Event streams
Type
Managed service on Google Cloud
Made by
Google Cloud
License
Proprietary
Facts checked
5 October 2026
Website

What it is

A publisher sends messages to a topic. Every subscription attached to the topic gets each message, and inside one subscription the messages are spread across however many clients are pulling, each acknowledged on its own. So the same product covers fan-out (one subscription per consumer) and work queues (many workers on one subscription). An unacknowledged message is sent again after the ack deadline (10 seconds by default, up to 600) and kept for 7 days by default, 31 at most. Messages can be up to 10 MB.

Subscriptions come in several types: pull, push to an HTTPS endpoint, and export subscriptions that write straight into BigQuery, Cloud Storage or (in preview) Bigtable. Optional features include ordering keys (messages with the same key arrive in order, up to 1 MBps per key), exactly-once delivery for pull subscribers in the same region, dead-letter topics, attribute filters, and seeking a subscription back to a timestamp or snapshot to replay messages. There are no partitions or shards to plan.

Why teams pick it

  • No partitions, shards or brokers: throughput scales without capacity planning
  • Fan-out and competing consumers in one model
  • Export subscriptions load BigQuery tables or Cloud Storage files with no code
  • Replay by seeking to a timestamp or snapshot, within the retention window

Watch out for

  • Ordering is opt-in, per ordering key, and capped at 1 MBps per key
  • Exactly-once delivery works only for pull subscriptions in the same region; push and export subscriptions are at least once
  • Filters match attributes only, not the message body, and can’t be changed after the subscription is created
  • Retention tops out at 31 days, so it isn’t a long-term event log

Alternatives

What all pub/sub have in common →
Amazon SNSAWSAWS’s managed pub/sub topics, which push each message to queues, functions, webhooks, phones and inboxes.

How it fits with other technologies

One topic, a worker subscription and a BigQuery export · bash

gcloud pubsub topics create orders

# workers share this subscription; each message goes to one of them
gcloud pubsub subscriptions create billing --topic=orders \
  --ack-deadline=60 --enable-exactly-once-delivery

# a second subscription gets its own copy of every message
gcloud pubsub subscriptions create orders-to-bq --topic=orders \
  --bigquery-table=acme-shop:analytics.orders_raw

gcloud pubsub topics publish orders --message='{"orderId": 42}' --attribute=status=paid
gcloud pubsub subscriptions pull billing --limit=10 --auto-ack

See it in a real stack

No architecture uses Google Cloud Pub/Sub yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2015–2026

Google’s own products, including Ads, Search and Gmail, pass messages through a shared internal publish/subscribe system that, by Google’s account, carries over 500 million messages per second, more than 1 TB/s of data. Cloud Pub/Sub is that infrastructure offered as a public service. Gregor Hohpe, co-author of Enterprise Integration Patterns, wrote that he had seen “some of the humble beginnings” while working at Google.

Google opened a public beta in March 2015 and made it generally available alongside Cloud Dataflow that August, at up to 1 million message operations per second. Hohpe singled out its central idea: separating topics from subscriptions gives both publish-subscribe and point-to-point channels “through a single API.”

Pub/Sub has since taken over jobs that used to need separate pipelines: subscriptions that write straight into BigQuery, exactly-once delivery for pull subscribers, and in 2026 transforms that send messages through Vertex AI models in flight.

Why it’s built this way

Topics and subscriptions as separate objects
Each subscription is its own queue fed by the topic, so one model covers fan-out (many subscriptions) and work sharing (many clients on one subscription).
No partitions or shards
Messages flow through many forwarder servers that Google scales automatically, so users never plan partitions. Ordering is therefore opt-in, per ordering key, rather than built into a log.
Push and pull from the start
Subscribers can pull messages or have them pushed to an HTTPS endpoint like a webhook, which suits both long-running workers and serverless code.
At-least-once by default
In 2015 it usually delivered messages exactly once and in order but didn’t promise to. Exactly-once delivery came in 2022 by moving delivery state from memory into a persistent layer, at the cost of higher latency and only within one region.

Timeline

  1. 2015

    Public beta in March; generally available in August with Cloud Dataflow

  2. 2022

    BigQuery subscriptions in July; exactly-once delivery GA in December

  3. 2024

    Import topics pull data in from Amazon Kinesis Data Streams

  4. 2025

    Single Message Transforms reach general availability

  5. 2026

    Vertex AI inference transforms; Bigtable export subscriptions in preview

Sources10 · facts checked 5 October 2026

Improve this page on GitHub