Which version of PostgreSQL am I running? 3 ways to check

TL;DR#

If you're staring at a terminal and the only thing on your mind is "Which version of PostgreSQL am I running?", the answer is one command away. The fastest way is psql --version for the client, or SELECT version(); inside a psql session for the server. If you don't have psql installed, pg_config --version works too.

The question, decoded#

You typed "Which version of PostgreSQL am I running?" into Google because you're in one of these situations:

• A query that worked on your local machine fails on production, and you suspect a version mismatch.
• You're about to use a feature like GENERATED ALWAYS AS IDENTITY or MERGE and need to know if your server supports it.
• A security advisory just dropped and you want to confirm you're on a patched release.
• You inherited a database and have no idea what's running under the hood.

The symptom isn't an error message—it's the absence of information. You're logged into a server, maybe you can connect with psql, maybe you can't. The version is there, but you need the right incantation to surface it.

Why you need to know the version#

PostgreSQL releases a new major version every year, and each one brings syntax changes, new functions, and sometimes breaking behaviour. If you're writing SQL that uses jsonb_path_query_first() (added in v12) or MERGE (added in v15), running it against an older server will throw a syntax error. The same goes for extensions like pg_cron or pg_net—they have minimum version requirements.

Beyond feature compatibility, the version tells you about security. PostgreSQL 16.4 includes fixes that 16.3 doesn't. If you're on a managed service like Supabase, the platform handles patching, but you still need to know which major version your project is on to plan migrations.

The root cause of the confusion is that PostgreSQL doesn't print its version on login by default. The psql welcome banner shows the version, but only if you connect interactively. If you're scripting or using a GUI, you might never see it. And if psql isn't installed at all, you need another way.

The fix: 3 ways to check your PostgreSQL version#

I'll walk through the three methods I use in production, ordered from most common to fallback.

1. psql client version (fastest)#

If you have the PostgreSQL client tools installed, this is the one-liner:

psql --version

or the short form:

psql -V

Expected output:

psql (PostgreSQL) 16.3

That tells you the client version, which usually matches the server version if you installed the full PostgreSQL package. But it's not a guarantee—you could have a v16 client talking to a v15 server. If you get psql: command not found, you need to install the client first. I cover that exact scenario in Fix: psql: command not found (Install PostgreSQL Client).

2. SQL query (server version, always accurate)#

Connect to the database with psql (or any SQL client) and run:

SELECT version();

The output looks like this:

PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 13.2.0, 64-bit

This is the server version—the one that actually matters for query compatibility. It includes the OS, architecture, and compiler details, which can be useful when debugging platform-specific issues.

If you only need the version number without the extra fluff, use:

SHOW server_version;

That returns just 16.3. For scripting, you can also query current_setting('server_version_num') to get an integer like 160003 that's easy to compare programmatically.

3. pg_config (when psql isn't available)#

If you're on a server that has the PostgreSQL development headers installed but not the client, pg_config is your friend:

pg_config --version

Output:

PostgreSQL 16.3

This reports the version of the installed server package. It's especially handy in CI pipelines where you might have libpq-dev but not the full psql binary.

Bonus: check via package manager#

On Debian/Ubuntu:

dpkg -l | grep postgresql

On RHEL/CentOS:

rpm -qa | grep postgresql

These list installed packages, and the version number is right in the package name (e.g., postgresql-16). This is a quick way to confirm what's installed without needing any PostgreSQL tool at all.

Supabase dashboard#

If your database lives on Supabase, you don't need a terminal. Go to your project dashboard → Settings → Database, and the PostgreSQL version is displayed under "Database version". This is the server version your project is running. I use this all the time before testing new features—knowing the version upfront saves me from writing SQL that will fail on deploy. For more on navigating the Supabase SQL editor, see PostgreSQL SHOW TABLES / DESCRIBE TABLE (psql + Supabase).

Verify the version#

Pick any method above and run it. You should see a version string that matches what you expect. If you're verifying after an upgrade, compare the output against the target version. For example, after upgrading a Supabase project from v15 to v16, running SELECT version(); should now show PostgreSQL 16.x.

If the version doesn't match, double-check that you're connected to the right host and port. It's easy to accidentally run psql against a local instance when your production database is elsewhere.

Two common pitfalls when checking the version#

Pitfall A: client vs. server mismatch#

You run psql --version and see 16.3, but SELECT version(); returns 15.7. This happens when the client tools were upgraded independently of the server. Always trust the server version from SELECT version(); for compatibility decisions. The client version only matters for psql-specific features like \gexec or \if meta-commands.

Pitfall B: multiple PostgreSQL installations#

On a dev machine, you might have PostgreSQL 14 from the system package manager and PostgreSQL 16 from a Homebrew or Docker install. Running psql might pick up whichever binary is first in your PATH. Use which psql to see which one you're invoking, and if needed, specify the full path to the correct psql binary.

Keep your version knowledge handy#

I make it a habit to pin the PostgreSQL version in my project's README and in infrastructure-as-code configs. That way, when I'm debugging a query six months later, I don't have to re-discover which version the staging database is on. If you're using Docker, tag your images with the exact minor version (postgres:16.3) instead of latest to avoid surprise upgrades.

For teams, add a database migration that inserts the current version into a schema_versions table. That gives you an audit trail of when upgrades happened and what version was active at any point in time.

FAQ#

How do I check the PostgreSQL version from the command line?#

Run psql --version or psql -V to see the client version. To check the server version, connect with psql and run SELECT version(); or use pg_config --version if the development headers are installed.

What is the SQL query to get the PostgreSQL version?#

Execute SELECT version(); inside a PostgreSQL session. This returns a string like PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc... that includes the full version number and build details.

Related#

• Fix: psql: command not found (Install PostgreSQL Client)
• PostgreSQL SHOW TABLES / DESCRIBE TABLE (psql + Supabase)
• How to Drop All Tables in PostgreSQL Safely (2026)