5432 PostgreSQL TCP Flagship

What it's for

Port 5432 is the default port for PostgreSQL, the advanced open-source relational database known for strict standards compliance, powerful indexing, and strong support for complex data types (JSON, arrays, full-text search) alongside traditional relational features. It's the connection port your application, ORM, or psql client uses to reach a Postgres server.

Postgres has become the default choice for a huge share of modern application backends — many popular frameworks and managed cloud database services (AWS RDS, Supabase, Neon, Google Cloud SQL) treat it as a first-class, often default, database option.

Protocol basics

• Protocol: TCP, for reliable ordered query/response exchange.
• Custom binary/text hybrid wire protocol. Postgres has its own well-documented wire protocol (the "frontend/backend protocol"), which is why dedicated drivers exist for every major language rather than treating it as a generic text protocol.
• Connection-based, not request-based. Like most relational databases, a client opens a connection to port 5432 and keeps it open for potentially many queries, rather than the connect-query-disconnect pattern seen in simpler protocols.
• Extension and role-based architecture. Postgres supports extensions (PostGIS, pgvector, etc.) loaded at the database level and a fine-grained role/permission system, both operating over the same port 5432 connection.

Security considerations

• Port 5432 should not be publicly exposed in typical architectures — application servers should reach Postgres over a private network/VPC, with the database itself firewalled from direct internet access.
• pg_hba.conf controls connection authentication rules (which hosts, users, and databases are allowed, and what auth method to use) — a misconfigured pg_hba.conf entry like trust on a broadly scoped connection is a common, serious misstep.
• Enable SSL/TLS for any connection crossing an untrusted network, including connections to a managed cloud instance over the public internet — most managed providers enable this by default, but self-hosted setups often require explicit configuration.
• Use role-based least privilege — avoid having every application connect as a superuser; scope database roles to only the tables and operations they actually need.

Troubleshooting

"could not connect to server: Connection refused":

• Postgres isn't running, or is only listening on localhost rather than the network interface (listen_addresses in postgresql.conf)

"no pg_hba.conf entry for host":

• The connecting host/user/database combination isn't authorized in pg_hba.conf — this file needs an explicit rule matching your connection, and Postgres needs a reload/restart after editing it

Connects locally but not from another server/container:

• Check listen_addresses (often needs to be * or a specific interface, not just localhost) and confirm the firewall/security group allows inbound 5432 from the connecting host

"too many connections for role" / "remaining connection slots reserved":

• The max_connections limit is being hit — consider adding a connection pooler (like PgBouncer) in front of Postgres rather than simply raising the limit indefinitely, since each Postgres connection carries meaningful memory overhead

Comparison / FAQ

Why shouldn't I expose port 5432 to the public internet even with a strong password?

Because database ports are prime targets for automated scanning and exploitation attempts, and a network-level control (VPC/security group restricting access to known application servers) provides defense-in-depth beyond credentials alone — most serious breaches combine multiple weak points, not just a guessed password.

What does "no pg_hba.conf entry for host" actually mean?

Postgres uses pg_hba.conf to explicitly define which combinations of host, database, user, and authentication method are permitted. This error means your specific connection attempt doesn't match any configured rule, even if the username and password themselves are correct.

Should I use a connection pooler like PgBouncer?

For most production applications, yes — Postgres connections are relatively expensive in memory, and a pooler lets many application-level connections share a smaller number of actual database connections, improving stability under load.

Can I change PostgreSQL's default port from 5432?

Yes, via the port setting in postgresql.conf — this is sometimes done to run multiple Postgres instances on one server, or as a minor obscurity measure, though it doesn't replace proper network-level access controls.