## Set up Azure private connectivity to PostgreSQL

URL: https://docs.atlan.com/apps/connectors/database/postgresql/how-tos/set-up-azure-private-connectivity-to-postgresql

> 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.

Private connectivity from Atlan to Azure Database for PostgreSQL is a **support-assisted setup**, not a self-serve build like [AWS PrivateLink](https://docs.atlan.com/llms/connectors/postgresql/set-up-a-private-network-link-to-postgresql/llms.txt). 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.

:::info No public endpoint needed at all?

If your policy simply prohibits inbound connectivity, the [self-deployed agent](https://docs.atlan.com/llms/platform/self-deployed-runtime/configure-workflow-execution/llms.txt) 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](https://docs.atlan.com/support/submit-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.

:::danger 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](https://docs.atlan.com/llms/connectors/postgresql/connect-over-the-internet-with-ip-allowlisting/llms.txt).
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](https://docs.atlan.com/llms/connectors/postgresql/firewalls-pg-hba-conf-and-ssl/llms.txt).
4. **Connect and verify** in Atlan - Host, Port, Database, credentials, then **Test connection** and preflight checks.

:::caution 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](https://docs.atlan.com/llms/connectors/postgresql/troubleshooting-postgresql-connectivity/llms.txt).

---