Migrate to RunxBuild and earn up to $50 in hosting credit on your first deposit.

Calculate your savings
unxBuild
Log in Get Started
Back to Blog Explainer

Default Port for PostgreSQL: 5432, the History, the IANA Reservation, and the Three Reasons to Change It

Sean

Platform Writer

Jun 20, 2026
6 min read

The default port for PostgreSQL is 5432. It is reserved with IANA, it is what the postgres and pg_ctl binaries use unless told otherwise, and it is what the libpq clients fall back to when no port is specified. Changing it does almost nothing for security — port scanners find Postgres on any port in seconds — but it does break a lot of tooling that assumes the default. The right answer for most teams is to leave it at 5432, expose it only to the application subnet, and move on.

This post explains why 5432 is the default, how to confirm the port a particular Postgres is using, the three reasons to actually change it, and the firewall pattern that is the right answer for the security case most teams think changing the port solves.

Default Port for PostgreSQL: 5432, the History, the IANA Reservation, and the Three Reasons to Change It

Table of contents

Why 5432: the history and the IANA reservation

PostgreSQL was originally developed at UC Berkeley starting in 1986 as part of the POSTGRES project. The original default port was 5432, chosen by the project’s lead developers. The IANA registered the port for PostgreSQL in the late 1990s as part of the broader move to formalize the IANA service name and transport number registry. The current registration is at the IANA Service Name and Transport Protocol Port Number Registry under “postgres” / “postgresql” / 5432 / tcp.

The interesting trivia: 5432 was the port the Berkeley team picked for the original POSTGRES implementation. When the project was renamed to PostgreSQL in 1996 (to reflect the addition of SQL support), the port stayed. When the IANA formalized the assignment, the existing convention was already entrenched. Changing the port at that point would have broken every install in production.

The port has been 5432 for so long that changing it now is the kind of decision a team makes once and regrets for years.

How to confirm the port your Postgres is actually using

The port your Postgres is actually using is not always 5432. The four ways to confirm:

  1. The PGPORT environment variable. If the variable is set, the postgres server uses that as the default. Check with echo $PGPORT or printenv | grep PGPORT.
  2. The postgresql.conf port directive. The server’s postgresql.conf has a port = 5432 line. The active value is in the running config, which can be queried with SHOW port; from a psql session.
  3. The connection string the client uses. The psql -h host -p PORT form overrides the default. If the client connects on a non-default port, the port is in the connection string.
  4. The listening port via ss or netstat. On the server, ss -tlnp | grep postgres or netstat -an | grep 5432 shows which port the process is actually listening on. The output is the ground truth.

The SHOW port; form is the cleanest when the team has psql access. The form returns the value the running server is using, regardless of how it was set.

The gotcha: the port directive in postgresql.conf can be overridden by the command line. If the team starts the server with postgres -p 5433, the runtime port is 5433 even if the config says 5432. The SHOW port; query returns 5433, which is the source of truth.

The three reasons to change the port

The three legitimate reasons to change the default port, in order of how often they apply:

  1. Port conflict on a shared host. A team is running two Postgres instances on the same host (a dev and a staging, for example). One uses 5432, the other uses 5433. The pattern is rare in containerized deployments but common on bare-metal dev hosts.
  2. Compliance mandate. A compliance framework (PCI-DSS in some interpretations, some internal security policies) requires non-default ports for databases. The mandate is usually about the appearance of compliance, not actual security, but the team has to comply.
  3. Documentation convention. A team has a multi-service setup (Postgres on 5432, MySQL on 3306, MongoDB on 27017, Redis on 6379) and the team prefers a custom port for consistency. The convention is harmless as long as it is documented and the connection strings reflect it.

The first is the only one that requires a change. The second is a real but usually misguided requirement. The third is harmless either way.

Why changing the port for security is a bad idea

The common reason teams change the port is “security through obscurity” — the idea that a non-default port makes the database harder to find. The idea is wrong in five ways:

  1. Port scanners find open ports in seconds. A nmap scan against a public IP discovers every open port in a few minutes, regardless of which one is in use. The non-default port buys a few minutes of delay at most.
  2. The connection string reveals the database. A psql connection string includes the port. Anyone with access to the connection string (a leaked .env, a logged CI variable, a screenshot in a Slack thread) knows the port.
  3. The protocol is the giveaway. A network observer does not need to know the port to fingerprint PostgreSQL. The protocol’s first packet identifies the database server regardless of the port.
  4. The non-default port creates a maintenance burden. Every client, every driver, every dashboard, every migration tool, every monitoring agent has to be told the custom port. One of them will be wrong, and the team will spend hours debugging the wrong-port error.
  5. The non-default port gives a false sense of security. A team that changes the port and stops there is a team that has not done the real security work (firewall rules, TLS, authentication, audit logging). The non-default port is a security theatre, not security.

