Choose how Atlan connects to Cloud SQL for PostgreSQL
Compare the three ways Atlan can reach your Cloud SQL for PostgreSQL instance - public IP with authorized networks, the self-deployed runtime, and Private Service Connect.
There are three ways for Atlan to reach your Cloud SQL instance. This page helps you pick the right one in about two minutes - before you touch any Google Cloud configuration.
Before you start: Two facts you need
Every path below depends on knowing these. Gather them first - they determine which options are even available to you.
| Fact | How to find it |
|---|---|
| Does your Cloud SQL instance have a public IP, a private IP, or both? | In the Google Cloud console: SQL → your instance → Connections → Networking. "Public IP" and "Private IP" each show enabled or disabled. If only "Private IP" is enabled, Atlan cannot reach the instance directly from the internet - that fact alone decides your path. |
| Which cloud and region your Atlan tenant runs on (AWS, Azure, or GCP) | Ask your Atlan admin or raise a support request - say "which cloud and region is my tenant hosted in?" This determines which Atlan IPs you allowlist, and whether Private Service Connect is even possible. |
On the same Connections page, check whether "Allow only SSL connections" (or "Require trusted client certificates") is turned on. If your instance requires SSL, you must enable SSL in the Atlan connection too - otherwise the very first connection attempt is rejected before your password is even checked. This mismatch is a recurring cause of confusing "authentication failed" reports.
Compare three methods
| Public IP + authorized networks | Self-deployed runtime (private IP) | Private Service Connect | |
|---|---|---|---|
| Traffic path | Public internet, TLS-encrypted, from Atlan's fixed source IPs to your instance's public IP | An Atlan-provided agent runs inside your network; only outbound HTTPS (port 443) leaves your network | Google's internal network - traffic never touches the internet |
| Instance requirement | Public IP enabled | Private IP is enough - no public exposure needed | PSC enabled on the instance (or a service attachment in front of it) |
| Who is involved | You + your Google Cloud admin | You + your infrastructure team | You + your Google Cloud admin + your network team + Atlan support |
| Typical setup time | Under an hour | Days (agent install + secret store) | 2–5 business days (includes an approval handshake) |
| Available when your Atlan tenant is on | AWS, Azure, or GCP | Any | GCP-hosted Atlan tenants only - set up with Atlan support |
| Start here | Public IP guide | Self-deployed runtime guide | Private Service Connect guide |
Entering your instance's private IP (e.g. 172.28.0.3 or 10.x.x.x) as the Host in Direct mode. A private IP is only reachable inside your own Google Cloud network - Atlan's cloud cannot route to it, so the test fails at the network layer and surfaces as a generic app internal error: 500. If your instance is private-IP-only, use the self-deployed runtime (or Private Service Connect) - no amount of credential fixing will make Direct mode work.
Which method to pick
- Pick public IP + authorized networks if your instance has (or is allowed to have) a public IP and your security policy accepts TLS traffic over the internet from known Atlan IPs. It's the fastest path and fully self-serve for GCP-hosted tenants.
- Pick the self-deployed runtime if your instance is private-IP-only and must stay that way. Most customers in this situation choose this option - connectivity stays inside your VPC and credentials never leave your network.
- Pick Private Service Connect if your Atlan tenant is hosted on GCP, your organization prohibits any public path, and you don't want to run an agent. It's set up with Atlan support - budget for the connection-approval handshake.
Private Service Connect only works when both ends are in Google Cloud. If your Atlan tenant runs on AWS or Azure, your private options are the self-deployed runtime or a cross-cloud design built with Atlan support - see Special cases.
See also
- How Cloud SQL connectivity works: The 5-minute explainer - no cloud knowledge assumed. Read this if "authorized network" or "service attachment" are new terms.
- Atlan Network Details: The published Atlan IPs to allowlist, by cloud and region - plus what to ask support for.
- Connect over public IP with authorized networks: Four phases: enable public IP, allowlist Atlan, set SSL, connect and verify.
- Troubleshooting Cloud SQL for PostgreSQL connectivity: Real error messages mapped to causes and fixes.