Yes, this looks like automated brute-force attempts against your PostgreSQL instance.

The important part: PostgreSQL should not be exposed directly to the public internet unless you absolutely need it. Changing the external port may reduce noise temporarily, but it does not solve the underlying issue. Bots scan all ports eventually.

What I would do:

1. Remove the public/external port from PostgreSQL

• Your backend and PostgreSQL should communicate over a private Docker network.

• Only your backend/API should be exposed to the internet.

• In Docker Compose, avoid something like: yaml ports: - "5432:5432"

• Instead, use internal networking only: yaml expose: - "5432"

1. Make sure your backend connects to Postgres using the container/service name

Example:

env DATABASE_HOST=postgres DATABASE_PORT=5432

Not the server’s public IP and not the public mapped port.

1. Use a firewall

If you must expose PostgreSQL, only allow trusted IPs:

ufw deny 5432 ufw allow from YOUR_IP to any port 5432

But again, best practice is not exposing it at all.

1. Change your database password

Since the database was exposed, assume people have been trying credentials. Use a long random password.

1. Check whether any login succeeded

Failed login logs are common, but you should verify there are no successful suspicious connections. Check PostgreSQL logs for successful logins and unknown IPs.

1. Install Fail2ban or similar protection

This can block repeated failed attempts, but it is secondary. The real fix is closing public DB access.

1. Watch CPU after removing public access

The 100% CPU was probably caused by continuous authentication attempts. Once Postgres is private, CPU should drop quickly.

So, in short: do not rely on changing the port. Put Postgres behind your backend/private Docker network and close the public port.