Google Cloud SQL as Your MCP Context Store: Setup Guide

open-context can run its MCP context store on Google Cloud SQL for PostgreSQL: point OPENCONTEXT_DB_URL at a cloudsql://user:password@project:region:instance/database connection string, install two optional packages, and Claude's save_context and recall_context tools read and write straight to your Cloud SQL instance. The official Node.js connector handles TLS and instance routing itself, and if you leave the password out it authenticates with IAM instead — no Cloud SQL Auth Proxy sidecar, no certificate files, and no firewall rule to open.

Why Cloud SQL needs its own connection scheme

Every other SQL backend in open-context — Postgres, MySQL, SQL Server — is addressed by a normal host:port pair, because that's what a TCP connection needs. Cloud SQL instances don't expose a stable hostname in the same way; Google addresses them by instance connection name, a project:region:instance triple. open-context's DSN parser has to read that format by hand rather than with the standard URL parser, specifically because the instance name itself contains colons that would otherwise be misread as a port separator. The result is a connection string shaped like cloudsql://user:password@project:region:instance/database instead of the usual host:port form.

Setting OPENCONTEXT_DB_URL for Cloud SQL

Install the driver and point the environment variable at your instance:

npm i pg @google-cloud/cloud-sql-connector
export OPENCONTEXT_DB_URL="cloudsql://user:password@my-project:us-central1:opencontext-db/opencontext"

Under the hood, createCloudSqlDriver hands that instance connection name to Google's Connector class, which negotiates the connection details — TLS certificates, routing, authentication — and hands back options that go straight into a normal pg.Pool. By default it reaches the instance over its public IP; add ?ipType=private to the connection string to route over a private IP instead, if your Cloud SQL instance and the machine running open-context share a VPC.

Password or IAM — choosing how it authenticates

open-context decides the authentication mode from whether a password is present in the connection string. Include one, and the connector authenticates with that password like any other Postgres connection. Leave it out, and open-context asks the connector to use IAM database authentication instead — the identity already active in the environment (a service account's Application Default Credentials, for example) logs in directly, as long as that identity has IAM database authentication enabled on the instance and a database user mapped to it. That removes a password that would otherwise need to be stored and rotated somewhere, which is the main security reason Google recommends IAM authentication for service-to-database connections in the first place.

What the connector replaces: no more Auth Proxy sidecar

Before Google shipped per-language connectors, the standard way to reach Cloud SQL securely was the Cloud SQL Auth Proxy — a separate binary run as a sidecar process that terminated TLS and forwarded a local socket to the instance. The Node.js connector reached general availability in 2023 and does the same job — TLS 1.3 encryption, identity verification, no certificate files to manage or firewall rules to open — inside the same process as the application, which is why open-context links directly against @google-cloud/cloud-sql-connector instead of shelling out to a separate proxy binary. One fewer process to deploy, monitor, and keep patched.

Everything else behaves like every other backend

Once connected, a Cloud SQL-backed store passes the same roughly 50-test conformance suite as every other adapter: identical ordering (createdAt ascending, then id), identical case-insensitive substring search across content, tags, and source, and the same rule that an unset field like bubbleId comes back undefined, never null. None of the 6 MCP tools can tell they're talking to Cloud SQL instead of self-hosted Postgres or SQLite. Moving existing contexts in follows the same three-command flow as any other backend migration:

# Confirm the connection works before switching to it
opencontext db test "cloudsql://user:password@my-project:us-central1:opencontext-db/opencontext"

# Make it the active store
opencontext db use "cloudsql://user:password@my-project:us-central1:opencontext-db/opencontext"

# Copy everything from wherever you are today
opencontext db migrate --to "cloudsql://user:password@my-project:us-central1:opencontext-db/opencontext"

The migration only reads from the source store and writes to the target, so an interrupted run leaves your existing data untouched and safe to retry.

When Cloud SQL is the right call here

Cloud SQL earns its place among open-context's 15 backends in one specific situation: you're already running workloads on Google Cloud, and standing up a database outside that project means a new piece of infrastructure, a new IAM policy, and a new thing to monitor. If that's not your situation, a simpler option usually wins — sqlite:// needs nothing installed and covers a single machine, and self-hosted Postgres avoids any dependency on a specific cloud provider at all. Cloud SQL's advantage isn't raw performance — the conformance suite guarantees identical read/write behavior across every backend — it's that your context store inherits backups, monitoring, and access control you've probably already set up for everything else running in that project.

FAQ

Does open-context's Cloud SQL support cover MySQL and SQL Server too, or only PostgreSQL?

Only Cloud SQL for PostgreSQL has a dedicated cloudsql:// driver today, addressed by instance connection name and routed through Google's Node.js connector. Cloud SQL for MySQL and Cloud SQL for SQL Server are still reachable through open-context's regular mysql:// or mssql:// connection strings, the same way any other managed MySQL or SQL Server instance is, since those Cloud SQL flavors expose a standard IP endpoint.

What happens if I leave the password out of the cloudsql:// connection string?

open-context switches to IAM database authentication instead of a stored password. The connector authenticates using whatever Google Cloud identity is already active in the environment (a service account or Application Default Credentials), provided that identity has IAM database authentication enabled on the Cloud SQL instance.

Do I need to run the Cloud SQL Auth Proxy alongside open-context?

No. The @google-cloud/cloud-sql-connector package used by open-context's cloudsql:// driver runs in the same Node.js process and handles TLS and instance routing itself, which is what Google now recommends over running the Cloud SQL Auth Proxy as a separate sidecar.

Can open-context reach a Cloud SQL instance that only has a private IP?

Yes. Add ?ipType=private to the cloudsql:// connection string and the connector routes over the instance's private IP instead of its public one. The host running open-context still needs network access to that private IP, typically through a VPC connector or a VM inside the same VPC.

Can I migrate my existing MCP context store into Cloud SQL without losing data?

Yes. opencontext db migrate --to "cloudsql://user:pass@project:region:instance/database" copies every context and bubble from whatever backend you're currently using into Cloud SQL, reading the source store without modifying it, so a failed run is safe to retry.