Special cases
AlloyDB for PostgreSQL special cases - fleets of instances, very large databases, cross-cloud tenants, and connection paths that rewrite the port.
Fleets of instances, very large databases, cross-cloud tenants, and connection paths that rewrite the port.
Many instances across dev / QA / prod projects
Each AlloyDB instance is a separate connection in Atlan, with its own host, credentials, and crawler. Real deployments run 10+ instances across environment tiers. What scales:
- Self-deployed runtime: one runtime (per routable network) covers every instance - the marginal cost of instance #11 is one more crawler config.
- PSC: one endpoint per instance. Batch all Service Attachment URLs into one support ticket, clearly labeled per instance, and propose a hostname scheme (e.g.
alloydb-<env>-<nn>.example-corp.internal). - Naming: connection names become part of asset addresses. Agree a convention before crawling - renaming later means re-crawling.
Very large instances (millions of assets)
AlloyDB fleets with 3–5 million+ assets produce a distinct class of issues: the crawl connects fine but runs many hours or fails at the publish step (writing assets into Atlan), sometimes affecting other running workflows. If your instance is at this scale:
- Start with a crawl scoped to one schema to validate connectivity and permissions cheaply.
- Use include/exclude filters and the "exclude regex for tables & views" option to keep partition-heavy schemas manageable.
- Tell support before the first full crawl - publish throughput can be tuned for the initial load.
- A long-running or publish-failing workflow after a successful test connection is not a connectivity problem - don't spend time on firewalls; see Troubleshooting AlloyDB connectivity.
Atlan tenant on AWS or Azure, AlloyDB on Google Cloud
Fully supported and common. Two things change:
- The egress IPs you allowlist are those of your tenant's hosting cloud (e.g. an Azure region's addresses), not Google addresses. Get them from support with your tenant URL.
- If you migrated a database from another cloud (e.g. RDS → AlloyDB) and previously used a private link, that link does not carry over - the private path must be rebuilt for GCP (PSC) or replaced by the runtime. Update the existing connection's credentials and host rather than creating a new connection, so asset history is preserved.
Load balancers, proxies, and non-default ports with IAM auth
If traffic reaches the database through a load balancer or proxy that listens on a different port than the database (e.g. LB port 5433 → database 5432), password auth works but IAM auth can fail: the short-lived IAM token is signed for the port you configured, and the database rejects a token signed for the wrong port.
- Symptom:
FATAL: PAM authentication failedor auth errors only on the connections that go through the port-rewriting hop. - Fix: use the advanced/auth port option so the token is signed for the database's real port - or mention the topology on a support ticket.
Which IAM options exist where
| Auth method | Direct | Self-deployed runtime | Notes |
|---|---|---|---|
| Username / password (built-in) | ✓ | ✓ | Simplest; credentials in Atlan (encrypted) or your vault (SDR) |
| IAM user | ✓ | ✓ | Uses a short-lived access token (~1 h) - fine for one-off testing, wrong for schedules |
| IAM service account | ✓ | ✓ | Service-account key; recommended for scheduled crawls |
| IAM Workload Identity Federation | ✗ | ✓ (GKE only) | No stored key at all; requires the runtime on GKE |
See Crawl AlloyDB for PostgreSQL for the full crawler configuration. Note the IAM options are not AWS-only - the matrix above is for AlloyDB on Google Cloud.