Pub/Sub cost is driven by three meters, and most overspend comes from misreading the first one. Throughput, the volume of message data published and delivered, is the largest line, and it carries a minimum billable message size, which means many small messages are billed as if each were that minimum rather than its true bytes. Message storage adds up when subscriptions retain unacknowledged or replayable messages longer than anyone consumes them. Network egress applies whenever messages cross regions or leave Google's network. The levers follow directly: batch small events into fewer larger messages to escape the minimum size penalty, set retention and replay windows to what consumers actually need, and keep publishers and subscribers in the same region. None of these weaken delivery guarantees; they stop you paying for per message overhead, idle retention, and avoidable cross region hops.
Here is how Pub/Sub is priced, why the bill runs ahead of expectations, and how to cut it without losing reliability.
How is GCP Pub/Sub billed?
Pub/Sub charges on data volume rather than on a per message flat fee, but with an important wrinkle. Throughput is measured in gigabytes of message data published and delivered, and each message has a minimum billable size applied regardless of how small the payload actually is. So a topic carrying millions of tiny events is billed against that minimum on every one, and the effective cost per real byte can be many times the headline rate. On top of throughput, message storage is charged when a subscription holds messages that have not been acknowledged, or when you enable message retention so consumers can replay a window of past messages, because Pub/Sub is storing that data until it expires. Network egress is the third meter, applying when a message is delivered across regions or out to a subscriber outside Google's network. Understanding which meter dominates your bill is the first step, because the fix for a throughput problem, a storage problem, and an egress problem are different levers entirely.
Why does the Pub/Sub bill run ahead of expectations?
The most common surprise is the minimum billable message size meeting a fine grained event design. Teams often publish one message per small event, a single metric, a single state change, a single click, and each is billed at the minimum size even though the payload is a fraction of it. Multiply that across high volume telemetry and the throughput cost is dominated by per message overhead rather than data. The second surprise is retention. Enabling message retention or generous replay windows so consumers can recover from failures is sensible, but a long window means Pub/Sub stores every message for that period whether or not anyone replays it, and the storage charge accrues silently. The third is geography: a topic published in one region with subscribers in another pays egress on every delivery, and a multi region consumer pattern can quietly double the effective cost of a stream. Each of these is invisible on a casual read of the bill and obvious once you slice throughput, storage, and egress apart.
A European SaaS company streamed device telemetry through Pub/Sub as one message per reading, with a long replay retention window set during an earlier reliability incident and never revisited, and subscribers split across two regions. We batched readings into fewer larger messages at the publisher, which collapsed the per message minimum size penalty and cut throughput sharply, trimmed the retention window to the few hours consumers actually used for recovery, and co located the heavy subscriber with its topic to remove cross region egress. Pub/Sub cost on that pipeline fell by more than half with no change to delivery guarantees or consumer logic, and the recovery window was still longer than any real replay the team had ever needed. The figures are verified against billing data and anonymised.
Which levers cut Pub/Sub cost?
Start with batching where messages are small, since it attacks the largest line for most event streams. Combining many tiny events into fewer larger messages at the publisher reduces the count of billable minimum size units and cuts throughput cost, at the price of a small, usually acceptable, latency increase that suits telemetry and event streams. Next, set retention and replay windows to what consumers genuinely need rather than the longest window someone once configured during an incident, because every extra hour of retention is storage you pay for on data nobody reads. Audit subscriptions for ones that are abandoned or duplicated: each active subscription on a topic receives and is billed for the full message stream, so a forgotten subscription is a full copy of the throughput cost. Keep publishers and their heavy subscribers in the same region to avoid egress, and reserve cross region delivery for cases that truly require it. Finally, push acknowledgement discipline so messages are acknowledged promptly and do not linger as billable unacknowledged storage. Together these levers reshape a Pub/Sub bill from an opaque throughput number into a controlled cost that tracks the events you actually move.
Frequently asked questions
How is GCP Pub/Sub billed?
Why is my Pub/Sub bill higher than expected?
Does batching reduce Pub/Sub cost?
Bring your Pub/Sub cost under control
We slice Pub/Sub throughput, storage, and egress apart, then apply batching, retention, subscription, and region levers so the bill tracks the events you move rather than per message overhead. We take zero provider commissions and answer only to you, and our guarantee is plain: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.