TLS, Network Entry and SQL Privileges Answer Different Questions
Encrypting a connection, admitting a source and granting a table are three decisions. Walk them in order before asking whether TLS can replace a VPN.
Somebody proposes handing a customer a PostgreSQL login so that an expense claim travels encrypted end to end. A database administrator needs a real SQL session, and somebody else proposes a web form instead. Both proposals solve the wrong problem, because neither started from the operation the client actually performs. Walk the three decisions in order and the question about TLS replacing a VPN answers itself.
Start from the operation the client needs
Write down what the client must accomplish. Submitting a claim, reading one row of a report and running an ad-hoc query are three different operations with three different risk profiles.
Then write down who is making the request. A customer, a support agent and an administrator are not interchangeable even when they touch the same table. The difference decides how much of the query language the client should ever see.
The pair of answers decides the interface. Everything after that is implementation, and most arguments about encryption are really arguments about which interface was chosen.
Three controls, three decisions
Authenticated TLS protects the connection and decides which TLS identities are accepted. Network entry decides which sources may reach the listener at all. Database authorization decides which objects and actions a role may use.
None of the three substitutes for the others, which the table makes explicit.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Read the row you are relying on before you remove another one. Most of these designs fail because a control was assumed rather than configured.
Direct SQL keeps the database policy in charge
With an approved direct connection, keep both service identity verification and the intended access policy. Turning TLS on makes encrypted connections available; it does not reject unencrypted ones unless the access configuration says so through hostssl entries.
That distinction is worth checking in the running configuration rather than in a template. A server that offers TLS and accepts plaintext is not the design most people think they deployed. Read the access rules and see which entries actually require it. That one check separates an encrypted-capable server from an encrypted-only one.
Use roles with only the privileges the job needs, and review ownership, inherited membership and broadly granted permissions. The PostgreSQL privilege model is the authority boundary for database objects.
A VPN can restrict which devices reach the service before database authentication happens, and an access gateway can do something similar. Neither removes the need to maintain the exposed component, manage credentials and limit resource use.
Client certificates are a credential, not an ACL
A client certificate can add a requirement at connection time. The clientcert setting can demand a trusted certificate and, in the stricter mode, a relationship between the certificate name and the database user.
That is a stronger credential. It is not an authorization list, and it does not make the server invisible, because the component accepting the connection still processes network traffic and a handshake. Treating a certificate as an access list leaves the actual permissions untouched. It also tends to widen the certificate distribution, which creates the next problem.
A strong certificate attached to an overprivileged role produces a well-authenticated administrator. Check the role before you celebrate the certificate.
Choose the narrower interface when it fits
For an expense claim, an application endpoint that accepts the claim, enforces the business rules and returns that user's permitted result represents the operation better than a general SQL account.
The application then uses its own restricted database identity, and the customer never receives a query language as a feature. That is a smaller surface with fewer ways to be wrong.
This is a design option rather than a claim that application code is automatically safer. That code has to authenticate its callers, authorize each action and validate its input, and its own database permissions still matter.
Direct SQL remains correct for people and tools whose approved job requires it. Qualify that design with roles, network scope and operational limits, and let the other clients keep the narrower interface. Mixing the two populations in one role is where the arguments start.