Set up Private Service Connect to AlloyDB
Let Atlan's SaaS reach your AlloyDB for PostgreSQL privately over Google's internal network - no public IP, nothing deployed on your side beyond a service attachment.
Let Atlan's SaaS reach your AlloyDB privately over Google's internal network - no public IP, nothing deployed on your side beyond a service attachment. Five phases, including the handshake with Atlan support where most setups stall.
Read How AlloyDB connectivity works first. The socket (service attachment) and plug (consumer endpoint) model below is introduced there.
Unlike the other two paths, PSC to AlloyDB is currently not self-serve - Atlan's network team builds the consumer endpoint and DNS mapping for you. Every step below owned by Atlan support happens on your support ticket. Budget 2–5 business days end to end.
Prerequisites
- An AlloyDB instance with Private Service Connect enabled. PSC is chosen at instance level; your cloud team may need to create or update the instance with PSC connectivity.
- Someone with permissions to manage the AlloyDB instance and PSC settings in your Google Cloud project.
- A hostname you want Atlan to use for this database (e.g.
alloydb-prod.example-corp.internal) - optional but strongly recommended, see Phase 2.
Five phases at glance
| Phase | What happens | Owner | Typical time |
|---|---|---|---|
| 1. Expose | Enable PSC on the instance; get the Service Attachment URL | Your cloud/network team | 1–2 hours |
| 2. Request | Open a support ticket with the exact attachment URL + desired hostname | Atlan User | 15 minutes |
| 3. Build | Atlan creates the consumer endpoint and maps the hostname | Atlan support | 1–2 business days |
| 4. Accept & verify wiring | Confirm the endpoint shows Accepted on your service attachment | Your cloud/network team | 15 minutes |
| 5. Connect & verify | Point the Atlan crawler at the hostname; test | Atlan User | 30 minutes |
Phase 1 - Expose instance over PSC
Owner: Your cloud/network team
Enable Private Service Connect on the AlloyDB instance and copy the Service Attachment URL from the instance's connectivity details. It looks like:
projects/<google-managed-project>/regions/<region>/serviceAttachments/<attachment-name>
# e.g. projects/x1234example-tp/regions/europe-west1/serviceAttachments/alloydb-abc123-example-sa
The service attachment URL is not the instance URI. Setups stall when the instance path (projects/…/locations/…/clusters/…/instances/…) is shared instead of the attachment path (projects/…/regions/…/serviceAttachments/…). If your URL contains /locations/ and /clusters/, it's the wrong one - Atlan cannot build an endpoint against it, and you lose a full round-trip finding out.
Phase 2 - Raise support request
Owner: Atlan User
Open a support request from within Atlan containing:
- Your Atlan tenant URL
- The exact Service Attachment URL from Phase 1 (copy-paste, don't retype)
- The hostname you want mapped (e.g.
alloydb-prod.example-corp.internal). If you skip this, Atlan will ask - providing it up front saves a day. A stable hostname means you never reconfigure the crawler if the underlying endpoint IP changes. - The AlloyDB region, and whether you'll authenticate with a password or IAM
Phase 3 - Atlan builds consumer endpoint
Owner: Atlan support
Atlan's team creates a PSC consumer endpoint in the tenant's network targeting your service attachment, assigns it a private IP, and maps your hostname to that IP. Here's the full lifecycle:
- Requested - you share the attachment URL (Phase 2)
- Pending - endpoint created, awaiting acceptance by your attachment
- Accepted - traffic can flow over the private path
- Usable - hostname resolves; proceed to Phase 5
Support replies on the ticket with confirmation and the hostname to use in the crawler.
Phase 4 - Accept and verify wiring
Owner: Your cloud/network team
- If your service attachment uses an accept list (rather than auto-accept), add the consumer project Atlan names on the ticket, then confirm the connection shows Accepted in the attachment's Connected endpoints.
- A second failure mode here: the endpoint exists but the hostname was mapped to the wrong IP on Atlan's side. If the test in Phase 5 times out even though the endpoint is Accepted, ask on the ticket: "please re-verify the DNS mapping for our hostname against the endpoint IP".
Phase 5 - Connect and verify
Owner: Atlan User
- In New workflow → AlloyDB Assets, keep Direct extraction selected.
- Enter the hostname from Phase 3 as Host (not the private IP, not the public URL), port
5432. - Enter credentials and click Test connection.
Success checklist
- Endpoint shows Accepted on your service attachment
- Test connection passes using the mapped hostname
- Preflight checks pass
- A full crawl completes
A PSC endpoint targets exactly one service attachment, which targets one AlloyDB instance. Connecting several instances means repeating Phases 1–5 per instance - put them all in one ticket, clearly labeled. See Special cases.
Next steps
Crawl AlloyDB for PostgreSQL: Configure and run the crawler to extract metadata from AlloyDB