Google Cloud SQL warehouse sync

Connect a Google Cloud SQL for PostgreSQL database to the managed warehouse. This guide covers Google account access, public and private networking, sync modes, and access removal. For other PostgreSQL deployments, use the PostgreSQL guide.

Guided setup

Choose PostgreSQL → Google Cloud SQL when the database runs in GCP. Enter the Google Cloud project ID, choose a database login method, select Connect Google, then choose the detected PostgreSQL instance and database. Embrasure requests Google's provider-specific cloudsql scope to read instance and database metadata, and userinfo.email to identify the connected account and protect shared grants during cleanup. Choosing Google account also requests sqlservice.login for passwordless database authentication. Choosing a database username and password does not request IAM login or offline access. Google's Cloud SQL consent wording includes management access; Embrasure's Cloud SQL Admin API calls only read metadata and never change the Google project automatically.

Choose the database login and table scope

The first Database login selector chooses Database username and password or Google account before Google authorization. With password authentication, the later Database login selector offers Use existing login or Create a dedicated login.

• Use existing login uses a PostgreSQL role your administrator already created. Enter its username and password. Embrasure does not create a role named embrasure_sync merely because that name is entered.
• Create a dedicated login generates SQL for an administrator to run in the selected database. The role is created when that SQL runs, not by Google consent. Review the generated SQL before running it: it includes grants on all tables in the selected schemas and default privileges for future tables created by the role running the SQL. For a restricted subset, have your administrator prepare a login with named-table grants and choose Use existing login instead.

Select the database containing your application tables, then the relevant schemas. Each selected schema needs USAGE and at least one table with SELECT access; setup does not require access to every table in the schema. Choose the tables to sync on Select data. See restricted table grants for an example and RLS considerations.

Google access and permissions

Google discovery credentials are stored in the encrypted setup session, which expires after 30 minutes. A database-login connection keeps its encrypted PostgreSQL and optional SSH credentials after completion. Unused Google tokens are retained encrypted for revocation retries, then deleted. Passwordless IAM Scheduled sync additionally retains the encrypted Google refresh token needed for ongoing access. See the privacy policy for storage, sharing, and deletion details.

For Google discovery, the account needs cloudsql.instances.list, cloudsql.instances.get, and cloudsql.databases.list on the selected project. Google's Cloud SQL Viewer role includes these read permissions; Cloud SQL Admin or Project Owner is not needed for discovery. An administrator with separate database permissions performs any required PostgreSQL setup.

For passwordless Scheduled sync over a public endpoint, enable cloudsql.iam_authentication on the instance, add the signed-in Google account as an IAM database user, and grant it cloudsql.instances.login through the Cloud SQL Instance User role or an equivalent custom role. Separately grant that database user CONNECT on the selected database, USAGE on the selected schemas, and SELECT on the selected tables. OAuth consent does not create these permissions. See Google's IAM login guide. SSH and Continuous sync use a PostgreSQL login instead.

Choose a network path

Choose Public address for a reachable public database endpoint, or SSH tunnel to keep Cloud SQL private. SSH uses a bastion in a network that can reach the instance’s private IP. You do not need to enable a public database IP or establish a site-to-site VPN for the SSH path.

For SSH, enter the bastion host, port, username, private key, and verified SHA256 host-key fingerprint in the browser. Obtain that fingerprint from the bastion administrator through a trusted channel. Embrasure pins the key and refuses a changed identity. Restrict bastion access to Embrasure’s egress IP and forwarding to the database’s private IP on port 5432. The bastion must allow this forwarding; an SSH login alone does not prove database reachability.

Choose a sync mode

Choose the sync mode before preparing database access:

Cloud SQL PostgreSQL 16 continuous sync uses Embrasure Flow. AWS DMS is not used for SSH sources. Flow is enabled per workspace; an unavailable engine is a setup blocker, and Embrasure does not silently switch a continuous source to Scheduled sync. The AWS source matrix separately lists Cloud SQL’s supported versions.

Flow table preflight checks primary keys, supported column types, replica identity, and publication permissions. DEFAULT is supported for eligible fixed-width replicated columns with a complete primary key; selected variable-width columns require FULL. See replica identity requirements. The login needs permission to create its publication, including the appropriate table ownership or role membership; database read access alone is insufficient. Ask a database administrator to review the specific preflight instructions. Embrasure does not automatically change table ownership, replica identity, or database flags.

Connection verification, replication preflight, and a completed sync are separate checks. Finish all three before relying on replicated data. Private Cloud SQL deployments require assisted qualification of their actual network and source configuration.

Set up through MCP

Use sources with action=types to inspect the workspace’s supported connection methods, then action=connect with kind=postgres. Open the returned browser URL and choose Google Cloud SQL and SSH tunnel. Enter all database and SSH secrets in that browser form, never in chat or MCP arguments.

After setup, inspect sources status, then run ingestion plan. If the engine is omitted, MCP preserves the saved Cloud SQL selection; SSH continuous sources use embrasure_flow. An explicit worker_batch choice means Scheduled sync and does not capture hard deletes. Resolve preflight blockers before ingestion start, then poll ingestion status and verify warehouse rows. A returned connection handle only proves setup was saved.

When you choose Create a dedicated login, the generated SQL is escaped for the selected database and schemas and contains a server-generated password. Run it in SQL Studio, then select Verify and select tables. Do not paste the block into tickets or logs.

Empty discovery or the wrong database

On Select data, check the instance → database → schemas summary and the saved database login. Google access and a successful SSH connection do not prove that this login can read the intended database tables.

Use Edit connection to correct the database, schemas, or password login without reentering saved SSH credentials. Leave the password blank to retain it, then select Verify and discover tables and review the new table selection. Failed verification preserves the saved connection; discovery alone never starts ingestion. If you have already created an ingestion sync, including a paused one, this editor blocks changes and offers Add a separate source instead.

Follow the connection recovery steps for permission errors, concurrent edits, and other limitations. Verify your ingestion run and destination rows before treating setup as successful.

Revoke and remove access

Remove the source in Embrasure to stop future synchronization. Passwordless IAM connections retain encrypted Google refresh credentials for ongoing reads; revoke Embrasure in your Google Account's third-party connections to prevent future token refreshes. That revocation can affect other connections using the same Google account and OAuth project. Existing database sessions may remain active until closed. Embrasure revokes unused Google access through a retryable cleanup process once no source or unexpired setup still depends on the grant. Shared grants remain usable by the other sources. Older grants whose account cannot be identified are retained conservatively while another Google source remains active.

For a PostgreSQL login, revoke its database grants or remove the generated embrasure_… role as a database administrator. Revoking Google access does not disable that separate login. Removing a connector does not automatically delete previously imported warehouse data; use the workspace's deletion controls or contact privacy@embrasure.ai, subject to the retention policy.