This page describes quotas and request limits for Cloud Storage.
Buckets
There is a per-project rate limit to bucket creation and deletion of approximately 1 operation every 2 seconds, so plan on fewer buckets and more objects in most cases. For example, a common design choice is to use one bucket per user of your project. However, if you're designing a system that adds many users per second, then design for many users in one bucket (with appropriate permissions) so that the bucket creation rate limit doesn't become a bottleneck.
Highly available applications should not depend on bucket creation or deletion in the critical path of their application. Bucket names are part of a centralized and global namespace: any dependency on this namespace creates a single point of failure for your application. Due to this and the 1 operation per 2-second limit mentioned above, the recommended practice for highly available services on Cloud Storage is to pre-create all the buckets necessary.
There is an update limit on each bucket of once per second, so rapid updates to a single bucket (for example, changing the CORS configuration) won’t scale.
There is a limit of 100 members holding legacy IAM roles per bucket. Examples of members include individual users, groups, and domains. See IAM identities.
For buckets with Pub/Sub notifications:
The bucket can have up to 100 total notification configurations.
The bucket can have up to 10 notification configurations set to trigger for a specific event.
Each notification configuration can have up to 10 custom attributes.
Objects
There is a maximum size limit of 5 TB for individual objects stored in Cloud Storage.
- The maximum size of a single upload request is also 5 TB. For uploads that would take a long time over your connection, consider using resumable uploads in order to recover from intermediate failures. See JSON API resumable uploads or XML API resumable uploads for more information.
There is an update limit on each object of once per second, so rapid writes to a single object won’t scale. For more information, see Object immutability in Key Terms.
There is no limit to writes across multiple objects, which include uploading, updating, and deleting objects. Buckets initially support roughly 1000 writes per second and then scale as needed.
There is no limit to reads of an object. Buckets initially support roughly 5000 object reads per second and then scale as needed.
Performance is much better for publicly cacheable objects. If you have an object being used to control many clients and thus want to disable caching to provide the latest data:
Consider instead setting the object's
Cache-Control
metadata topublic
withmax-age
of 15-60 seconds. Most applications can tolerate a minute of spread, and the cache hit rate will improve performance drastically.Proxy data transfers through a Google App Engine application located in the same location as your bucket.
Use
Cache-Control: no-cache
for an object to indicate that the object must not be cached for subsequent requests in edge-caches.
For more information about
Cache-Control
directives, see RFC 7234: Cache-Control.There is a limit of 100 access control list entries (ACLs) per object. Members can be individual users, groups, or domains. See ACL scopes.
For object composition:
Up to 32 objects can be composed in a single composition request.
While there is no limit to the number of components that make up a composite object, the
componentCount
metadata associated with a composite object saturates at 2,147,483,647.Composite objects are subject to the overall 5 TB size limit for objects stored in Cloud Storage.
XML API requests
When sending requests through the XML API, there is a limit on the combined size of the request URL and HTTP headers of 16 KB.
When listing resources with the XML API, there is a limit of 1000 items that get returned.
HMAC keys for service accounts
- There is a limit of 5 HMAC keys per service account. Deleted keys do not count towards this limit.