Google Cloud Postgres: What Cloud SQL Gives You, Explained Neutrally

Cloud SQL for PostgreSQL is Google Cloud’s managed Postgres: they run the instance, apply patches, take backups, and handle failover, and you get a normal Postgres you connect to with normal tools. Most of what it does is what any managed Postgres does, and separating those parts from the Google-specific ones is the useful exercise.

Vendor documentation is thorough about features and quiet about which of them are ordinary. If you are evaluating Cloud SQL, or trying to understand a system already using it, the question worth answering is which capabilities are inherent to managed Postgres, which are Google particulars, and which you would have to build yourself elsewhere.

Table of contents

• What managed Postgres means anywhere
• The Cloud SQL specifics worth knowing
• Connecting, which is the part that confuses people
• The costs to look at
• When it is the right choice
• Migrating in or out
• How this fits the rest of the stack
• FAQ

What managed Postgres means anywhere

Before anything Google-specific, the baseline. Every managed Postgres service provides roughly this set, and it is the reason people use one:

• Provisioning. An instance exists a few minutes after you ask for one, without installing anything.
• Patching. Minor versions and security fixes applied by the provider, usually in a maintenance window you can influence.
• Backups. Automatic, on a schedule, with a retention period, restorable without you writing the procedure.
• Point-in-time recovery. Continuous transaction log archiving so you can restore to a moment rather than to last night.
• High availability. A standby that takes over on failure, if you enable it.
• Read replicas. Additional instances serving reads.
• Monitoring. Metrics without installing an agent.
• Network isolation. The instance on a private network rather than exposed to the internet.

It is still Postgres. Your queries, your ORM, psql, pg_dump, and the extensions you use work as they do anywhere. That is the point of managed Postgres rather than a proprietary database — the compatibility is the product.

What you give up is the operating system. No shell on the machine, no editing postgresql.conf directly, no installing arbitrary extensions. Configuration happens through a defined set of flags, and extensions are limited to a supported list. For most applications this is invisible; for a workload needing an unusual extension it is the constraint that decides the question.

The Cloud SQL specifics worth knowing

The parts that are particular to Google’s implementation, or where the details differ enough to matter.

Editions. Cloud SQL is split into Enterprise and Enterprise Plus. The Plus edition offers a higher availability SLA, near-zero-downtime maintenance, a data cache for read-heavy workloads, and longer log retention. The distinction is real and it affects both price and behaviour, so knowing which edition an existing instance uses matters when interpreting its performance.

Flags. Rather than editing configuration files, you set database flags through the console, CLI, or API. A large number are exposed, and some require a restart. If you are used to tuning postgresql.conf directly, this is the equivalent surface, and anything not exposed as a flag is not adjustable.

Maintenance windows. You can set a preferred window, receive advance notice, and postpone maintenance within limits or set a deny period. This is more control than some providers offer and it is worth configuring rather than accepting the default.

Query Insights. Built-in query performance analysis with visual plans, which covers similar ground to pg_stat_statements with a graphical layer over it. Useful, and worth knowing that the underlying data is the ordinary Postgres statistics you could read yourself.

IAM database authentication. Connecting using cloud identities rather than database passwords. Genuinely useful for eliminating long-lived credentials, and specific to the cloud it runs in — code written against it does not move unchanged.

Connecting, which is the part that confuses people

Connection is where Cloud SQL differs most from a database with a hostname and a password, and it is where most of the initial difficulty lives.

There are several paths and choosing the wrong one produces a lot of confusion.

Public IP with authorised networks. The instance gets a public address and you allowlist source IPs. Simplest to get working, and it means your database has a public address, which is the arrangement to avoid where anything else is available.

Private IP through VPC. The instance is reachable only from within your virtual private cloud. This is the right default — the application connects over the private network and the database is not addressable from the internet at all.

The Cloud SQL Auth Proxy. A small local process that authenticates using cloud credentials and presents a local socket your application connects to as though the database were local. It handles encryption and identity without you managing certificates. This is the recommended route for connecting from outside the VPC, including from a developer machine.

cloud-sql-proxy --port 5433 project:region:instance

# Then connect as though it were local
psql -h 127.0.0.1 -p 5433 -U myuser mydb

Connectors for specific languages do the same thing in-process rather than as a separate binary.

The practical implication worth flagging: this is a Google-specific connection mechanism. An application built around the proxy or a language connector has a piece of Google Cloud in its data layer, which is a small but real dependency to note if portability matters.

The costs to look at

Without quoting figures, since they change and vary by region, the structure is what matters.

You pay for compute — vCPU and memory — per second while the instance runs. Instances can be stopped, which stops compute charges, and that is genuinely useful for development and staging instances that need not run overnight.