The right answer for the security case is: firewall rules that allow only the application subnet, TLS for in-transit encryption, authentication that requires a password or a certificate, and audit logging for every connection.

The managed Postgres caveat

The managed Postgres pattern is: the platform provisions the database, the platform sets the port, and the team gets a connection string with the port embedded. The team does not configure the port; the platform does.

The implications:

  • The port is whatever the platform chose. Some platforms (Render, Fly, Supabase) use the default 5432. Others (RDS, Cloud SQL) may use 5432 or a custom port. The team finds out from the connection string, not from a config file.
  • The firewall rules are handled by the platform. A managed platform usually has the database on a private network by default, with no public access unless the team explicitly enables it. The team does not configure iptables.
  • The connection string is the source of truth. The team reads process.env.DATABASE_URL and connects. The port is in the URL, the host is in the URL, the credentials are in the URL. The team does not have to remember the port.

The gotcha: the connection string in the dashboard may have the port as :5432 (default, no port in the URL) or :5433 (custom, explicit port). The team should use the connection string as given, not assume the default.

The firewall pattern that actually works

The firewall pattern that actually works for the security case most teams think the non-default port solves:

  1. Private network by default. The database is on a private network, accessible only from the application subnet. The platform’s private network feature is the standard implementation.
  2. Firewall rules that allow only the application subnet. The database’s firewall allows inbound from the application’s IP range (or the platform’s egress range) and nothing else. The platform’s IP allowlist feature is the standard implementation.
  3. TLS for in-transit encryption. The connection between the app and the database is encrypted. The platform’s TLS feature is the standard implementation.
  4. Authentication that requires a credential. The database requires a username and password, or a client certificate, for every connection. The platform’s credential management is the standard implementation.
  5. Audit logging for every connection. The database logs every successful and failed connection. The platform’s audit log feature is the standard implementation.

The five together are the security the team actually needs. The non-default port is a sixth item that buys almost nothing and costs real maintenance time.

How this fits the rest of the stack

The network pattern is also a cost pattern. The database tier, the storage, the bandwidth, the connection count, the private network feature, and the firewall rules each show up as a line item on the platform bill, and the team’s mental model for the project cost is the sum of those numbers. The right answer is to know the line items before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the database tier, the storage, the connection count, the private network feature, and the bandwidth, and the calculator shows what the database actually costs at the team’s actual usage.

Useful related references:

FAQ

What is the default port for PostgreSQL?

  1. The port is reserved with IANA under the service name “postgres” and is what the postgres and pg_ctl binaries use unless told otherwise. The libpq clients fall back to 5432 when no port is specified.

Why is the default PostgreSQL port 5432?

It was the port the Berkeley POSTGRES team picked for the original implementation in the late 1980s. The IANA formalized the assignment in the 1990s. The port has stayed 5432 ever since, and changing it now would break every install in production.

How do I check which port my Postgres is using?

SHOW port; from a psql session returns the value the running server is using. On the server, ss -tlnp | grep postgres or netstat -an | grep 5432 shows the listening port. The connection string the client uses is the third place to check.

Should I change the default PostgreSQL port for security?

No. Port scanners find open ports in seconds, the connection string reveals the port anyway, and the non-default port creates a maintenance burden. The right answer is firewall rules, TLS, authentication, and audit logging — the four things that actually provide security.

When should I change the default PostgreSQL port?

Three legitimate reasons: a port conflict on a shared host, a compliance mandate, or a documentation convention. The first requires a change. The second is real but usually misguided. The third is harmless either way.

Does the managed Postgres pattern let me choose the port?

Usually not. The platform picks the port, the platform configures the firewall, and the team gets a connection string with the port embedded. The team uses the connection string as given, not the default.

What is the difference between changing the port and using a firewall?

A port change is “we listen on a different number.” A firewall rule is “we listen, but only allow connections from this subnet.” The firewall rule is the security. The port change is the security theatre.

#PostgreSQL#Networking#Port#IANA#Database Administration