Quotas and limits

Stay organized with collections Save and categorize content based on your preferences.

This page provides information about the Cloud SQL quotas and limits. Quotas are applied per-project; limits are applied to the instance or to the project, depending on the limit.

Check your quotas

To check the current quotas for resources in your project, go to the Quotas page in the Google Cloud console and filter for Cloud SQL Admin API. These quotas apply only to API calls; they don't include database queries.

Increase your quotas

As your use of Google Cloud expands over time, your quotas can increase accordingly. If you expect a notable upcoming increase in usage, make your request a few days in advance to ensure your quotas are adequately sized.

  1. On the Quotas page, select Cloud SQL Admin API from the Services drop-down list.

    If you do not see Cloud SQL Admin API, the Cloud SQL Admin API has not been enabled.

  2. Select the quotas you want to change.

  3. Click Edit quotas.

  4. Fill out your name, email, and phone number and click Next.

  5. Fill in your quota request and click Submit request.

You will receive a response from the Cloud SQL for PostgreSQL team within 48 hours of your request.

How resource quotas are replenished

Daily quotas are replenished daily at midnight Pacific Time.

Quotas and resource availability

Resource quotas are the maximum amount of resources you can create for that resource type if those resources are available. Quotas do not guarantee that resources will be available at all times. If a resource is not physically available for your region, you will not be able to create new resources of that type, even if you still have remaining quota in your project.

Limits

There are restrictions on some Cloud SQL resources that are not replenished periodically and not shown on the Quotas page in the Google Cloud console. Some limits can be increased while others cannot.

Configurable limits

Instances per project

By default, you can have up to 100 instances per project. If you need more, file a support case to request the increase. Read replicas are counted as instances.

We recommend that you distribute your instance count across multiple projects to reduce the reliance on quota increase requests. This will help you avoid any potential blockages.

Maximum concurrent connections

You can use the max_connections flag to configure connections limits. When you create a Cloud SQL for PostgreSQL instance, the machine type configuration settings automatically adjust the range of memory sizes available, based on the number of cores you select. This also determines the initial default connection limits set for the instance.

You can find the connection limits for your instance by connecting to your database and running this command: SELECT * FROM pg_settings WHERE name = 'max_connections';

The value on replicas must be greater than or equal to the value on the primary. Changes on the primary propagate to replicas that have a value that is lower than the new value on the primary, or that have not been changed from the default value.

Caveats

Cloud SQL connectors's quota usage

The Cloud SQL Auth proxy and other Cloud SQL connectors use Cloud SQL Admin API's quota. The quota usage is calculated as:

Quota used = Instances of the proxy * Instances of Cloud SQL * 2 per refresh attempt

A refresh attempt happens when a connector starts up, and typically happens every hour after that, but can happen as often as every 30 seconds if something goes, such as an instance failover or Admin API call failure.

If you use automatic instance discovery or the -projects parameter, then you might see high quota usage because of the large number of instances. While the Cloud SQL Auth proxy is running, it issues 2 API calls per hour per connected instance.

If you're getting started with Cloud SQL, then keeping note of the above formula, you should be mindful of:

  • How quickly you scale up new DB clients

  • How quickly you add more instances

  • Using different service accounts for each application

Cloud SQL IAM database authentication

There's a per-minute login quota for each instance, which includes both successful and unsuccessful logins. When the quota is exceeded, logins are unavailable temporarily. We recommend that you avoid frequent logins and restrict logins using authorized networks. The quota for authorization of logins is 3000 per minute, per instance.

Forwarding rule quota

Each Cloud SQL instance consists of a forwarding rule and a load balancer. There's quota limit on the forwarding rule, based on the kind of load balancer to which it's pointing. There are multiple quotas on each kind of forwarding rules, per project, per network and per peering group. There's also an override rule for per network quota and per peering group quotas, for Cloud SQL. This means when we bump up the per network quota for producer networks, the per peering group quota gets bumped to the same value as well.

Cloud SQL producer VPC is peered with customer's VPC, so we often hit per network quota for Cloud SQL producer network, and per peering group quota for customer's VPC.

When we hit the quota, certain operations could fail, which includes:

  • Create Operation: We need new forwarding rules when we create new instances.

  • Update Operation: We allow customers to switch the network of instances, so we will need new forwarding rules in the new network.

  • Maintenance Operation: Forwarding rules get recreated.

If you experience such issues, then file a support case and we'll bump the relevant quota(s) for you.

Fixed limits

IOPS

IOPS are the number of input/output operations (or read/write) operations that your disk can process per second.

Cloud SQL uses Compute Engine virtual machines (VMs) with persistent storage disks. For details on specific VM performance characteristics, see the maximum sustained IOPS table on the persistent disk performance page.

Operations limit

Micro and small tier machine types limit the number of concurrent operations. Exceeding these limits causes a Too many operations error.

The db-custom-1-3840 (single CPU) machine type limit is 50 concurrent operations.

The f1-micro (shared-core CPU) machine type limit is 20 concurrent operations.

Metrics collection limit

PostgreSQL metrics are collected for up to 500 databases.

Cloud SQL storage limits

Cloud SQL storage options

To configure a storage option for best performance, it's important to understand your workload and choose the appropriate disk type and size. For more information on the available choices for Cloud SQL, see instance settings.

App Engine limits

Each App Engine instance running in a standard environment cannot have more than 100 concurrent connections to an instance. For PHP 5.5 apps, the limit is 60 concurrent connections.

App Engine applications are subject to request time limits depending on usage and environment. For more information, see how instances are managed in App Engine standard environment standard and flexible environments.

App Engine applications are also subject to additional App Engine quotas and limits as discussed on the App Engine Quotas page.

Cloud Run limits

Cloud Run services are limited to 100 connections to a Cloud SQL database. This limit applies per service instance. This means that each instance of the Cloud Run service can have 100 connections to the database, and as it scales the total number of connections per deployment can grow.

Cloud Functions limits

Cloud Functions (1st gen) limits concurrent executions to one per instance. You never have a situation where a single 1st gen function instance is processing two requests at the same time. In most situations, only a single database connection is needed.

Cloud Functions (2nd gen) is based on Cloud Run and has a limit of 100 database connections per instance.