Skip to main content

Set up Azure private connectivity to PostgreSQL

TL;DR

Private connectivity from Atlan to Azure Database for PostgreSQL is a support-assisted VNet peering setup - what to ask for, what you configure yourself, and the caveats to insist on before signing off.

Connect

Private connectivity from Atlan to Azure Database for PostgreSQL is a support-assisted setup, not a self-serve build like AWS PrivateLink. Atlan tenants on Azure have used VNet peering arrangements set up with Atlan support. This page tells you what to ask for, what stays yours to configure, and the caveats to insist on before signing off.

No public endpoint needed at all?

If your policy simply prohibits inbound connectivity, the self-deployed agent avoids private networking entirely - it runs inside your network and makes only outbound HTTPS calls to Atlan.

Prerequisites​

  • Your Atlan tenant is hosted on Azure - private peering requires both ends in the same cloud. Confirm via Admin Center → Overview or with support.
  • The VNet and region of your Azure Database for PostgreSQL (flexible or single server), and its port (default 5432).
  • Someone who can approve/configure peering on your side (cloud/network team), and a Postgres admin for users and grants.

What to put in support ticket​

Raise a support request from within Atlan with:

  • Your tenant URL.
  • Your database's hostname (not its IP - see the caution below), VNet, region, and port.
  • A request for private connectivity to an Azure-hosted PostgreSQL source, and a question up front: "How does this setup behave after a database restart?"

Atlan support designs and builds the Atlan-side peering; they'll tell you what to approve or configure on your side.

Insist on hostname-based configuration

Peering configured against fixed IP addresses breaks every time the database restarts and gets a new IP - in past setups, each restart needed a new support ticket to update the peering. Ask for hostname-based configuration wherever possible, and test a restart before you sign off on the setup.

What stays yours to configure​

The database-side gates apply exactly as on every other path:

  1. Service user and grants - as in Phase 1 of the internet guide.
  2. Firewall / NSG rules - allow the peered ranges support gives you to reach the database port.
  3. SSL - Azure Database for PostgreSQL commonly enforces SSL (require_secure_transport). The Atlan connection's SSL mode must be require or stricter - see Firewalls, pg_hba.conf, and SSL.
  4. Connect and verify in Atlan - Host, Port, Database, credentials, then Test connection and preflight checks.
Authentication on Azure

Azure Service Principal authentication is not supported for PostgreSQL connections - IAM-style auth is AWS-only (access keys / role ARN). Use Basic auth (username/password) for Azure-hosted PostgreSQL.

Success checklist​

  • Support confirms the peering is live and hostname-based
  • Test connection passes in the Atlan UI
  • Preflight checks pass, and a small-scope crawl completes
  • A crawl still completes after a database restart (the real test of the peering configuration)

Any step failing - see Troubleshooting PostgreSQL connectivity.