How to run and monitor PostgreSQL in Docker with FrontierStack

Published 2026-09-02

PostgreSQL fails differently from MySQL. It is rarely the query that is slow; it is the transaction someone left open, holding a lock that a queue of other backends are politely waiting behind. This guide covers running it, and finding that transaction quickly.

Native or containerised

Services ▸ Postgres installs it natively via Homebrew with a brew services entry, and the pane handles start, stop and reload. That is fine when one PostgreSQL serves the machine.

Containers earn their place when you need versions. PostgreSQL major upgrades require a dump and reload, so running 15 and 16 side by side while you migrate is genuinely useful; and trivial with two containers on different ports, where it is painful natively.

Creating the container

Docker pane ▸ Create Container…, then pick the PostgreSQL preset. You get:

• Image postgres:16; pin the major version deliberately here; postgres:latest across a restart is how people accidentally upgrade a database.
• Port 5432, bound to 127.0.0.1 only by default, so nothing off the machine can reach it until you decide otherwise.
• Volume pgdata at /var/lib/postgresql/data; the named volume that makes the container disposable and the data permanent.
• Environment POSTGRES_PASSWORD, marked secret and masked everywhere it is displayed.

To run a second version alongside the first, create another container with image postgres:15, host port 5433, and a different volume name. Two databases, no conflict, and you can throw either away.

Read the command before you run it

The sheet previews the exact docker run line with the password masked. Read it, or copy it into a script. Press Create and it pulls, creates and starts; then the container appears in the Docker pane with logs and a shell.

Or on a linked server

Target any host in your Fleet and the same container is created there over SSH. Useful for standing up an identical database on a staging box without repeating yourself.

Reading the backends

Database Health lists every backend with its state, the query it is running, and how long it has been that way. The states that matter are idle in transaction; a client that opened a transaction and wandered off, holding locks the whole time; and anything waiting on a lock. Both show up here without you writing a pg_stat_activity query from memory.

A backend can be terminated from the pane when it is clearly the problem. It asks before it does.

"Why is it slow or stuck?"

The diagnosis runs against the live server: what is executing, what is blocked and by whom, how close you are to the connection limit, and which transactions have been open long enough to matter. Findings come back ranked, each tied to the backend responsible; so the answer is "this transaction, opened eleven minutes ago" rather than "something is holding a lock."

Check and repair operations are available here too, and a Behavior & History view charts how the server has been trending rather than only how it looks this second.

Ask the AI Administrator

Or skip the reading: "something is blocking writes on the Postgres box; what is it?" The assistant inspects the live server, explains what it found in plain terms, and proposes the fix. It will not apply anything without your approval.

Where this lives in the app

Databases ▸ Database Health is the pane doing the work. Pick a target, and it lists every live connection, flags the ones worth worrying about, and; for MySQL and PostgreSQL; answers "why is this slow or stuck?" against the running server rather than guessing from a log.

Nothing here needs an agent installed on the database host. FrontierStack reaches a linked server over SSH using the key you already use, and reads through the database's own admin interfaces.

Set the alert before you need it

The useful moment for monitoring is the one before something breaks. Add the host in Fleet, point Database Health at it, and let the checks run on a schedule; a dead database reads as "no data", not "no problem", so an explicit alert is what turns a silent failure into a notification you actually receive.