Pub/Sub cost explained: what $40 per TiB actually buys you
Pub/Sub prices throughput at a flat rate per TiB with no shards to provision, which is either a bargain or a trap depending on your fan out factor and retention settings. Here is the full meter list.
Quick answer
Pub/Sub charges roughly $40 per TiB of throughput, counting both publish and each subscription delivery, with the first 10 GiB per month free. The critical detail is that every subscription is billed separately: publishing 1 TiB to a topic with four subscriptions costs 5 TiB of metered throughput, about $200, not $40. Message retention beyond the default costs about $0.27 per GiB per month, and snapshots the same. There are no shards or clusters to size, so cost scales purely with bytes times fan out. The optimization levers are batching, fan out reduction, and retention discipline.
Pub/Sub has the simplest pricing model of the major streaming services: no shards, no brokers, no cluster hours, no partition count to get wrong. You pay for bytes. That simplicity is genuinely valuable, but it hides one multiplier that catches nearly everyone the first time, and a couple of smaller meters that show up later.
The meters
| Meter | Approximate price | Notes |
|---|---|---|
| Throughput | $40 per TiB | First 10 GiB per month free, counts publish and each delivery |
| Retained message storage | ~$0.27 per GiB-month | Beyond the default acknowledged retention |
| Snapshot storage | ~$0.27 per GiB-month | For replay points |
| Egress to another region | Standard network egress rates | Cross region subscribers pay transfer too |
There are no cluster hours and no idle charge, which is the structural advantage: a topic that carries nothing for three weeks costs nothing for three weeks. That makes Pub/Sub unusually well suited to low volume event buses, per tenant topics, and anything whose traffic is unpredictable enough that provisioning for peak would be wasteful.
Message sizes are metered with a minimum of 1,000 bytes per message for billing purposes. That single rule reshapes the economics of high frequency small messages: publishing 100 byte IoT readings costs the same as publishing 1,000 byte ones. If you send 500 million 120 byte messages a month, you are billed as though you sent 500 GB, not 60 GB, an 8x markup. Batching 10 readings into one message cuts that bill by roughly 80 percent with no loss of information.
The fan out multiplier
This is the number that surprises people. Throughput is metered on publish and on every delivery to every subscription. A topic carrying 2 TiB a month with a single subscription meters 4 TiB total, about $160. Add three more subscriptions for a data warehouse sink, a monitoring pipeline, and an archival job, and you meter 2 publish plus 8 delivery, 10 TiB, about $400. Nothing about the data changed.
| Published volume | Subscriptions | Metered TiB | Monthly cost |
|---|---|---|---|
| 2 TiB | 1 | 4 | ~$160 |
| 2 TiB | 3 | 8 | ~$320 |
| 2 TiB | 6 | 14 | ~$560 |
| 10 TiB | 4 | 50 | ~$2,000 |
The fix is architectural. If four consumers each need the same full stream, consider one subscriber writing to a shared store that the others read, rather than four independent subscriptions. If consumers need only a subset, publish to filtered topics or use subscription filters so undelivered messages are not metered as deliveries. Filtered out messages are not charged as delivery throughput, which makes filters a direct cost lever rather than just a convenience.
Retention is small until it is not
Unacknowledged messages are retained at no additional storage charge up to the default window. Enabling retention of acknowledged messages for replay, up to 31 days, starts the storage meter at about $0.27 per GiB per month. A topic carrying 2 TiB a month with 7 days of acknowledged retention holds roughly 470 GiB at steady state, about $127 a month. With 31 days it holds about 2 TiB, roughly $553 a month. Replay is genuinely useful for recovering from a bad consumer deploy, but 31 days of it on a high volume topic is a real line item that should be a deliberate choice rather than a default nobody revisited.
How it compares on shape
The useful contrast is between models, not just numbers. Shard or partition based services charge for provisioned capacity whether or not you use it, which rewards steady predictable load and punishes spiky or low volume streams. Pub/Sub charges only for bytes moved, which rewards spiky and low volume streams and becomes relatively expensive at very high sustained throughput with heavy fan out. A stream doing 50 MB per second sustained is 126 TiB a month, about $5,040 with one subscription and $7,560 with two, at which point self managing brokers on committed compute starts to look attractive, with the operational cost that implies. See managed versus self hosted broker economics for that crossover.
Practical controls
Batch small messages to beat the 1,000 byte minimum. Audit subscriptions quarterly and delete the ones nobody reads, since each one is a full copy of the throughput bill. Use subscription filters so consumers meter only what they need. Keep acknowledged retention at the shortest window your recovery story actually requires. Keep publishers and subscribers in the same region to avoid stacking network egress on top of throughput charges. The topics, subscriptions, service accounts, and networking are Terraform managed, and C3X prices them from theresource catalog before the pipeline goes live.
FAQ
How much does Pub/Sub cost?
Roughly $40 per TiB of throughput, with the first 10 GiB per month free. Throughput is metered on publish and again on every delivery to every subscription, so fan out multiplies the bill. Retained acknowledged message storage and snapshots each cost around $0.27 per GiB per month, and cross region delivery adds standard network egress charges.
Does each Pub/Sub subscription cost extra?
Yes. Every subscription meters its own delivery throughput. Publishing 2 TiB to a topic with four subscriptions meters 2 TiB publish plus 8 TiB delivery, 10 TiB total, about $400 a month rather than $80. Auditing and removing unused subscriptions is one of the most direct cost reductions available.
Why do small Pub/Sub messages cost so much?
Billing applies a minimum of 1,000 bytes per message. Sending 500 million 120 byte messages is billed as 500 GB rather than 60 GB, roughly an 8x markup. Batching multiple small records into a single larger message before publishing typically cuts this portion of the bill by 70 to 85 percent with no data loss.
Do subscription filters reduce cost?
Yes. Messages filtered out are not delivered and therefore are not charged as delivery throughput. That makes filters a genuine cost lever, not just a convenience. Where a consumer needs 10 percent of a stream, a filter cuts that subscription's delivery charges by roughly 90 percent compared with delivering everything and discarding client side.
How much does Pub/Sub message retention cost?
About $0.27 per GiB per month for acknowledged message retention and snapshots. A topic carrying 2 TiB a month holds around 470 GiB at 7 days of retention, roughly $127 a month, or about 2 TiB at the 31 day maximum, roughly $553 a month. Set retention to the shortest window your recovery plan genuinely needs.
When does Pub/Sub become more expensive than running brokers?
At high sustained throughput with heavy fan out. A stream at 50 MB per second sustained is about 126 TiB a month, roughly $5,040 with one subscription and $7,560 with two. Beyond that range, brokers on committed compute can be cheaper on infrastructure, though the operational burden and engineering time often offset the difference.
What to do next
Price your streaming infrastructure before it runs. C3X reads Terraform and costs your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.