How to Check PostgreSQL Version

Q: How to Check PostgreSQL Version

Check your PostgreSQL version with postgres --version from the shell, SELECT version() inside a session, or SHOW server_version in scripts. Covers client vs. server version differences and when they matter.

There are a few ways, depending on whether you have shell access or an active database session. The commands look similar but return different things, and the client/server distinction trips people up more than you'd think.

As of July 2026, the current stable release is PostgreSQL 18.4. Versions 14 through 18 are supported. PostgreSQL 14 reaches end-of-life in November 2026.

From the shell (no database connection needed)

bash

1
postgres --version

Output:

1
postgres (PostgreSQL) 18.4

This queries the server binary directly, so it works without a running database. If you get a "command not found" error, Postgres is probably installed somewhere outside your PATH. Find it with:

bash

1
which postgres || locate bin/postgres

On Debian/Ubuntu, the binary usually lives at /usr/lib/postgresql/<version>/bin/postgres. Call it directly:

bash

1
/usr/lib/postgresql/18/bin/postgres --version

From inside a database session

Connect with psql and run:

sql

1
SELECT version();

The output includes the full build string:

1234
                                                  version
------------------------------------------------------------------------------------------------------------
 PostgreSQL 18.4 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 13.3.0-6ubuntu2) 13.3.0, 64-bit
(1 row)

For scripts or monitoring queries where you only need the version number, SHOW is cleaner:

sql

1
SHOW server_version;

Output:

1234
 server_version
----------------
 18.4
(1 row)

You can also pull it from pg_settings, which is handy when comparing against a version string in application code:

sql

1
SELECT setting FROM pg_settings WHERE name = 'server_version';

The client version is separate from the server version

The psql client and the Postgres server are separate binaries. They can be on different versions. To check your client:

bash

1
psql --version

Output:

1
psql (PostgreSQL) 16.2

A psql 16 client talking to a Postgres 18 server works fine for most queries. Where it breaks down is with the dump utilities.

When the version gap actually causes problems

pg_dump refuses to dump a server newer than itself:

12
pg_dump: error: aborting because of server version mismatch
pg_dump: detail: server version: 18.4; pg_dump version: 16.14

The fix is to call the pg_dump binary that matches your server version:

bash

1
/usr/lib/postgresql/18/bin/pg_dump -h localhost -U myuser mydb > backup.sql

The same logic applies to pg_restore. A dump created by pg_dump 18 won't restore with pg_restore 16. This is the scenario that catches people out: you have a working backup, you move it to a different environment with older client tooling, and the restore fails.

A few things to watch with managed Postgres

If you're on RDS, Cloud SQL, or Azure Database for PostgreSQL, SELECT version() returns the server version your provider is running, which may lag behind the latest minor release depending on their update schedule. Check your provider's console if you're planning around a specific patch.

Managed services also run cloud-specific builds, so your SELECT version() output might look slightly different from a self-hosted installation:

1
PostgreSQL 17.2 on x86_64-pc-linux-gnu, compiled by gcc 13.2.0, 64-bit

The build metadata varies. The version number at the start is what counts.

Final thoughts

For a quick check, postgres --version from the shell does the job. Inside a session, SHOW server_version is cleanest for scripts. If something is failing and you suspect a client/server mismatch, compare both explicitly before assuming it's something else.

If you're on PostgreSQL 14, it's worth starting the upgrade conversation now. EOL is November 2026. The official versioning policy has the full schedule.

Database version is one signal. Knowing what your database is actually doing in production, across queries, connections, and downstream services, requires more. Dash0 gives you an OTel-native control plane for production: query-level traces, metrics, and logs without proprietary agents or vendor lock-in. Start a free trial — no credit card required.