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, refers to publish requests and data delivered using pull, streamingPull, or push operations. It is priced per volume of data transmitted in a calendar month.
The first 10 GiB are free. After that, the price is $40 per TiB in all Google Cloud regions.
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.
A minimum of 1 KB 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.
Storage of unacknowledged messages in a subscription does not result in fees.
There are three cases when Pub/Sub storage is not free:
- A topic is configured to retain all messages. In this case, message storage fees are charged for storing all messages published to the topic.
- A subscription is configured to retain acknowledged messages. 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.
The price of storage in these cases is $0.27 per GiB-month.
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.
Retaining acknowledged messages in individual subscriptions offers the most flexibility to subscription owners but is usually the most expensive storage mechanism. The least expensive storage mechanism is topic retention because messages retained for a topic can be used across all subscriptions attached to that topic without additional fees per subscription. Snapshots can also be an economical option because a single snapshot can be used across multiple subscriptions.
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.
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-region 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 with the following lifecycle:
- Published in region A
- Routed to region B for storage
- Delivered to a subscriber client in region C
The following is the billing logic where A, B, and C are all different regions:
- 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 is charged an egress fee only if the published message is stored in a region different from the region where the message was published. The project containing the subscription is charged an egress fee only if the published message is stored in a different region from the subscriber client.
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.
Pub/Sub Lite service pricing
The following pricing details apply to only to Pub/Sub Lite, not Pub/Sub.
Throughput capacity for Lite reservations is provisioned in capacity units. One capacity unit corresponds to 1 MiB/s of publish traffic or 2 MiB/s of subscribe traffic.
Lite reservations are billed for the maximum capacity provisioned in the last 24 hours for any given minute. For example, if you create a reservation with 10 capacity units on Monday at 10 am, then reduce the size of this reservation to 5 capacity units at 3:30 pm, you will be charged for 10 capacity units per hour until 3:30 pm on Tuesday. After that you will be charged for 5 capacity.
You can choose to not use reservations and reserve publish and subscribe throughput capacity for a single topic. In this case, you are billed for the currently reserved capacity rather than the maximum over a running 24 hour window. Note that capacity configured without reservations must be between:
- 4 and 16 MiB/s (equivalent to 4 and 16 capacity units) for publishing.
- 4 and 32 MiB/s (equivalent of 2 and 16 capacity units) for subscribing.
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
Paying in currency other than USD
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).