PostgreSQL port 5432 already in use: the one where killing the process does not help

Port 5432 is a special case, and it is worth knowing why before you start killing things.

With a dev server, you started the process, so killing it ends the story. Postgres is usually started by something else: Homebrew’s service manager, Docker, or Postgres.app. Kill the process and the manager starts it again, sometimes within seconds, which makes it look like the kill silently failed.

So the first question is not “what is the PID”, it is “who is in charge of this”.

Find out what owns 5432

lsof -i :5432

The command name in the output tells you which case you are in:

postgres and you are on a Mac with Homebrew, it is almost certainly a brew service.
com.docke or docker-proxy, it is a container.
postgres with Postgres.app installed, it is that.

Match the fix to the owner. This is the whole article.

Homebrew

If Homebrew started it, Homebrew should stop it:

brew services list
brew services stop postgresql@16

Use the exact name brew services list prints, the version suffix matters.

Killing the PID here is the classic wasted afternoon. brew services registers a launchd job, and launchd’s whole purpose is to keep the thing running. You kill it, launchd restarts it, the port is busy again, and it looks like nothing happened.

Docker

docker ps --filter "publish=5432"
docker stop <container>

Same logic. Killing docker-proxy does not stop the container, and Docker will republish the port. Restart policies make it worse: a container set to always or unless-stopped comes back after you kill it and after you reboot.

If it is part of a Compose project, docker compose down in that project directory is cleaner than stopping containers one at a time.

Postgres.app

Stop it from the menu bar item. There is no reason to do this from a terminal.

The stale postmaster.pid case

Different symptom, same port. Postgres refuses to start and says something like:

FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 12345) running in data directory ...?

This is Postgres protecting its data directory, not a port conflict. It writes postmaster.pid on startup and removes it on a clean shutdown. A hard kill or a power loss leaves it behind.

Check whether that PID is real before touching anything:

ps -p 12345

If nothing comes back, the file is stale and removing it is safe. If a process does come back, stop it properly and do not delete the file. Deleting a live lock file invites two postmasters onto the same data directory, which is a genuinely bad day.

When you actually should kill the process

If you started Postgres by hand, from a terminal, not through a service manager, then a normal termination is correct:

lsof -ti :5432 | xargs kill

Plain kill sends SIGTERM, which Postgres treats as a smart shutdown and handles cleanly. Avoid kill -9 on a database if you have any alternative. An unclean shutdown means recovery on the next start, and in the worst case it is how the stale pid file appeared in the first place.

Running two Postgres versions

A common cause here is upgrading without stopping the old one. Both want 5432 and the second loses. Either stop the one you are not using, or put the second on another port in its postgresql.conf:

port = 5433

Then connect with -p 5433. Worth doing deliberately when you keep an old version around for one legacy project.

The general lesson

The owner matters more than the PID. Homebrew, Docker and launchd all exist to restart what you kill, and fighting them with kill is a fight you lose repeatedly and confusingly.

Bosun shows what is holding each port in your menu bar and names Docker containers properly instead of showing docker-proxy, so you can see which case you are in before deciding what to do. macOS 14 or later, 14 day trial.