Choose how Atlan connects to PostgreSQL
Compare the three ways Atlan can reach your PostgreSQL database - internet with IP allowlisting, private connectivity, or a self-deployed agent - and pick the right one before touching any firewall.
There are three ways for Atlan to reach your PostgreSQL database - over the internet with an IP allowlist, over a private link, or with a self-deployed agent inside your own network. This page helps you pick the right one before you touch any firewall or 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.
| Fact | How to find it |
|---|---|
| Which cloud and region your Atlan tenant runs on (AWS, Azure, or GCP) | In Atlan, go to Admin Center → Overview. If you can't see it, ask your Atlan admin or raise a support request - say "which cloud and region is my tenant hosted in?" |
| Where your PostgreSQL runs - AWS RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or a server you manage yourself (on-premises or in a VM) | Ask whoever administers the database. The answer decides which network options apply, and whether IAM authentication is possible (AWS RDS/Aurora only). |
Compare three methods
| Internet + IP allowlisting | AWS PrivateLink | Self-deployed agent | |
|---|---|---|---|
| Traffic path | Public internet, TLS-encrypted, from Atlan's fixed egress IPs to your database's public endpoint | Never leaves AWS's private network - Atlan plugs into an endpoint service you build in front of your database | Extraction runs inside your own network; only results travel out, over HTTPS that you initiate |
| Your database must be | Reachable from the internet on its port (default 5432) | In an AWS VPC (RDS, Aurora, or self-managed on EC2) | Reachable from wherever you run the agent - works for fully private and on-premises databases |
| Who is involved | You + your database admin | You + database admin + your cloud/network team + Atlan support | Your infrastructure team |
| IAM authentication (RDS/Aurora) | Supported | Supported - with extra care, see the guide | Depends on agent deployment |
| Start here | Connect over the internet | AWS PrivateLink guide | Self-deployed runtime docs |
The Crawl PostgreSQL page describes two extraction methods: Direct (Atlan SaaS connects directly to your PostgreSQL database) and Agent (a Self-Deployed Runtime that runs within your organization and keeps connections inside your network perimeter). Both internet and private-link connectivity on this page are variants of the Direct method.
Private connectivity by cloud
"PrivateLink" is an AWS product name - each cloud has its own private path, and Atlan's support for them differs:
| Your database runs on | Private option | Guide |
|---|---|---|
| AWS RDS / Aurora | AWS PrivateLink - full self-serve build | Set up AWS PrivateLink to PostgreSQL |
| Azure Database for PostgreSQL | VNet peering, arranged with Atlan support | Set up Azure private connectivity |
| Google Cloud (Cloud SQL, AlloyDB, or self-managed) | Private Service Connect via the Cloud SQL / AlloyDB connectors; self-deployed agent otherwise | Set up GCP private connectivity |
Which method to pick
- Pick internet + IP allowlisting if your database already has (or is allowed to have) a public endpoint and your security policy accepts TLS traffic from known fixed IPs. It's the fastest path.
- Pick AWS PrivateLink if your RDS/Aurora database is private-only, or your policy prohibits any public database endpoint. Budget for the handshake with Atlan support and involve your cloud/network team early - you will build a load balancer and an endpoint service.
- Pick the self-deployed agent if the database is on-premises or reachable only inside your network and a private link isn't an option (non-AWS private networks, strict no-inbound policies).
PostgreSQL is unusual among data sources: even after your cloud firewall lets Atlan in, PostgreSQL runs its own access-control file, pg_hba.conf, which can still reject the connection - most often because it requires SSL and the connection didn't offer it. This double gate is the single most common cause of "authentication failed" support requests. It's explained in How database connectivity works and configured in Firewalls, pg_hba.conf, and SSL.
See also
- How database connectivity works - the 5-minute explainer, no cloud or networking knowledge assumed. Read this if
pg_hba.conf,sslmode, or "endpoint service" are new terms. - Atlan Network Details - where Atlan's connections come from, which values to allowlist, and how to get your tenant-specific IPs.
- Connect over the internet - five phases, each labeled with who performs it.
- AWS PrivateLink guide - the full build-and-accept handshake for RDS and Aurora, including IAM authentication and multi-database setups.
- Firewalls, pg_hba.conf, and SSL - the reference for what to allowlist where, and keeping SSL consistent end to end.
- Special cases - on-premises servers, many databases behind one endpoint, Aurora failovers, cross-region IAM, and VPC Lattice.