Pub/Sub pricing is throughput per TiB: every byte published to a topic and every byte delivered to a subscription counts, at one rate in every region after the first 10 GiB a month, with higher rates for subscriptions that write straight into BigQuery or Cloud Storage and for import topics that read from other systems; retained messages and snapshots pay storage per GiB-month, and egress leaves the region at network rates. Pub/Sub Lite sells reserved capacity instead, per zone and capacity unit. Eventarc delivers events through Pub/Sub and charges per million published events in its advanced form, Cloud Tasks per million operations and Cloud Scheduler per job and month. On the bill, Pub/Sub is proportional to the bytes an application sends and the number of subscriptions that read them, because a message with three subscriptions pays its bytes four times, and the storage line appears when acknowledged messages are retained or a subscription falls behind.

Pricing dimensions

Google prices messaging by the bytes that flow, not by the messages or the topics; every rate has its own SKU, and the throughput rates do not vary by region.

DimensionUnitWhat drives itOptional
Message deliveryTiB of throughput, published bytes and delivered bytes alike, at the basic rate in every region; the first 10 GiB a month per billing account free; a minimum of 1,000 bytes per publish or pull requestEvery message published and every subscription that receives it, pull, push or streaming pullNo
BigQuery and Cloud Storage subscriptionsTiB of subscribe throughput at a higher rate, with no further ingestion charge on the sinkSubscriptions that write to BigQuery or a bucket without a pipelineYes
Import topicsTiB of publish throughput at a higher rate from Kinesis, Cloud Storage, Event Hubs, MSK or ConfluentTopics that ingest from other systemsYes
StorageGiB-month of retained acknowledged messages, of snapshots and of unacknowledged messages beyond the free windowTopic and subscription retention settings, slow or stopped subscribersYes
Single message transformsTiB of data processed by a transform on a topic or subscription; AI inference transforms by the enriched messageTransforms configuredYes
EgressGiB at network rates when a subscriber reads from another region or the internet; within the region freeCross-region consumersYes
Pub/Sub LiteCapacity units per zone and hour for publish and subscribe throughput, plus storage per GiB-month reservedReserved-capacity messagingYes
EventarcStandard events free per million published; advanced events per million published once out of preview; the Pub/Sub delivery behind them at Pub/Sub ratesEvent routing to Cloud Run, GKE and WorkflowsYes
Cloud Tasks and Cloud SchedulerTasks per million operations after a free million a month; Scheduler per job per 31 days after three free jobs per billing accountQueues and cron jobsYes
Purchase optionNone; no commitment on messaging

Throughput counts twice at least: a message published once and delivered to one subscription pays its bytes on publish and on delivery, and every further subscription on the topic adds another delivery, so fan-out multiplies the bill by the number of readers. The minimum of 1,000 bytes per request makes small messages dearer than their size: a 100-byte message pays 1,000 bytes on every publish and pull, and batching publishes and pulls brings the count back to the real bytes. Storage is the line for what waits: a subscription that falls behind keeps unacknowledged messages free for seven days, retained acknowledged messages and snapshots pay per GiB-month, and a topic with message retention pays every byte for the retention window whether anyone reads it again or not. The BigQuery and Cloud Storage subscriptions cost a quarter more per TiB than plain delivery but replace a Dataflow job that would cost more than the difference. Eventarc is Pub/Sub with routing: the standard events cost nothing to publish and pay Pub/Sub for the delivery, which makes an event-driven architecture cheap until the events are large or many. The mechanics across all three providers are in messaging and streaming services; what the AWS counterparts cost, in messaging and streaming pricing.

How it appears in your billing data

In the billing export the rows carry service.description Cloud Pub/Sub and a sku.description per kind of throughput: Message Delivery Basic for publish and delivery in TiB, BigQuery Subscriptions Message Delivery and Cloud Storage Subscriptions Message Delivery for the sink subscriptions, Import Topics Message Delivery for imports, Topic Message Storage and Subscription Message Storage per GiB-month, Snapshot Storage, Intra-region Data Delivery and Inter-region Data Delivery for egress by boundary; usage.unit is byte for throughput and gibibyte-month for storage. resource.name in the export with resource-level detail names the topic or subscription, and their labels in labels are the attribution per team; without resource-level detail a project's topics sum into one row per SKU and day, and the per-topic volume sits in the Pub/Sub metrics topic/byte_cost and subscription/byte_cost, which count exactly the billable bytes. Eventarc rows carry service.description Eventarc for advanced events and nothing for standard ones, Cloud Tasks Cloud Tasks with Operations per million, Cloud Scheduler Cloud Scheduler with Jobs per month.

The free 10 GiB appear as credits.type FREE_TIER beside the delivery row; there is no sustained use or committed use discount on Pub/Sub. The export's structure is described in the Google Cloud billing export; in the FOCUS export, ServiceName carries Cloud Pub/Sub, ServiceCategory Integration, SkuId the SKU and ChargeCategory Usage (FOCUS columns).

