Managed PostgreSQL on Supabase, Neon, Amazon RDS, or Google Cloud SQL expects encrypted connections. Local Postgres in Docker often runs without TLS, so the first cloud connection is where many developers hit password OK but connection failed errors. Understanding SSL modes saves time and avoids the unsafe habit of turning verification off in production.

SSL modes in plain language

disable: no encryption. Fine for trusted local dev only.
require: encrypt traffic; verify server certificate when the client supports it.
verify-ca / verify-full: stricter chain and hostname checks (common in CLI flags).

Desktop clients usually expose a simpler toggle: SSL off or SSL required. PgNative maps require to encrypted connections with certificate verification for PostgreSQL, which matches what most cloud providers document in their connection strings.

Typical connection fields for cloud hosts

Regardless of provider, you need host, port, database name, user, and password. Providers also publish a connection URI:

postgresql://USER:PASSWORD@HOST:5432/DATABASE?sslmode=require

Translate that URI into your GUI: host is everything after @ and before the port, user and password are in the authority section, and sslmode=require means enable SSL in the client. Pooler endpoints (Supabase pooler, Neon pooled host) use the same TLS rules as direct connections.

Supabase and Neon specifics

Supabase exposes a direct and a pooled connection string from the dashboard. Use the database password you set at project creation (or rotate in settings). If connection fails from a corporate network, check whether outbound 5432 is allowed; some teams use VPN or SSH tunnels instead.

Neon provides a hostname per branch. Branches are useful for preview environments: point PgNative at the branch connection string while a PR is open, then delete the branch when merged. Always enable SSL for Neon hosts; their platform rejects plaintext.

RDS and Cloud SQL

AWS RDS often sits in a private VPC. Developers connect through VPN, bastion, or IAM-aware proxies. SSL is still required for compliance even on private networks. Download the RDS CA bundle when your organization mandates custom trust stores; many GUIs rely on the system trust store, which already includes major CAs.

Google Cloud SQL can use the Cloud SQL Auth proxy for local dev. The proxy speaks TLS to Google; your client connects to localhost. In PgNative you would save localhost as host with the proxy port while the proxy runs in a terminal.

Debugging failed connections

Confirm the database allows your IP (provider firewall or security group).
Verify username includes tenant prefix if the provider requires it.
Check whether you must use pooled vs direct hostname for your workload.
Retry with SSL required after a plaintext attempt failed.
Read the exact error: certificate verify failed points to TLS trust, not password.

Using PgNative for cloud Postgres

Save each environment as a separate connection with a clear name (prod-readonly, staging, local-docker). Enable SSL for every cloud entry. Passwords are stored encrypted on disk with AES-256-GCM so you are not keeping secrets in plain text notes. For more on credential storage, see storing database credentials safely. After connecting, run SELECT version(); and SELECT current_database(); to confirm you landed in the right place before destructive SQL.

How to Connect to PostgreSQL with SSL (Supabase, Neon, RDS)