# PostgreSQL Port 5432: Check It, Change It, Fix 5433 > PostgreSQL's default port is 5432. How to check which port it really uses, change it (restart, not reload), fix Docker mappings, and why you got 5433. 1. [Home](/) 2. [Blog](/blog) 3. PostgreSQL Port 5432: How to Check It, Change It, and Why You Got 5433 DatabasesNovember 9, 20269 min read # PostgreSQL Port 5432: How to Check It, Change It, and Why You Got 5433 PostgreSQL listens on 5432, but the same number also names the local Unix socket and sets every client's default. How to check the real port, change it with a restart, and why a second install ends up on 5433. ## The short version PostgreSQL listens on TCP port 5432 by default, and the same number names its local Unix socket and is the default every libpq client tries. Check the real port with SHOW port or ss -ltnp rather than a config file. A server on 5433 is usually a second install that found 5432 taken. Changing the port needs a restart, not a reload. [Teo Marquardt](/about#author)· Facts last checked November 6, 2026 Your connection string says 5432 and psql can't connect. Or it connects fine, just to the wrong server, and the tables you created yesterday aren't there. Both usually come down to the same thing: PostgreSQL's port is set in more places than people expect, and those places don't always agree. Below: how to see which port a server really uses, why a second install lands on 5433, and how to change the port without breaking local connections. If the server is on the right port and turns you away with `sorry, too many clients already`, that's a connection limit, not a port problem, and [the post on too many clients](/blog/postgres-too-many-clients-already) covers it. ## What port does PostgreSQL use? 5432, and where that number lives PostgreSQL listens on TCP port 5432 by default. The number is registered with [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5432) under the service name `postgresql`, and most Linux systems carry it in `/etc/services`: text ``` postgresql 5432/tcp postgres # PostgreSQL Database ``` The protocol runs over TCP, or over a Unix-domain socket on the same machine. It doesn't use UDP. IANA lists the name for both tcp and udp, as it does for most registrations, but PostgreSQL only ever uses TCP, so a firewall rule only needs TCP 5432\. Replication uses the same port too: a standby streams WAL from the primary over an ordinary connection to 5432, so there's no separate replication port to open. The number does three jobs, and most port confusion comes from mixing them up: * The server listens on it. That's the `port` setting in `postgresql.conf`, default 5432\. One server listens on one port, though it can listen on several addresses through `listen_addresses` ([PostgreSQL docs](https://www.postgresql.org/docs/current/runtime-config-connection.html)). * It's part of a file name. Local connections go through a Unix socket file named after the port: `/var/run/postgresql/.s.PGSQL.5432` on Debian and Ubuntu, `/tmp/.s.PGSQL.5432` in a build from source. Change the port and the file name changes with it. * Clients assume it. libpq, the library under psql and most drivers, uses the `PGPORT` environment variable when no port is given, and otherwise a value compiled in at build time, normally 5432 ([libpq docs](https://www.postgresql.org/docs/current/libpq-envars.html)). That third role explains a common surprise. `psql` with no `-h` doesn't touch TCP at all, yet it still "uses" port 5432: it opens the socket file whose name ends in 5432\. Move the server to 5433 and plain `psql` can stop working, even though nothing about the network changed. ## What port is my Postgres running on? If you can log in, ask the server: sql ``` SHOW port; -- 5432 SELECT inet_server_port(); -- 5432 over TCP, NULL over a Unix socket SELECT name, setting, source, pending_restart FROM pg_settings WHERE name = 'port'; ``` `SHOW port` returns the configured port however you connected. `inet_server_port()` returns the port of the current TCP connection, and NULL when you came in through the socket ([function reference](https://www.postgresql.org/docs/current/functions-info.html)). The `pg_settings` query adds where the value came from (`default`, `configuration file`, `environment variable` or `command line`), which ends arguments about which config file won. In psql, `\conninfo` prints the host or socket directory and the port of the current session. If you can't log in, look from the operating system: bash ``` # Linux: who listens on 5432, and on which address sudo ss -ltnp 'sport = :5432' # LISTEN 0 244 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=812,fd=7)) # (plus a [::1]:5432 line when IPv6 is on) # No login needed: line 4 of postmaster.pid in the data directory is the port sudo sed -n '4p' /var/lib/postgresql/17/main/postmaster.pid # Debian/Ubuntu: every cluster and its port pg_lsclusters # Docker: which host port maps to the container's 5432 docker port my-postgres # Windows (PowerShell) Get-NetTCPConnection -LocalPort 5432 -State Listen ``` | Command | What it shows | Where it misleads | | ------------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | SHOW port; | The port of the server you're connected to | You have to connect first, possibly to the wrong server | | inet\_server\_port() | The port of the current TCP connection | Returns NULL over a Unix socket | | \\conninfo | Host or socket path and port of this session | Says nothing about other servers on the host | | ss -ltnp / lsof -i :5432 | Which process holds the port, on which address | Needs root for the process name; inside a container it only sees the container | | pg\_lsclusters | Every cluster on the host, with port and status | Debian and Ubuntu only | | postmaster.pid | PID, data directory, start time, port, socket directory and listen address, one per line | Exists only while the server runs, and you need to know the data directory | | docker port | The host port mapped to the container | The server inside still listens on its own port, usually 5432 | Seven ways to find the port, and where each one can mislead you Read the address as well as the port. `127.0.0.1:5432` in the `ss` output means the server accepts connections only from the same machine, so a client in another container or on another host gets refused even though the port number is right. ## Why your Postgres is on port 5433 PostgreSQL port 5433 isn't a second default. It's what you get when something already holds 5432 and an installer or `pg_createcluster` moves on to the next number. On Debian and Ubuntu, PostgreSQL runs as named clusters managed by `postgresql-common`. When `pg_createcluster` creates a cluster without an explicit port, it takes the first free port starting at 5432 ([pg\_createcluster manpage](https://manpages.debian.org/testing/postgresql-common/pg%5Fcreatecluster.1.en.html)). Installing a new major version next to the old one creates a `main` cluster for it, and because 16 already owns 5432, 17 gets 5433: text ``` $ pg_lsclusters Ver Cluster Port Status Owner Data directory Log file 16 main 5432 online postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.log 17 main 5433 online postgres /var/lib/postgresql/17/main /var/log/postgresql/postgresql-17-main.log ``` Your application still connects to 5432, which is still version 16\. If you copied the data into 17 with `pg_dump` and called the upgrade done, the app keeps writing to the old cluster and the new one never sees those writes. `pg_upgradecluster` avoids this by giving the new cluster the old port and moving the old one aside (as of writing; check `man pg_upgradecluster` for your release). Manual upgrades are where 5433 sticks. Two other routes end in the same place. The EDB installer on Windows asks for a port and, in recent versions, proposes the next free one when 5432 is taken, often by an older PostgreSQL nobody remembers installing. And on a laptop it's often a second container, mapped to 5433 on the host because the first one already took 5432. ### Change PostgreSQL port from 5433 to 5432 Two servers can't share 5432 on the same address, so decide what happens to the old one first. On Debian or Ubuntu, once you've confirmed the new cluster has all the data: bash ``` # Stop the old cluster and keep it from starting at boot sudo pg_ctlcluster 16 main stop echo manual | sudo tee /etc/postgresql/16/main/start.conf # Move the old cluster off 5432 in case someone starts it again sudo sed -i 's/^port = 5432/port = 5434/' /etc/postgresql/16/main/postgresql.conf # Give the new cluster 5432 sudo sed -i 's/^port = 5433/port = 5432/' /etc/postgresql/17/main/postgresql.conf sudo pg_ctlcluster 17 main restart pg_lsclusters ``` If you no longer need the old cluster, `sudo pg_dropcluster 16 main` deletes it along with its data, so take a dump first. On Windows, edit `port` in the `postgresql.conf` of each version's data directory and restart both services from the Services console. Either way, confirm the result with `SHOW port;` rather than trusting the file. ## How to change the PostgreSQL port To change the PostgreSQL port, set `port` in `postgresql.conf` and restart the server. On Debian and Ubuntu, edit `/etc/postgresql///postgresql.conf` (or run `sudo pg_conftool 17 main set port 5433`) rather than using ALTER SYSTEM, because `pg_lsclusters` and `pg_ctlcluster` read the port from that file only. Elsewhere, a superuser session works too: sql ``` ALTER SYSTEM SET port = 5433; -- written to postgresql.auto.conf, which overrides postgresql.conf ``` A reload isn't enough: `port` has the `postmaster` context, so PostgreSQL reads it only at startup. After `pg_ctl reload` or `systemctl reload`, `SHOW port` still says 5432 and `pending_restart` in `pg_settings` turns true. The port can also come from `postgres -p 5433` on the command line or from `PGPORT` in the server's environment. The command line beats the config file, and the config file beats the environment, but only if the file has an uncommented `port` line. Debian's has one; a stock `initdb` file doesn't. Check the `source` column when a new number doesn't stick. Then update every client. Connection strings and `PGPORT` are the obvious ones. The socket is the one people miss: plain `psql` still looks for `.s.PGSQL.5432`, which no longer exists, and fails with the error below. On Debian and Ubuntu, `psql` is a wrapper script that can pick the cluster for you, so this shows up mostly with source builds, RHEL-family packages and Docker images: text ``` psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory Is the server running locally and accepting connections on that socket? ``` The server is running; the client is looking for the old file name. `psql -p 5433`, or `export PGPORT=5433` in the shell profile, fixes it. Cron jobs, backup scripts and `pg_isready` health checks need the same change. If the error mentions TCP/IP and `Connection refused` instead of a socket, the server isn't listening where the client looks, and [ECONNREFUSED on 127.0.0.1:5432](/blog/econnrefused-127-0-0-1) walks through that case. ### Changing the port in Docker: host side vs container side In Docker you usually don't change PostgreSQL's port at all. A port mapping has two numbers, and only the left one belongs to the host: yaml ``` services: db: image: postgres:17 environment: POSTGRES_PASSWORD: change-me ports: - "127.0.0.1:5433:5432" # host 5433 -> container 5432 app: image: my-app environment: DATABASE_URL: postgresql://postgres:change-me@db:5432/postgres ``` Your laptop reaches the database on `localhost:5433`. The `app` container reaches it on `db:5432`, because traffic between containers on the same network never passes through the host mapping. Mixing the two up is the most common Docker port bug: someone sees 5433 in the compose file, puts it in the app's `DATABASE_URL`, and the app can't connect from inside the network. The official image has no `POSTGRES_PORT` variable. If the server inside the container really has to listen elsewhere, for example with `network_mode: host`, set `PGPORT: "5433"` in its environment. The server and the clients inside the container (`psql`, `pg_isready`) all read it, so health checks keep working. `command: postgres -c port=5433` also changes the port, but then every client inside the container needs `-p 5433` as well. ## "Port 5432 is already in use" PostgreSQL won't start while another process holds its port. The server log says so like this: text ``` LOG: could not bind IPv6 address "::1": Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. LOG: could not bind IPv4 address "127.0.0.1": Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. WARNING: could not create listen socket for "localhost" FATAL: could not create any TCP/IP sockets ``` Docker has two versions of the same error, and the wording shifts a little between Docker releases. `port is already allocated` usually means another container already publishes that host port. `address already in use` means something outside Docker holds it, usually a PostgreSQL installed directly on the host: text ``` Bind for 0.0.0.0:5432 failed: port is already allocated Error starting userland proxy: listen tcp4 0.0.0.0:5432: bind: address already in use ``` Find the holder with `sudo ss -ltnp 'sport = :5432'` or `sudo lsof -i :5432`, and with `docker ps --filter publish=5432` for containers. Then either stop the other server or map this one to a different host port. The second half of the HINT is for a restart where the previous server is still shutting down; if `ss` shows nothing on the port, wait and try again. ## Is changing the port a security measure? Changing PostgreSQL's port is not a security measure. Moving to 5433 or 15432 cuts the noise from bots that only try 5432, but internet-wide scanners probe many ports and recognise PostgreSQL by its handshake, not by the number. A database that's reachable from the internet with a weak password gets found on any port. What does protect it: * `listen_addresses`, which defaults to `localhost`. Set it to a private address rather than `*` when other hosts need access. * `pg_hba.conf` that admits only the networks and users that need access, with `scram-sha-256` passwords and `hostssl` lines for anything crossing a network you don't control. * A firewall that drops 5432 from everywhere except known sources. * TLS on external connections, so passwords and query results never cross the internet in clear text. * A private network between the application and the database, so the database has no public route at all. Docker publishes past your firewall `ports: - "5432:5432"` binds on every interface, and Docker writes its own iptables rules, which ufw doesn't see. A database you believe is firewalled can be open to the whole internet. Bind published ports to `127.0.0.1`, as in the compose file above, or don't publish the port and let other containers reach it over the Docker network. For teams handling EU personal data there's a GDPR side to this. Article 32 asks for appropriate technical measures to secure personal data, and a database open to the internet is hard to defend as appropriate, whatever port it listens on. ## Other ports you'll meet next to 5432 | Port | What usually runs there | Notes | | ------------ | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | 5432 | PostgreSQL, direct connections | The default for the server and for every libpq client | | 5433, 5434 | A second or third server on the same host | Debian, Ubuntu and Windows installers pick these when 5432 is taken | | 6432 | PgBouncer | PgBouncer's default listen\_port, not an IANA registration; see [what ports 5432 and 6432 do side by side](/blog/pgbouncer-connection-pooling) | | 15432, 55432 | A hand-picked host port for local development | Chosen to stay clear of a PostgreSQL on the host; nothing standard about them | ## How Runsite handles the port Each Runsite database uses the standard ports: 5432 for direct connections, and 6432 for the built-in PgBouncer in transaction mode. The two connection strings differ only in the port and a flag: bash ``` # Direct: migrations, LISTEN/NOTIFY, session-level features DATABASE_URL=postgresql://user:password@db.runsite.app:5432/mydb # Pooled through PgBouncer: application traffic DATABASE_URL=postgresql://user:password@db.runsite.app:6432/mydb?pgbouncer=true ``` Each database also has two hostnames. Services running on Runsite use the internal one over private networking, and your laptop or a BI tool uses the external one, with TLS on by default. If you'd rather not care which port the server landed on, [managed PostgreSQL with PgBouncer on 6432](/services/postgresql) gives you both ports with TLS, with the data kept in Germany. ## The short version * PostgreSQL's default port is 5432, TCP only, for client connections and replication alike. * The same number names the Unix socket file and is the client default, which is why a port change can break plain `psql`. * Check the real port with `SHOW port;`, `ss -ltnp` or `pg_lsclusters`, not by reading a config file. * 5433 usually means a second cluster or install found 5432 taken. Stop or move the old server before giving the new one 5432. * Changing the port needs a restart. In Docker, change the host side of the mapping and leave the server alone. * A different port doesn't secure anything; `listen_addresses`, `pg_hba.conf`, a firewall, TLS and a private network do. Related service ## Managed PostgreSQL on Runsite Deploy from a single git push and keep active apps warm — no cold starts, hosted entirely in the EU with a signed GDPR DPA on every plan. [Explore Managed PostgreSQL](/services/postgresql) [Back to all articles](/blog) FAQ ## Frequently Asked Questions Common questions about this service. ### What port is my Postgres running on? Run SHOW port; in any session connected to the server. If you can't connect, check from the operating system: on Linux, sudo ss -ltnp 'sport = :5432' shows which process listens on 5432 and on which address; on Debian and Ubuntu, pg\_lsclusters lists every cluster with its port; for Docker, docker port shows the host port mapped to the container's 5432\. The default is 5432 unless an installer found it taken and picked 5433 or higher. ### Is postgres 5432 TCP or UDP? TCP. The PostgreSQL protocol runs over TCP, or over a Unix-domain socket for local connections, and doesn't use UDP. Streaming replication goes over the same TCP port. A firewall rule for PostgreSQL only needs TCP 5432, or whichever port the server is configured to use. ### What is port 5433? It isn't a separate PostgreSQL default. 5433 is the port installers pick when 5432 is already taken. On Debian and Ubuntu, pg\_createcluster assigns the first free port from 5432, so a second major version installed next to the first lands on 5433\. The Windows installer proposes it when another PostgreSQL already holds 5432, and developers often map a second Docker container to 5433 on the host. ### Why is postgres port 5432? 5432 is the port the PostgreSQL project registered with IANA under the service name postgresql, and it's compiled into the server and into libpq as the default. The official documentation doesn't explain why that particular number was chosen. In practice it matters because every client tries 5432 when no port is given, so a server on any other port has to be named explicitly in the connection string or in PGPORT. Keep reading ## Related articles [Databases10 min readConnection Pooling with PgBouncer: What Ports 5432 and 6432 Really DoYou switched to port 6432 to stop the connection errors, and now prepared statements throw and SET doesn't stick. That's pooling working as designed. Here's what a pooler actually does, why 5432 and 6432 are different contracts, and what breaks in transaction mode.Jul 20, 2026Read](/blog/pgbouncer-connection-pooling)[Deployment9 min readECONNREFUSED 127.0.0.1: Your App Is Calling ItselfError: connect ECONNREFUSED 127.0.0.1:6379 after a deploy means your app is calling its own machine. Why the address says localhost, the ::1 variant, and how to fix each cause for Redis and Postgres.Oct 7, 2026Read](/blog/econnrefused-127-0-0-1)[Databases10 min readPostgreSQL "FATAL: sorry, too many clients already" — What It Means and How to Fix ItYour app is suddenly throwing 500s and the database logs are full of "too many clients already." Here's what the error really means, how to see what's hogging your connections, and the fix that actually holds: pooling, not a bigger number.Jun 26, 2026Read](/blog/postgres-too-many-clients-already) ## Your app deserves to be online €5 of credit on signup. Deploy in under a minute. No credit card needed. [Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app) --- Source: https://runsite.app/blog/postgres-port-5432