Pub/Sub pricing is based on:
- Message ingestion and delivery
- Seek-related message storage: snapshots and retained acknowledged messages
Message ingestion and delivery
Message delivery pricing
Message ingestion and delivery are priced per volume of data transmitted in a calendar month. The first 10 gigabytes of usage are free. After that, the price for ingestion or delivery of messages is $40 per TiB.
The data volume of a message is the sum of the following:
- The number of bytes in the encoded message body string
- For each attribute, the size of the key and its value
- 20 bytes for the timestamp
- The size of the
- Additional optional fields, such as those associated with early access and other restricted access APIs.
A minimum of 1000 bytes per publish, push or pull request is assessed regardless of message size. This means that for messages smaller than 1000 bytes, it is cheaper to batch multiple messages per request.
Ingestion and delivery charges apply only to publish requests and data delivered using pull, streamingPull or push operations. Other operations are free.
If you pay in a currency other than USD, the prices listed in your currency on Google Cloud SKUS apply. The rate listed is per TiB (240 bytes, or approximately 1.1 trillion bytes).
Pub/Sub automatically acknowledges the messages that don't match a filter, but you still incur message delivery fees for these messages.
The 1,000-byte minimum doesn't apply to the messages that the Pub/Sub service automatically acknowledges. Message delivery fees are based on the number of bytes in these messages, regardless of how small the messages are.
Data region egress fees
The fees for internet egress and message delivery between Google Cloud regions are consistent with the Compute Engine network rates, with the following exceptions:
- There are no zone egress fees for Pub/Sub usage.
- Egress to Google products is not exempt from egress fees.
For example, a 1 MiB message published in
us-west1 and delivered to
a subscriber in
europe-west1 results in charges for two distinct SKUs:
- 2 MiB of Message Delivery Basic (1 MiB of publish and the delivery)
- 1 MiB of Inter-Region Data Delivery from the Americas to EMEA
To understand your usage, you can export your billing data to BigQuery. Once you set this up, you can use a query like this to understand your usage:
SELECT TIMESTAMP_TRUNC(usage_start_time, day) as usage_date, sku.description, usage.unit, sum(usage.amount) as egress_volume FROM `BILLING_EXPORT_TABLE` WHERE _PARTITIONTIME >= TIMESTAMP("2019-01-01") AND service.description = "Cloud Pub/Sub" AND (sku.description like "Internet data%" OR sku.description like "Inter-region data%") GROUP BY usage_date, sku.description, usage.unit;
Pub/Sub automatically acknowledges the messages that don't match a filter. You don't incur egress fees for the messages that Pub/Sub automatically acknowledges.
Example: message ingestion and delivery
To illustrate the overall costs of operation you might expect, consider an
application that publishes 1024-KB messages to a topic with two subscriptions,
at a rate of 1 MiB/second. Assuming that the subscribers are keeping up,
Pub/Sub ingests 1 MiB/second and delivers 2 MiB/second, for a total
data transmission rate of 3 MiB/second. Over the course of a 30 day month, this
3 MiB/second x 3600 seconds/hour x 24 hours/day x 30
days/month x 1 month/(2^20 MiB/TiB) = 7.416 TiB. After subtracting the first
10 GB (which is free), the data volume is 7.406 TiB x $40 per TiB and the charge
If you use Pub/Sub across projects, Pub/Sub fees are billed to the project that contains the requested resource:
- The project that is billed for publishing is the project that contains the topic.
- The project that is billed for subscribing is the project that contains the subscription.
For example, if the subscription lives in project A, then project A is billed for data that is pulled from the subscription, even if the subscription is attached to a topic in project B.
If an authorized service account in project A consumes messages from a subscription in project B, then project B is billed for the data that is pulled from the subscription.
Seek-related message storage
Message storage fees, at a rate of $0.27 per GiB-month, are charged in these cases:
- A subscription is configured to retain acknowledged messages to make it possible to re-process them using seek. In this case, storage fees are charged for retained acknowledged messages.
- A snapshot of a subscription is created. In this case, message storage fees are charged for storing the snapshot's unacknowledged messages. In addition, if the subscription has a backlog of unacknowledged messages when the snapshot is created, a one-time fee equivalent to storing that backlog for seven days is charged.
Snapshots can be a more economical way to retain messages for replay than retaining all acknowledged messages because a single snapshot can be used across multiple subscriptions. Snapshots generally have a small billable data volume that increases gradually through the age of the snapshots. Subscriptions configured to retain acknowledged messages maintain a fixed time window of message data (at steady state), but may be more convenient.
Example: subscription with retained acknowledged messages
Consider a topic with a single subscription and the following:
- The topic has a steady 1MiB/second rate of incoming data.
- The subscriber is keeping up with the data on the subscription, consuming it at 1 MiB/second and has negligible new message backlog.
- The subscription is configured to retain acknowledged messages for 7 days.
In this setup, the acknowledged message volume grows by
1 MiB/second x 3600 seconds/hour x 24 hours/day = 86.4 GiB/day.
After 7 days, retained acknowledged messages start expiring and the total
volume of stored acknowledged messages settles at
7 days x 86.4 GiB/day =
605 GiB. The total monthly fee for storing this volume of messages is
605 GiB-month x $0.27/GiB-month = $163.
Example: snapshot message storage fees
Snapshot message storage fees consist of an incremental charge for new messages
published to the snapshot's topic and a one-time fee at the time of creation.
Consider a snapshot of the subscription with retained acknowledged messages. The
snapshot has a lifetime of seven days unless it is deleted earlier, since the
subscription from which it is created has no backlog of unacknowledged messages.
The data published in the first minute (60 MiB) is stored for 7 days - 1 minute,
the data published in the second minute for 7 days - 2 minutes, and so forth.
This scenario results in a backlog size of 605 GiB when the snapshot expires,
1/2 x 605 GiB x 7 days = 2118 GiB-days of storage used, for which
the charge is
2118 GiB-days x (1/30 months/day) x $0.27/GiB-month = $19 in a
30-day month. Thus, snapshots are a potentially cost-effective alternative to
acknowledged message retention.
Example: snapshot of a subscription with a backlog
If the subscription has a backlog of unacknowledged messages when the snapshot
is created, a one-time fee equivalent to storing that backlog for the full seven
days is charged. For example, consider a subscription with a 10 GiB
unacknowledged message backlog. The one-time fee at the time of snapshot
creation would be
10 GiB x 7 days / 30 days/month x 0.27/GiB-month = $0.63.
Resource location restriction implications
A message storage policy can result in additional region egress (network) fees if the policy forces the data to exit a Google Cloud region. Consider a message that is:
- Published in region A
- Routed to region B for storage
- Delivered to a subscriber client in region C
In this case:
- The project that contains the topic is billed for network egress from region A to region B.
- The project that contains the subscription is billed for egress from region B to region C.
The project that contains the topic will be charged an egress fee only if the published message is stored in a region different from the region where the message was published (that is, B is actually a different region from A). The project that contains the subscription will be charged an egress fee only if the published message is stored in a region different from where the subscriber client is (C is not the same as B).