PostgreSQL sslmode Values Compared: Which One Should You Use?

PostgreSQL connection strings often hide an important security decision inside one small parameter: sslmode. The difference between require, verify-ca, and verify-full determines whether the client merely encrypts traffic, validates the server certificate chain, or also checks that the certificate belongs to the host it meant to reach.

For production applications, the practical answer is usually verify-full when the client can be configured with the right root certificate. require is better than plaintext on untrusted networks, but it does not provide the same protection against connecting to the wrong endpoint. The right setting depends on the client library, certificate distribution model, and whether you operate the PostgreSQL server yourself or consume a managed PostgreSQL service.

Why sslmode matters

TLS for PostgreSQL has two jobs. The first is encryption, which prevents passive observers from reading queries, credentials, and result data in transit. The second is authentication of the server, which helps the client prove it is talking to the intended database endpoint rather than a machine that can intercept traffic.

Those two jobs are related but not identical. A connection can be encrypted and still fail to verify the identity of the server. That is the main trap with sslmode=require: it requests an encrypted connection, but the official PostgreSQL libpq documentation describes its man-in-the-middle protection as absent unless older compatibility behavior with a local root certificate file happens to apply. Applications that need certificate validation should choose verify-ca or verify-full explicitly.

This matters most when database credentials cross networks you do not fully control: developer laptops on hotel Wi-Fi, application workloads in cloud networks, CI runners, customer-managed deployments, and any service-to-service connection that leaves a single trusted host. Managed PostgreSQL reduces certificate and server maintenance, but the client still has to select the validation behavior.

The sslmode comparison

The PostgreSQL client modes form a ladder from no TLS to full identity verification. The names are compact, but the operational differences are large.

The table is intentionally conservative. PostgreSQL documents a backward-compatibility behavior where require can behave like verify-ca if a root CA file exists in the expected client location. Relying on that implicit behavior makes reviews harder and can produce different results between laptops, containers, and CI images. If the goal is validation, say so in the connection string.

Choosing a production setting

Use verify-full when the application connects by a stable DNS name and you can provide the trusted root certificate bundle used to validate the server certificate. This gives the client both parts of the safety contract: it encrypts the session and verifies that the certificate chain is trusted and that the certificate name matches the hostname in the connection.

Use verify-ca only when hostname matching is intentionally not part of the design. That can happen in controlled private environments where certificates are issued by an internal CA but hostnames are abstracted, pinned elsewhere, or not stable. Even then, document the reason. verify-ca proves the server has a certificate from a trusted CA, but it does not prove the certificate name matches the host parameter.

Use require as a compatibility step, not as the final state for sensitive production systems. It is useful when you need to force encryption quickly and cannot yet distribute CA files. The migration path should be to add the root certificate, confirm driver support, and move to verify-full.

Avoid disable, allow, and prefer for production application traffic unless you have a narrow, documented exception. The convenience of automatic fallback can become a security ambiguity: during an incident or network change, it is harder to prove which sessions were encrypted and which were not.

Managed PostgreSQL vs self-hosted PostgreSQL

The biggest difference is who owns the server-side certificate lifecycle. With managed PostgreSQL, the provider usually provisions server certificates, publishes the root certificate or expected trust path, and gives customers a hostname that should match the certificate. The application still has to use the right sslmode, store CA material in the deployment environment, and avoid replacing hostnames with raw IP addresses that cannot match the certificate.

With self-hosted PostgreSQL, the team must configure server TLS, protect the private key, renew certificates before expiry, set ssl = on, and write pg_hba.conf entries that require TLS where appropriate. PostgreSQL uses hostssl records in pg_hba.conf to match TCP/IP connections made with SSL. If a self-hosted server has both host and hostssl rules, the order and specificity of those rules matter during authentication.

ArmorDB users should follow the connection details shown in the dashboard and keep environment-specific connection strings separate. If your application also uses PgBouncer, validate the TLS behavior on the exact endpoint the app uses, not only on a direct database endpoint.

A practical rollout plan

Start by inventorying connection strings. Search application secrets, CI variables, background workers, migration tools, BI tools, and local development templates. The goal is to find every place that sets sslmode or implicitly relies on a driver default. Defaults vary across tools and wrappers, so an explicit production connection string is easier to audit.

Next, add the trusted root certificate to the runtime environment. In containerized deployments, mount it as a secret or bake it into a minimal trusted bundle through your normal image process. In serverless and CI systems, use the platform secret store rather than committing certificate material into source control. Root CA files are public trust anchors rather than passwords, but treating them as managed configuration prevents accidental drift and unclear provenance.

Then test verify-full from the same environment that runs the application. A laptop test is useful, but it does not prove the production image has the right file path, environment variables, or DNS behavior. If the connection fails with a hostname mismatch, fix the hostname or certificate path rather than downgrading to require. Hostname mismatches are exactly the class of problem verify-full is designed to catch.

Finally, make the setting part of release review. Migrations, one-off scripts, and analytics exports often use separate connection strings from the main app. If those paths keep sslmode=require after the web service moves to verify-full, the security posture is uneven and harder to explain.

Common mistakes

One common mistake is connecting with an IP address while expecting verify-full to pass against a certificate issued for a DNS name. Use the hostname given by the provider or issue certificates with names that match the way clients connect.

Another mistake is assuming TLS replaces database authentication. sslmode controls transport encryption and server validation. Password, SCRAM, certificate authentication, IAM-style tokens, or other authentication methods still decide who may log in. On self-hosted servers, pg_hba.conf can combine hostssl with normal authentication methods and, when needed, client certificate verification.

A third mistake is solving a broken certificate rollout by weakening sslmode permanently. During an emergency, a temporary rollback may be necessary to restore service, but the post-incident fix should address certificate distribution, DNS, or renewal automation. Otherwise the application silently keeps a weaker identity guarantee long after the incident is over.

Takeaway

For most production PostgreSQL applications, choose sslmode=verify-full, connect by the provider or service DNS name, and distribute the trusted root certificate through normal deployment configuration. require is an encryption setting, not a full server identity check. verify-ca is useful in narrower controlled environments, but verify-full is the setting that best matches the way teams usually expect TLS to work.

If you are planning a new managed PostgreSQL deployment, treat TLS validation as part of the launch checklist alongside backups, pooling, and connection limits. ArmorDB keeps PostgreSQL setup simple, and the same discipline still applies: make the secure path explicit so every app, migration job, and worker connects the same way.

Sources and further reading

• PostgreSQL documentation: SSL support in libpq
• PostgreSQL documentation: secure TCP/IP connections with SSL
• PostgreSQL documentation: the pg_hba.conf file
• PostgreSQL documentation: connection settings and ssl
• ArmorDB docs: connect to your database