Cloud SQL for PostgreSQL: Setup, Pricing & Best Practices

Cloud SQL for PostgreSQL at a glance

Cloud SQL for PostgreSQL (often searched as Cloud SQL Postgres or GCP Postgres) is the PostgreSQL engine of Google Cloud SQL. Google states that its functionality is in general the same as a locally hosted PostgreSQL instance, with a few differences: features that need SUPERUSER are unavailable (with exceptions for supported extensions and casts), as are custom background workers and LLVM JIT compilation. Applications connect over the standard PostgreSQL protocol, so drivers, ORMs and tools such as pgAdmin and DBeaver work as usual.

Cloud SQL supports a new PostgreSQL major version within 90 days of its community release and keeps minor versions patched during maintenance. When a major version reaches community end of life it moves to extended support for three years at an extra per-vCPU charge, then Cloud SQL upgrades remaining instances automatically.

How to create a Cloud SQL for PostgreSQL instance

Google's quickstart creates an instance from the Cloud SQL Instances page in the console: click Create instance, choose New instance, choose PostgreSQL, enter an instance ID and a password for the postgres user, and click Create instance. You need the Cloud SQL Admin role and a project with billing enabled. A new instance contains a postgres database, and the default postgres user belongs to the cloudsqlsuperuser role.

The choices that matter most are made at creation time:

• Edition. Enterprise offers shared-core, general purpose dedicated-core and N4 machines; Enterprise Plus offers N2, C4A and C4 machines with sub-second maintenance and data cache. For PostgreSQL 16 and later the default is Enterprise Plus, so switch to Enterprise if you want the lower rate.
• Machine size. Google advises giving OLTP workloads enough memory to hold the working set; you can scale up later.
• Networking. The quickstart uses a public IP. For production, Google recommends private IP inside your VPC.
• Storage. Capacity can be increased but not decreased in place, and automatic storage increases are on by default.
• High availability. A regional (HA) instance adds a standby in a second zone at double the cost.

Connecting with the Cloud SQL Auth Proxy and psql

For a public IP instance, the documented route is the Cloud SQL Auth Proxy. Copy the instance connection name (projectID:region:instanceID) from the instance Overview page, start the proxy in its own terminal, then point psql at the local port. These are the commands from Google's quickstart (shell):

./cloud-sql-proxy INSTANCE_CONNECTION_NAME
psql "host=127.0.0.1 port=5432 sslmode=disable dbname=DB_NAME user=postgres"

The proxy encrypts the link to Cloud SQL itself, which is why the local connection uses sslmode=disable; Google recommends running the proxy on the same machine as the workload because the hop between your client and the proxy is not encrypted. The proxy uses IAM to authorise connections and supports automatic IAM database authentication. It does not pool connections, so put PgBouncer or an application pool in front if you open many connections. On Windows the proxy cannot use Unix sockets.

The same settings work in GUI clients: connect to 127.0.0.1, port 5432, with your database user. See PostgreSQL GUI tools for options.

PostgreSQL extensions on Cloud SQL

You can install only the extensions Cloud SQL supports, you cannot add your own, and only members of cloudsqlsuperuser can create them. The supported list is long; among the most requested are pgvector for storing and searching vector embeddings (version 0.8.5 on PostgreSQL 13 and later), PostGIS for all major versions, pg_cron for scheduling SQL from inside the database, pgAudit, pg_stat_statements, pglogical, hstore and uuid-ossp.

Install extensions on the primary; they replicate to read replicas. Maintenance installs new extension binaries but does not update the extension in your database catalog, so check and update versions yourself (PostgreSQL):

CREATE EXTENSION IF NOT EXISTS postgis;
SELECT * FROM pg_extension;
ALTER EXTENSION postgis UPDATE;

Some extensions, such as pglogical, need database flags set before you create them.

Read replicas, high availability and recovery

Cloud SQL for PostgreSQL supports in-region, cross-region and cascading read replicas, and you can also run your own logical replication with PostgreSQL's built-in features or pglogical. Two PostgreSQL-specific points are worth knowing. First, max_connections on a replica must be at least as large as on its primary; if you leave the flag unset and give the replica less memory, it can inherit a value too high for its size, so set the flag explicitly. Second, unlogged tables are not replicated to read replicas, do not survive failover on an HA instance, and are wiped during a backup restore.

High availability uses a standby in another zone with synchronous writes, and failover takes about a minute. Point-in-time recovery keeps transaction logs for up to 7 days on Enterprise and up to 35 days on Enterprise Plus. A standalone (zonal) instance is not recovered automatically from a zonal outage: you restore it with PITR or promote a replica in another zone.

Cloud SQL for PostgreSQL or AlloyDB?

Google offers two managed PostgreSQL services. AlloyDB uses a Google-built, PostgreSQL-compatible engine with separate compute and storage, a columnar engine for analytics and read pools of up to 20 nodes. In our assessment, the choice usually comes down to workload size and how much PostgreSQL fidelity you need.

Our rule of thumb

Start on Cloud SQL for typical application databases. Consider AlloyDB when you outgrow a single Cloud SQL instance, need heavy read scaling or want reporting queries on the live database. See also Google Cloud SQL vs AlloyDB.

Best practices for Cloud SQL Postgres

• Use private IP for production and the Auth Proxy or a language connector for public IP.
• Stay on a version in regular support; PostgreSQL 13 instances already pay for extended support.
• Set max_connections deliberately, especially with smaller replicas, and pool connections in the application.
• Avoid unlogged tables for data you need to restore or replicate.
• After maintenance, compare installed extension versions with the supported list and run ALTER EXTENSION ... UPDATE.
• Set an automatic storage increase limit if you want to cap growth, because increases are permanent unless you shrink storage manually.
• Choose Enterprise Plus where maintenance restarts of up to 30 seconds are not acceptable.

The usual PostgreSQL disciplines still apply on a managed service; see the SQL indexes and transactions and concurrency lessons.

Pricing

Prices from the provider's official pricing pages, checked 8 October 2026, region Iowa (us-central1), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.

Google Cloud Postgres pricing on Cloud SQL follows the general Cloud SQL rates: Enterprise vCPU 0.0413 USD per hour, memory 0.007 USD per GiB-hour, SSD storage 0.000232877 USD per GiB-hour and backups 0.000109589 USD per GiB-hour; HA instances use 0.0826 USD per vCPU-hour, 0.014 USD per GiB-hour of memory and 0.000465753 USD per GiB-hour of SSD. End-of-life versions add extended support at 0.07 USD per vCPU-hour in the first two years. See the Cloud SQL pricing guide for Enterprise Plus rates and committed use discounts.

Worked examples are estimates calculated from the list prices above; they are not quotes or measured bills.

Frequently asked questions

Sources

• Cloud SQL for PostgreSQL features
• Cloud SQL for PostgreSQL: database versions and version policies
• Cloud SQL editions overview (PostgreSQL)
• Cloud SQL for PostgreSQL: Create instances
• Quickstart: Connect using the Cloud SQL Auth Proxy (PostgreSQL)
• About the Cloud SQL Auth Proxy
• Configure PostgreSQL extensions
• About replication in Cloud SQL (PostgreSQL)
• About high availability (PostgreSQL)
• Cloud SQL backups overview (PostgreSQL)
• Instance settings (PostgreSQL)
• AlloyDB overview
• AlloyDB: Create a cluster and its primary instance
• Cloud SQL pricing

Checked 8 October 2026.

How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.