The cost of 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 costs for snapshots, messages retained by topics, and acknowledged messages retained by subscriptions
Pub/Sub service charges are based on usage (the number of published, delivered, or stored bytes).
Pub/Sub Lite throughput and storage charges, by contrast, are based on reserved capacity.
Egress charges for both services are based on usage, rather than reserved capacity.
This document requires that you understand the architecture of Pub/Sub or Pub/Sub Lite and the common terms that are part of each product. For more information, see Pub/Sub architecture.
The following table compares the monthly cost of Pub/Sub and Pub/Sub Lite systems for sample loads in North America. This example assumes a 24-hour message storage period, a 50% resource utilization for Pub/Sub Lite, and a pull or push subscription type for Pub/Sub. Other types of subscriptions might have additional costs.
|Publish throughput in MiBps||Number of subscriptions||Zonal Lite topic||Regional Lite topic||Pub/Sub|
When you compare the cost of Pub/Sub and Pub/Sub Lite, consider the differences in features between the two products. For more information, see Choosing Pub/Sub or Pub/Sub Lite.
Pub/Sub service pricing
The pricing details in this section apply only to Pub/Sub and not Pub/Sub Lite. This section includes the following topics:
Throughput is the total number of bytes written (publish throughput) to a Pub/Sub topic or read (subscribe throughput) from a subscription to a topic over an interval of time.
Every calendar month, the first 10 GiB of throughput identified as the Message Delivery Basic SKU for a billing account is free. After that, the price is $40 per TiB in all Google Cloud regions. However, if you are using BigQuery subscriptions, read the next section.
Throughput costs for BigQuery subscriptions
BigQuery subscriptions cost $50 per TiB in all Google Cloud regions for reading (subscribe throughput) from a subscription and writing to BigQuery. There are no additional BigQuery data ingestion charges. However, other types of BigQuery charges such as storage and data extraction apply. For more information, see BigQuery pricing. The first 10 GiB of BigQuery subscription throughput is not free.
Message volume calculation
The data volume of a message is the sum of the sizes of the following message attributes:
- 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
- The size of additional optional fields, such as those associated with early access and other restricted-access APIs.
A minimum of 1 KB is assessed for each request, independent of the message sizes in the request. Hence, for messages smaller than 1 KB, it is cheaper to batch multiple messages in a single request.
Storage of unacknowledged messages in subscriptions is free for up to seven days.
There are three cases when Pub/Sub storage is not free. Storage costs of $0.27 per GiB-month is charged for the following:
- 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.
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 are 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 region where messages are stored, you are charged egress fees independently for delivery to each subscriber.
Egress costs due to message storage policy
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 events:
- Published in region A
- Routed to region B for storage
- Delivered to a subscriber client in region C
In this case, the billing scenario is explained as follows:
- 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 (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).
Filtered messages costs
Pub/Sub automatically acknowledges the messages that don't match a filter, but you still incur throughput fees for these messages. There are no egress fees for filtered 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, and is independent of the small size of the messages.
Cross-project Pub/Sub billing
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.
Pub/Sub Lite service pricing
The following pricing details apply only to Pub/Sub Lite, not Pub/Sub. Unless otherwise specified, the details apply to both zonal and regional Lite topics. The following sections are included:
Throughput is the total number of bytes written (publish throughput) to a Pub/Sub Lite topic or read (subscribe throughput) from a subscription to a topic over an interval of time.
Pub/Sub Lite throughput fees are based on the provisioned or reserved throughput capacity, rather than the actual throughput (MiBps) or the total number of bytes in a billing period (MiB per month). Throughput capacity is provisioned and priced in capacity units. You can provision throughput capacity for one or more topics in the same region by using a Lite reservation.
The following table shows the costs for throughput and storage for a Pub/Sub Lite system.
Throughput with a Lite reservation
Lite reservations are a way to reserve and share throughput capacity among one or multiple topics in a region. Lite reservations are required for regional Pub/Sub Lite topics.
Throughput capacity for Lite reservations is measured in capacity units. You can provision only a whole number of capacity units for a reservation. Throughput of different operations require a different number of capacity units, as described in the following table:
|Capacity units required||Zonal Lite topic||Regional Lite topic|
|1 MiBps of publish throughput||1 capacity unit||4 capacity units|
|1 MiBps of subscribe throughput||0.5 capacity units||2 capacity units|
The number of partitions across all Lite topics in a reservation must be no greater than the number of capacity units reserved.
Calculate the cost of throughput capacity for a single topic with reservations
The following section helps you to calculate the cost of throughput capacity for a single zonal Lite topic that uses reservations:
- Type of topic = Zonal Lite topic
- Number of topics = 1
- Number of partitions = 5
- Peak publish throughput = 5 MiBps
- Capacity units required for publish throughput = 5
- Peak subscribe throughput = 10 MiBps
- Capacity units required for subscribe throughput = 5
- Total capacity units required = 5+5 = 10
- Cost of 10 capacity units in North America per month = $45
For the same throughput with a regional Lite topic with 5 partitions, you require a reservation with 40 capacity units, 20 for publish throughput and 20 for subscribe throughput.
You can change the number of capacity units in a reservation at any time. However, you are billed for the maximum capacity provisioned in the last 24 hours. For example, if you change the capacity of a reservation from 40 to 10 capacity units at 10:00 AM on Monday, you are billed for 40 capacity units per hour until 10:00 AM on Tuesday and for 10 capacity units per hour afterwards.
Note that the capacity of a reservation can be used for publish and subscribe throughput with any topic in the same region as the reservation. To learn more about reservations, see Create and manage Lite reservations.
Throughput without a Lite reservation
This section applies to zonal Lite topics only.
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 the following limits:
- 4 and 16 MiBps (equivalent to 4 and 16 capacity units) for publish for each partition.
- 4 and 32 MiBps (equivalent to 2 and 16 capacity units) for subscribe for each partition.
Calculate the cost of throughput capacity for a single topic without reservations
The following section helps you to calculate the cost of throughput capacity for a single zonal Lite topic that does not use reservations:
- Type of topic = Zonal Lite topic
- Number of topics = 1
- Number of partitions = 4
- Peak publish throughput = 16 MiBps
- Capacity units required for publish throughput = 16
- Peak subscribe throughput = 16 MiBps
- Capacity units required for subscribe throughput = 8
- Total capacity units required = 16+8 = 24
- Cost of 24 capacity units in North America per month = $108
As with Lite throughput, you pay for the storage capacity of a topic. Pub/Sub Lite charges for the maximum amount of storage that you provision in a month. Each partition must have at least 30 GiB of storage capacity.
A regional Lite topic stores data in two zones in a region, whereas a zonal Lite topic stores data only in one zone in a region. Regional Lite topics use two bytes of storage for every byte of messages published. Therefore, the storage cost per byte published to a regional Lite topic is double the cost for a zonal one.
To estimate storage capacity for a Pub/Sub Lite system, refer to the following list:
Determine the length of time you require to store messages.
To estimate the total storage required, multiply your average expected throughput for each partition by the length of time needed to store your messages. For example, to publish 40 MiB of messages per second across 10 partitions in a zonal Lite topic and to retain messages for one day, provision 3375 GiB of storage (equivalent to 40 MiBps * 3600 secs per hour * 24 hrs per day * 1 GiB/1024 MiB). The storage costs you $135 in North America (equivalent to 3375 GiB * 24 hours per day * 30 days per month * $0.04 / GiB-month-zone). For a regional Lite topic, since the data is stored in two zones, the storage cost is doubled to $270.
Consider uneven key distribution.
All partitions are allocated the same storage capacity. If you expect some partitions to have a larger volume than others, provision all partitions to have the storage required for the largest partition.
Message volume calculation
When computing the size of messages for throughput and storage, each message uses a minimum of 256 bytes. If the message is larger than 256 bytes, then the size of the message is the sum of the following message attributes:
- 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
Pub/Sub Lite egress fees apply only if your subscribers are in a different zone or region from the location of the topic. The fees for internet egress and message delivery between Google Cloud regions are consistent with the VPC network rates, with the following exceptions:
For regional Lite topics with subscribers in the same region as the topic, there are no zone egress fees.
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 are charged egress fees.
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).
Calculate your Pub/Sub costs using the pricing calculator.
Refer to the Pub/Sub SKU groups.