Google SQL: What Cloud SQL Is, How You Connect to It, and Who It Is For

Google SQL almost always means Cloud SQL, the managed relational database service on Google Cloud that runs MySQL, PostgreSQL and SQL Server on instances Google provisions, patches, backs up and replicates for you. It is not a Google-flavoured dialect of SQL; the query language is whatever engine you picked. What you get over running the same database on a virtual machine is that the operational work disappears and the database gains private networking, automated backups with point-in-time recovery, and a high-availability option. What you pay for is that convenience at hyperscaler pricing, plus the connection setup, which is the part that trips up most first-time users.

There are two other things the phrase can mean, and it is worth dismissing them first: BigQuery, which is a data warehouse with a SQL interface and not a transactional database, and the SQL you write in Sheets or Looker, which is a query feature. If you are hosting an application, Cloud SQL is the one you are looking at.

Table of contents

• What Cloud SQL manages, and what it leaves to you
• Choosing an engine on it
• Connecting: the part that takes the afternoon
• The cost shape
• Who Cloud SQL is for, and who it is not
• How this fits the rest of the stack
• FAQ

What Cloud SQL manages, and what it leaves to you

The service takes an engine you already know and wraps the parts nobody enjoys.

• Provisioning. Pick an engine, a version, a machine size and a region; an instance exists within a few minutes.
• Patching. Minor version updates and OS patches are applied in a maintenance window you choose.
• Backups. Automated daily backups plus transaction logs, which enable restoring to a point in time rather than only to the last snapshot.
• Replication and failover. A high-availability configuration keeps a standby in another zone and fails over automatically.
• Storage growth. Disk can grow automatically as data grows, which prevents the classic out-of-space outage.

What stays yours: the schema, the users and their grants, the queries and their indexes, the connection pool sizing, and the decision about how large an instance to run. A managed database does not make a slow query fast. It makes sure the slow query runs on a machine that is patched and backed up.

Choosing an engine on it

Cloud SQL offers three engines and the choice is rarely about the platform.

• PostgreSQL if you are starting fresh. Stricter typing, richer indexing, JSON support that is genuinely good, and the engine most modern frameworks and ORMs default to.
• MySQL if the application already speaks it, which describes most CMS and e-commerce software. It is a fine engine and moving away from it for its own sake is not worth the migration.
• SQL Server if you have a .NET application written against T-SQL and stored procedures. It costs more because the licence is included in the hourly rate, and that surcharge is the main reason teams migrate to Postgres when the application allows it.

Whichever engine you pick, the version matters more than people expect: choose the newest major version the application supports, because upgrading a live database later is a project.

Connecting: the part that takes the afternoon

A Cloud SQL instance can have a public IP, a private IP inside your VPC, or both, and none of them accept a plain connection from an arbitrary address. There are three sane ways in.

1. Private IP from inside the same VPC. The application runs on Google Cloud, in the same network, and connects to the instance’s private address directly. Fast, no exposure, and the right answer for anything running there.
2. The Cloud SQL Auth Proxy. A small binary that runs beside your application, authenticates with a service account, and exposes a local port that tunnels to the instance over TLS. It works from anywhere, including a laptop or a server outside Google Cloud, and it means you never manage certificates or IP allowlists.
3. Public IP with an authorised network. Allow a specific address range and connect with TLS. Acceptable for a fixed office IP; wrong for a service whose egress address changes.

# Cloud SQL Auth Proxy: local port 5432 tunnels to the instance
./cloud-sql-proxy my-project:europe-west1:my-instance --port 5432 &

# then connect as if it were local
psql "host=127.0.0.1 port=5432 dbname=app user=app sslmode=disable"

The proxy is the path most tutorials skip and the one that avoids most support tickets. If the application runs somewhere other than Google Cloud, use it, or accept that you are managing an allowlist of every egress IP your hosting provider might use.

The cost shape

Cloud SQL bills per hour for the instance size, per gigabyte-month for storage and backups, and per gigabyte for egress, with high availability roughly doubling the instance line because the standby is a full machine. Prices vary by region and change, so the point is the shape rather than a figure: the instance runs and bills whether or not queries arrive, and the cheapest shared-core instances are meant for development, not for production traffic.

The two lines that surprise people are egress and the standby. Egress matters when the application runs outside Google Cloud, because every query result leaving the region is metered. The standby matters because a production database without high availability is a single point of failure, and adding it later means accepting the doubled cost you were avoiding.

Who Cloud SQL is for, and who it is not

It is the right choice when the application already runs on Google Cloud. Private IP networking, IAM-based authentication, and integration with the rest of the platform’s tooling are real advantages that only exist inside that ecosystem. It is also the right choice when you need SQL Server as a managed service, because few other providers offer it.

It is a heavy choice for an application that runs elsewhere, because you pay for egress, wrestle with the proxy, and gain none of the in-platform integration. And it is an expensive choice for a small project, because the production-grade configuration with high availability and a reasonable machine size costs more per month than the application it serves. For a Postgres or MySQL database behind a small service, a managed instance from the same provider that hosts the service, with backups, connection limits and private networking already in place, does the same job with one fewer network boundary and a price you can read off a plan table.

How this fits the rest of the stack

The database is rarely the only line on the bill, and its price only makes sense next to the service that queries it and the bandwidth between them. The RunxBuild hosting calculator shows a managed Postgres or MySQL instance beside the service plan, with connection limits and backups as part of the plan rather than as separate lines, so the comparison with a hyperscaler estimate is one screen rather than a spreadsheet.

Useful related references:

• Google Cloud Postgres: What Cloud SQL Gives You, Explained Neutrally
• Kill All Connections to a SQL Server Database (Safely)
• Google MX Records: Setting Up Workspace Mail on Your Own Domain
• Services on RunxBuild

FAQ

What is Google SQL?

In hosting contexts it means Cloud SQL, the managed relational database service on Google Cloud. It runs standard MySQL, PostgreSQL or SQL Server and handles provisioning, patching, backups, replication and storage growth. It is not a separate SQL dialect.

Is Cloud SQL the same as BigQuery?

No. Cloud SQL is a transactional database for applications, running MySQL, Postgres or SQL Server. BigQuery is an analytics warehouse that uses SQL syntax for large scans over columnar data. Applications read and write Cloud SQL; analysts query BigQuery.

How do I connect an application to Cloud SQL?

From inside the same VPC, use the instance’s private IP. From anywhere else, run the Cloud SQL Auth Proxy beside the application and connect to the local port it exposes. Public IP with an authorised network works only for a fixed source address.

Which engine should I pick on Cloud SQL?

Postgres for a new application, MySQL if the software already uses it, SQL Server only if you have a .NET application tied to T-SQL. SQL Server costs more because licensing is included in the hourly rate.

Is Cloud SQL worth it for a small project?

Only if the application already runs on Google Cloud. For a small service hosted elsewhere, the egress charges, proxy setup and high-availability cost outweigh the benefits, and a managed Postgres or MySQL instance from the same provider as the service is simpler and cheaper.