A published messageMessage delivery: the publishand every subscription'sdelivery per TiB, each requestat least a thousand bytesTopic and subscriptionstorage per GiB-month whileretained or acknowledgedand keptSink subscriptions to BigQueryor Cloud Storage: a surchargeper TiB of their ownInter-region delivery perGiB for a subscriberelsewhereThe free allowance as a credit;no commitment on Pub/Sub
A message pays its publish and every subscription's delivery by the byte, storage while retained, and extra for a subscriber in another region

Levers

Configuration: the first lever is the number of subscriptions per topic, because every subscription pays the delivery again, and a filter on a subscription drops messages before they are delivered and billed; the second is message size and batching, because the 1,000-byte minimum per request punishes small messages sent one by one and batching publishes and pulls counts the real bytes; the third is retention, because retained acknowledged messages and long topic retention pay storage every month for data that a sink already holds. Dead-letter topics and retries are subscriptions too, and a failing subscriber that retries forever pays its deliveries forever.

A topicThe number of subscriptions:each pays the delivery againA filter on the subscription:messages dropped before theyare delivered and billedMessage size and batching: thethousand-byte minimum per requestpunishes small messages sentone by oneRetention: retained acknowledgedmessages and long topic retentionpay storage every month
Every subscription pays the delivery again, a filter drops before billing, batching defeats the per-request minimum, and retention pays storage every month

Purchase option: none; Pub/Sub Lite is the reserved-capacity form for steady, high-volume streams where the capacity is sized to the measured throughput, and it is cheaper only when the capacity is used.

Architecture: BigQuery and Cloud Storage subscriptions instead of a Dataflow job for plain loads, because the surcharge per TiB is less than the workers; Eventarc for event routing, because the standard events cost nothing to publish; a Cloud Run worker pool or a pull subscriber in the region of the topic, because egress pays per GiB across regions (network pricing); and Pub/Sub for events, not for files, because a 10 MB message pays 10 MB on every hop where a reference to an object pays 1,000 bytes. What the consumers cost is in Cloud Run and Cloud Run functions pricing and Dataflow, Dataproc and Composer pricing.

Where it goes wrong

  • Five subscriptions on the firehose. A topic with five subscriptions pays six times its bytes. The metric subscription/byte_cost per subscription shows which readers exist; filters and fewer readers lower it.
  • Tiny messages, one per request. A stream of 100-byte events published one at a time pays 1,000 bytes each. Batching publishes brings the bill down tenfold.
  • The subscriber stopped and nobody noticed. Unacknowledged messages are free for seven days, then expire; a retained subscription or a snapshot pays storage from day one. The oldest unacknowledged message age is the alert.
  • Retention on both sides. Topic retention and subscription retention of acknowledged messages pay the same bytes twice per GiB-month. One retention, where the replay actually happens.
  • The retry loop. A push subscription to an endpoint that fails retries with backoff for the message's lifetime, paying every delivery. A dead-letter topic ends the loop after a few attempts.
  • Files through the topic. Messages near the 10 MB limit pay their size on every publish and delivery. A pointer to a Cloud Storage object costs 1,000 bytes a hop.
  • The consumer is in another region. A subscriber in Belgium reading a topic in Frankfurt pays inter-region egress on every byte. Consumers where the topic is.

Example

List prices in USD, read on 2026-10-21 from the Pub/Sub, Eventarc, Cloud Tasks and Cloud Scheduler pricing pages, the same in every region including Frankfurt (europe-west3): message delivery costs USD 40 per TiB after the first 10 GiB a month, BigQuery and Cloud Storage subscriptions USD 50 per TiB of subscribe throughput, import topics USD 50 per TiB from Kinesis and USD 80 per TiB from Cloud Storage, Event Hubs, MSK or Confluent, storage USD 0.27 per GiB-month; Eventarc standard events USD 0 per million published and advanced events USD 1 per million once out of preview; Cloud Tasks USD 0.40 per million operations after the first million a month; Cloud Scheduler USD 0.10 per job per 31 days after three free jobs per billing account.

An application that publishes 2 TiB a month to a topic with one pull subscription pays 4 TiB of throughput, 4 × 40 less the free 10 GiB, about USD 159.61; with three subscriptions 8 TiB, USD 319.61; the same 2 TiB as 100-byte messages published one at a time count as 1,000 bytes each and pay ten times the published volume, about USD 1,200 for the publish side alone. A BigQuery subscription on the 2 TiB topic costs USD 100 of subscribe throughput in place of a Dataflow job's workers. Retaining the month's 2 TiB of acknowledged messages for replay costs 2,048 × 0.27 = USD 552.96 a month, more than the delivery itself. An event-driven system that routes 50 million standard Eventarc events of 2 KB a month to Cloud Run pays nothing for the events and about USD 7.45 for the 186 GiB of Pub/Sub delivery behind them; 100 Cloud Scheduler jobs cost USD 9.70 a month. The figures show that fan-out and small messages multiply the throughput bill, that retention costs more than delivery, and that event routing itself is nearly free.

Sources

Read on 2026-10-21. Prices: Pub/Sub pricing, Eventarc pricing, Cloud Tasks pricing, Cloud Scheduler pricing. Service: Pub/Sub quotas and limits, message retention and replay, monitoring Pub/Sub. Billing data: structure of the standard Cloud Billing data export.