The cost of using Pub/Sub has three components:
- Throughput costs for message publishing and delivery
- Egress costs associated with throughput that crosses a Google Cloud zone or region boundary
- Storage fees for snapshots, messages retained by topics, and acknowledged messages retained by subscriptions
Pub/Sub service charges are billed based on the number of bytes sent or stored. Pub/Sub Lite service charges, by contrast, are billed based on throughput and storage capacity reserved for a given Lite topic. Lite egress charges are based on number of bytes sent, not reserved capacity.
The following table compares the monthly cost of Pub/Sub and Pub/Sub Lite systems that store messages for one day, assuming 50% average capacity utilization:
|Data published/s||Data published/mo||Data received/mo||Storage/mo||Total Pub/Sub Lite cost||Total Pub/Sub cost|
|1 MiB||2.5 TiB||2.5 TiB||84 GiB||$30||$200|
|1 MiB||2.5 TiB||5 TiB||84 GiB||$30||$300|
|10 MiB||25 TiB||25 TiB||844 GiB||$169||$2,000|
|10 MiB||25 TiB||50 TiB||844 GiB||$214||$3,000|
|100 MiB||247 TiB||247 TiB||8438 GiB||$1,688||$19,760|
|100 MiB||247 TiB||494 TiB||8438 GiB||$2,138||$29,640|
When you compare the cost of Pub/Sub and Pub/Sub Lite, consider the differences between the products. For more information, see Choosing Pub/Sub or Pub/Sub Lite.
Pub/Sub service pricing
The following pricing details apply only to Pub/Sub (not Pub/Sub Lite).
Throughput, consisting of message publishing and delivery, is 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.
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.
The fees for internet egress and message delivery between Google Cloud regions are consistent with the VPC 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.
- There is no exemption for ingress. For example if you publish messages from region A to a regional endpoint of remote region B, or if your storage policy requires Pub/Sub to forward the message to region A, you will be charged egress fees.
You are charged for egress every time a message crosses a region boundary. If you have several subscribers in a region different from the where messages are stored, you will be charged egress fees independently for delivery to every subscriber.
Pub/Sub automatically acknowledges the messages that don't match a filter, but you still incur throughput (not delivery egress 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.
Storage of unacknowledged messages does not result in fees.
There are three cases when Pub/Sub storage is not free:
- A topic is configured to retain all messages to make it possible for any attached subscriptions to later re-process them using seek. In this case, message storage fees are charged for storing all messages published to the topic.
- 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.
Note: 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.
Topic retention may be a more economical way to retain messages for replay than retaining all acknowledged messages for a subscription because the messages retained for a topic can be used across all subscriptions attached to that topic. Snapshots can also be an economical option 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. Topics and subscriptions configured to retain messages maintain a fixed time window of message data (at steady state), and are typically more convenient to use.
Message volume calculation
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.
Throughput charges apply 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 (2^40 bytes, or approximately 1.1 trillion bytes).
Egress fees due to message storage policy
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.
Cross-project egress fees
A message storage policy can result in additional region egress fees if the policy forces the data to exit a Google Cloud region. For example, 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 containing the subscription will be charged an egress fee only if the published message is stored in a different region from the subscriber client is (C is not the same as B).
Pub/Sub Lite service pricing
The following pricing details apply to only to Pub/Sub Lite (not Pub/Sub).
The pricing table summarizes throughput prices. Pub/Sub Lite egress prices are the same as for Pub/Sub, with one addition: zone egress fees are charged similarly to Compute Engine.
The pricing for zone and internet egress is the same as the pricing for networking products.
For an example scenario with usage and charges, see the Pricing examples table.
Throughput capacity is provisioned in MiB per sec. A partition can have 4 to 16 MiB per sec of publishing throughput capacity and 4 to 32 MiB per sec of subscribing throughput capacity.
A partition must have at least 30 GiB of storage. Each of the partitions in a Lite topic has the same amount of storage.
Pub/Sub Lite charges for the maximum amount of storage that you provision in a month.
Pub/Sub Lite egress prices are the same as for Pub/Sub, with one addition: zone egress fees are charged similarly to Compute Engine.
To determine how much capacity to provision to a Pub/Sub Lite system, account for the throughput and storage that you need on average and any spare capacity for peak traffic.
If you use 10 MiB/s of publishing throughput and 20 MiB/s of subscribing throughput on average, provision 20 MiB/s of publishing capacity and 40 MiB/s of subscribing capacity, at a cost $180/month in North America.
To estimate the storage and the cost of storage per partition, determine how long to store messages and how much spare storage you need. For example, to publish 4 MiB of messages per sec and retain messages for one day, provision 337.5 GiB of storage. To save half of the storage for traffic increases, provision each partition at least 675 GiB.
The following table shows the cost of storage in North America:
|Data published/s||Data published/mo||Maximum storage/mo||Cost/partition|
|1 MiB||2.5 TiB||84 GiB||$3|
|10 MiB||25 TiB||844 GiB||$34|
|100 MiB||247 TiB||8438 GiB||$338|
Message volume calculation
Lite topics store messages in partitions, and each message uses 256 bytes-3.5 MiB of storage. If the message is larger than 256 bytes, then the size of the message is the sum of the following:
- The number of bytes in the encoded message body string
- The number of bytes in the key and value of each attribute
- The number of bytes in the ordering key
- 12 bytes for the event timestamp