Skip to main content

Choose how Atlan connects to AlloyDB for PostgreSQL

TL;DR

Compare the three ways Atlan can reach your AlloyDB for PostgreSQL instance - the self-deployed runtime, Private Service Connect, and public IP with authorized networks.

Connect

AlloyDB is Google Cloud's PostgreSQL database - and unlike most databases, it is born private: a new AlloyDB instance gets only a private address inside your Google Cloud network. This page helps you pick the right of three connection paths in about two minutes, before you touch any 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.

FactHow to find it
How your AlloyDB instance is reachable - private IP only (the default), public IP enabled, or Private Service Connect enabledAsk your Google Cloud administrator, or check the instance's Connectivity section in the Google Cloud console. If nobody remembers enabling a public IP, you almost certainly don't have one - AlloyDB never gets one by default.
Which cloud and region your Atlan tenant runs on (AWS, Azure, or GCP)Ask your Atlan admin, or raise a support request and ask: "which cloud and region is my tenant hosted in?" This determines which egress IPs Atlan connects from - and they differ per tenant.

Compare three methods​

Self-deployed runtime (SDR)Private Service Connect (PSC)Public IP + allowlist
Traffic pathA small Atlan-provided service runs inside your network; only outbound HTTPS leaves itGoogle's internal network - traffic never touches the internetPublic internet, TLS-encrypted, from Atlan's tenant-specific egress IPs
AlloyDB change neededNone - works with the default private IPEnable PSC on the instance; create a service attachmentEnable public IP; add Atlan's IPs to authorized networks
Who is involvedYour infrastructure team + youYour cloud/network team + Atlan support + youGoogle Cloud admin + Atlan support (for the IPs) + you
Typical setup time1–3 days (deploy runtime once, reuse for all sources)2–5 business days (includes a handshake with Atlan support)Hours (one support ticket for the IP list)
Auth methodsUsername/password, IAM user, IAM service account, IAM Workload Identity Federation (GKE only)Username/password, IAM user, IAM service accountUsername/password, IAM user, IAM service account
Start hereSDR guidePSC guideAllowlist guide
The #1 first-time setup failure

Entering your instance's private IP (an address like 10.x.x.x or 172.28.0.3) as the Host in Direct extraction mode. A private address is only reachable inside your own network - Atlan's cloud cannot route to it, so the test fails at the network layer and surfaces as app internal error: 500. This is expected behavior, not a bug. If your instance has no public address, use the self-deployed runtime or Private Service Connect.

Which method to pick​

  • Pick the self-deployed runtime if your AlloyDB has private IP only and your security policy prohibits exposing it. This is the most common setup for AlloyDB, works with every auth method, and the same runtime can crawl your other private sources too.
  • Pick Private Service Connect if you want Atlan's SaaS to reach AlloyDB without deploying anything yourself and without any public exposure. Requires a support ticket and coordination - budget a few business days.
  • Pick public IP + allowlist only if your security policy allows an internet-reachable database restricted to known IPs. Fastest path, least common choice for AlloyDB.
Already running a fleet?

Each AlloyDB instance is a separate connection target. If you have many instances across dev/QA/prod projects, the self-deployed runtime scales best: one runtime deployment reaches every instance it can route to, whereas PSC needs one endpoint per instance. See Special cases.

See also​