Quotas and limits

This document provides information about quotas and resource limits for Cloud Pub/Sub.

For more information about tracking your quotas (such as topic or subscription utilization), see Monitoring.

Viewing quota usage and managing quota limits

For a given project, you can use the APIs and services quotas dashboard to view current quotas and usage. You can also use this dashboard to modify one quota at a time.

To modify multiple quotas, use the IAM & admin quotas dashboard

You can use either of the above dashboards to:

  • Reduce your quotas.
  • Initiate a process to apply for higher quota limit(s).

Quota units

Each measured request or response counts as the greater of 1 kB or the total size of the request or response.

The quota usage for each request or response is rounded up to the nearest 1 kB increment. Consider a publish request with 100 messages of 50 bytes each and a topic name length equal to 30 bytes. The request's quota usage would be max(1, ceil(5030/1000)) = 6kB.

Project usage attribution

For push subscriber throughput, quota usage is charged against the project that contains the push subscription.

For the following quotas, usage is charged against the project associated with the caller's credentials, not against the project that contains the requested resource (that is, the project that appears in the topic or subscription name):

  • Publisher throughput
  • Subscriber throughput
  • Administrator operations

For example: If a service account in project A sends a publish request to publish to a topic in project B, the quota is charged to project A. Every request contains credentials that include a project ID.

Quota limits

The quotas listed in the following table can be viewed and edited on a per-project basis in the APIs and services quotas dashboard.

Quota Default quota limit Description
Publisher throughput 60,000,000 kB per minute (1,000 MB/s) Quota usage is based on the size of message(s) contained in PublishRequest:

Note that multiple messages can be included in a single publish request, and there is no additional quota charge per message.

Subscriber throughput 120,000,000 kB per minute (2,000 MB/s) For pull subscriptions, quota usage is based on the size of Pull responses, to include:

In addition, Acknowledge and ModifyAckDeadline requests are included in this quota:

  • AcknowledgeRequest (RPC)
  • ModifyAckDeadlineRequest (RPC)
    Push subscriber throughput 6,000,000 kB per minute (100 MB/s) For push delivery requests made to the push endpoint, quota usage is based on the size of requests to the push endpoint.
    StreamingPull subscriber throughput 120,000,000 kB per minute (2000 MB/s) Quota usage is based on the size of StreamingPullResponses:

    Note that Client Libraries use StreamingPull operations where possible.

    Number of open StreamingPull connections 30,000 open connections at a time The number of open StreamingPull connections at any given time. See StreamingPull.
    Rate of StreamingPull connections 6,000,000 per minute The rate of opening new StreamingPull connections. See StreamingPull.
    Administrator operations 6,000 per minute (100 ops/s) Each administrator operation, such as GetTopicRequest , charges one unit against this quota.

    In general, Get*, List*, Create*, Delete*, ModifyPushConfig, SetIamPolicy, GetIamPolicy, and TestIamPermissions comprise the set of administrative operations.

    Resource limits

    Resource Limits
    Project 10,000 topics
    10,000 subscriptions
    5,000 snapshots
    Topic 10,000 attached subscriptions
    5,000 attached snapshots
    Subscription Retains unacknowledged messages in persistent storage for 7 days from the moment of publication. There is no limit on the number of retained messages.
    Subscriptions whose client presence has not been detected for 31 days may be automatically deleted. Presence is detected through calls such as Pull, Acknowledge, and successful push operations.
    Publish request 10MB (total size)
    1,000 messages
    Message Message size (the data field): 10MB (the maximum request size)
    Attributes per message: 100
    Attribute key size: 256 bytes
    Attribute value size: 1024 bytes
    Push delivery messages Outstanding messages are subject to both of the following per-subscription limits:
    • 10 MB (this limit applies to the sum of the sizes of all outstanding messages, including message data and attributes)
    • A total of 1000 outstanding messages
    If your endpoint responds quickly (faster than 100ms), these limits are unlikely to come into effect. See the Push Subscriber Guide.
    StreamingPull streams 10 MB/s per open stream
    Pull/StreamingPull messages The service might impose limits on the total number of outstanding StreamingPull messages per connection. If you run into such limits, increase the rate at which you acknowledge messages and the number of connections you use.

    Tips and caveats

    High-volume operations

    If you use the Cloud SDK gcloud tool with a normal user account (that is, a non-service account), Cloud Pub/Sub operations are limited to a rate suitable for manual operations. Rates in excess of this limit will result in the RESOURCE_EXHAUSTED error. The solution is to make sure that you are using service account credentials. If you wish to use credentials from the Cloud SDK for automation, activate a service account for your Cloud Pub/Sub operations.

    Quota mismatches

    Quota mismatches can happen when published or received messages are smaller than 1000 bytes. For example:

    • If you publish 10 500-byte messages in separate requests, your publisher quota usage will be 10,000 bytes. This is because messages that are smaller than 1000 bytes are automatically rounded up to the next 1000-byte increment.

    • If you receive those 10 messages in a single pull response, your subscriber quota usage might be only 5 kB, since the actual size of each message is combined to determine the overall quota.

    • The inverse is also true. The subscriber quota usage might be greater than the publisher quota usage if you publish multiple messages in a single publish request or receive the messages in separate Pull requests.

    Was this page helpful? Let us know how we did:

    Send feedback about...

    Cloud Pub/Sub Documentation