Storage is per gigabyte per month and can be set to grow automatically. Automatic growth is convenient and one-directional: storage does not shrink back, so a one-off large import permanently raises the floor. Consider whether you want automatic growth enabled on an instance where a runaway process could write a great deal.

High availability roughly doubles compute, because a standby is a second instance. Read replicas each add close to a full instance’s cost.

Backups have their own storage charge, and network egress is metered when data leaves the region or the provider.

The general advice from the wider question of database pricing applies here: size on memory rather than cores, pool connections rather than buying a larger plan for a connection limit, and keep the application in the same region and network as the database so query traffic is neither metered nor slow.

When it is the right choice

Cloud SQL is a reasonable default if you are already on Google Cloud. The integration with the surrounding services, the private networking, and the identity model all work together, and running your database somewhere else while your application runs there means paying egress and latency on every query.

It is a less obvious choice if you are not already on Google Cloud. The connection model, the identity integration, and the operational tooling all assume the surrounding platform, and adopting one managed database from a cloud you otherwise do not use brings a fair amount of that cloud with it.

The general principle, which holds regardless of provider: put the database next to the application. The cost of splitting them across providers is paid twice, in metered egress and in latency on every query, and it is rarely offset by a better unit price on the database.

If the application runs somewhere else, a managed Postgres from that platform on the same private network is usually the better arrangement — not because it is a better Postgres, but because the network topology is right. Managed Postgres on RunxBuild works that way: the same private network as the service, with backups, user management, and connection limits handled at the platform level, and standard pg_dump export whenever you want to leave.

Migrating in or out

A note on portability, since it is the reassuring part of choosing Postgres over something proprietary.

Moving into Cloud SQL is a standard Postgres import: pg_dump from the source, pg_restore into the target, or Google’s Database Migration Service for a lower-downtime path with continuous replication.

Moving out is the same tools in reverse. Because it is genuine Postgres, a dump is a dump and it restores anywhere that runs Postgres.

pg_dump -h 127.0.0.1 -p 5433 -U myuser -Fc mydb > mydb.dump
pg_restore -h newhost -U myuser -d mydb mydb.dump

What does not move is the surrounding configuration: IAM-based authentication, the proxy connection mechanism, flag settings, and any monitoring or alerting built on cloud-specific metrics. Those are reconstructed rather than exported, and they are the actual migration work.

This is the general shape of lock-in with managed databases and it is a reasonable one. The data is portable because the engine is standard; the operational surface around it is not. Keeping the application’s connection logic behind a thin abstraction, rather than scattering provider-specific connection code through it, keeps that surface small.

How this fits the rest of the stack

Cloud SQL for Postgres is competent managed Postgres, and most of what it provides — patching, backups, point-in-time recovery, replicas, private networking — is what managed Postgres means anywhere. The parts genuinely specific to it are the connection model, the identity integration, and the edition split, and those are the parts that do not travel. Wherever it runs, the rule that matters most is keeping the database on the same private network as the application. The RunxBuild hosting calculator shows managed Postgres alongside the service that queries it.

Useful related references:

• Show Databases in Postgres: Why SHOW DATABASES Does Not Work
• Postgres-XL: What the Distributed Fork Was, and Why It Lost to Citus
• Choosing a Vector Database for RAG: Start With Postgres
• Databases on RunxBuild

FAQ

What is Cloud SQL for PostgreSQL?

Google Cloud’s managed Postgres service. Google runs the instance, applies patches, takes automated backups, and handles failover, while you get a standard Postgres that works with psql, pg_dump, and your existing ORM. What you give up is operating-system access — configuration happens through defined flags and extensions come from a supported list.

How do I connect to a Cloud SQL Postgres instance?

Through a private IP within your VPC, which is the right default; through a public IP with authorised networks, which works and exposes the database publicly; or through the Cloud SQL Auth Proxy, which authenticates with cloud credentials and presents a local socket. The proxy is the recommended route from outside the VPC, including a developer machine.

What is the difference between Cloud SQL Enterprise and Enterprise Plus?

Enterprise Plus adds a higher availability SLA, near-zero-downtime maintenance, a data cache aimed at read-heavy workloads, and longer log retention. It costs more and behaves differently under maintenance, so it is worth knowing which edition an existing instance uses before interpreting its performance.

Is Cloud SQL locked in?

The data is not — it is standard Postgres and a pg_dump restores anywhere. What does not travel is the surrounding configuration: IAM database authentication, the proxy connection mechanism, flag settings, and any monitoring built on cloud-specific metrics. Keeping connection logic behind a thin abstraction keeps that surface small.

Should I use Cloud SQL if my application is not on Google Cloud?

Usually not. Splitting the application and the database across providers means every query crosses a metered network and pays the latency, which is rarely offset by a better unit price. A managed Postgres on the same private network as your application is the better arrangement, whichever platform that is.