Finding PostgreSQL 14 Databases That Need an Upgrade

Organizations often operate multiple PostgreSQL databases across development, testing, staging, and production environments. Some databases support customer-facing applications, while others are used for internal reporting, analytics, background jobs, or legacy systems.

Over time, database versions can become outdated without anyone noticing. A team may upgrade its primary production database while leaving older instances running in development environments, reporting systems, or applications maintained by another department.

This becomes a security and maintenance concern when a PostgreSQL major version reaches the end of its support period.

PostgreSQL 14 has reached the end of its community support lifecycle. Its final scheduled support date was November 12, 2026, and PostgreSQL 14.25 is the final minor release. It will no longer receive regular community security and bug fixes.

The challenge for database administrators is not simply upgrading one PostgreSQL server. It is identifying every PostgreSQL 14 instance, understanding which applications depend on it, assessing the upgrade risks, and prioritizing the databases that need attention.

This article explains how to find PostgreSQL 14 databases, inventory instances across environments, identify applications that depend on them, assess upgrade risks, and prepare a practical migration plan.

Why PostgreSQL 14 Databases Need Attention

PostgreSQL follows a major-version support policy under which each major release receives approximately five years of community support.

During the support period, PostgreSQL releases minor updates containing bug fixes, security fixes, and other important corrections.

After a major version reaches end of life, the community stops publishing regular fixes for that version.

This does not mean that an existing PostgreSQL 14 database immediately stops working. Applications can continue connecting to it, executing queries, and processing transactions.

However, continuing to run an unsupported version creates several risks.

Security vulnerabilities may remain unpatched

Security vulnerabilities can be discovered after a PostgreSQL version reaches end of life.

If the affected version no longer receives community security updates, administrators cannot rely on the normal PostgreSQL release process to provide a fix.

This is particularly important for databases that:

• Accept connections from external applications.

• Store customer or financial information.

• Support public-facing services.

• Are accessible through multiple application environments.

• Contain sensitive business records.

The risk depends on the vulnerability and the database's exposure, but an unsupported database should be treated as a security-maintenance concern.

Compatibility with newer tools becomes harder

Database drivers, extensions, monitoring tools, backup utilities, and application frameworks evolve over time.

Older PostgreSQL versions may eventually become less compatible with newer software or lose support in managed services and development tools.

This can make future maintenance more difficult.

Operational risks increase

A database upgrade becomes more complicated when the source version is significantly older than the target version.

Administrators may need to review several major-version changes, extension compatibility, deprecated behavior, and migration requirements.

Planning an upgrade before a database becomes several releases behind makes the process easier to manage.

Understanding PostgreSQL 14 Support Status

PostgreSQL's official versioning policy identifies the supported major versions and their expected final release dates.

The support status of PostgreSQL 14 is particularly important when deciding which databases to prioritize.

PostgreSQL 14.25 is the final minor release in the PostgreSQL 14 series.

An organization should not confuse the latest minor version with a supported major version. PostgreSQL 14.25 contains the final scheduled maintenance updates for PostgreSQL 14, but installing it does not extend the version's community support lifecycle.

For databases that must remain on PostgreSQL 14 temporarily, verify that the instance is running the latest available minor release. This is a temporary risk-reduction measure, not a replacement for upgrading.

How to Find PostgreSQL 14 Databases

The first step is to identify every database server running PostgreSQL 14.

In a small environment, an administrator may know where the database servers are installed. In a larger organization, instances can exist across several infrastructure platforms.

For example:

Organization
    |
    +-- Production
    |     |
    |     +-- Customer API Database
    |     +-- Payment Database
    |     +-- Reporting Database
    |
    +-- Staging
    |     |
    |     +-- Customer API Staging
    |     +-- Payment Staging
    |
    +-- Development
          |
          +-- Developer Database
          +-- Integration Test Database

Do not limit the investigation to production. A development database may contain an old schema or application dependency that becomes important during migration testing.

Check the PostgreSQL server version

If you can connect to a PostgreSQL instance, use the following SQL statement:

SELECT version();

Example output:

PostgreSQL 14.25 on x86_64-pc-linux-gnu,
compiled by gcc, 64-bit

This confirms the PostgreSQL server version.

For a shorter and easier-to-process result, use:

SHOW server_version;

Or:

SELECT current_setting('server_version');

The result can be used by scripts and monitoring tools to identify PostgreSQL 14 instances.

Identify the server version and database name together

When connected to an instance, retrieve its version and database information:

SELECT
    current_database() AS database_name,
    current_setting('server_version') AS server_version,
    current_setting('server_version_num') AS server_version_num;

The server_version_num setting provides a numeric representation of the version.

For PostgreSQL 14, the major-version number begins with 14.

For example, a version such as 14.25 is represented by a numeric value beginning with 1400.

You can use this information in inventory scripts to classify database instances.

Check the PostgreSQL version from the command line

If you have access to the database server or a machine with PostgreSQL client tools, use:

psql --version

Example:

psql (PostgreSQL) 14.25

However, there is an important distinction: this command reports the installed client version, not necessarily the version of the remote PostgreSQL server.

To inspect the server version through a connection:

psql \
  -h database-host \
  -U postgres \
  -d postgres \
  -c "SHOW server_version;"

This distinction matters when multiple PostgreSQL client versions are installed on the same machine.

Finding PostgreSQL 14 Instances Across Multiple Servers

For larger environments, manually connecting to every database is inefficient.

A database inventory script can connect to known PostgreSQL endpoints and collect their server versions.

For example, the following Python script checks a list of database instances.

Install the PostgreSQL Python driver:

pip install "psycopg[binary]"

Create a file named database_inventory.py:

import psycopg

databases = [
    {
        "name": "Production",
        "host": "prod-db.example.com",
        "port": 5432,
        "database": "postgres"
    },
    {
        "name": "Staging",
        "host": "staging-db.example.com",
        "port": 5432,
        "database": "postgres"
    },
    {
        "name": "Development",
        "host": "dev-db.example.com",
        "port": 5432,
        "database": "postgres"
    }
]

for db in databases:
    try:
        with psycopg.connect(
            host=db["host"],
            port=db["port"],
            dbname=db["database"],
            user="inventory_user",
            password="YOUR_SECRET_SOURCE",
            connect_timeout=5
        ) as connection:

            with connection.cursor() as cursor:
                cursor.execute("""
                    SELECT
                        current_setting('server_version'),
                        current_setting('server_version_num')
                """)

                version, version_num = cursor.fetchone()

                major_version = int(version_num) // 10000

                status = (
                    "Upgrade required"
                    if major_version == 14
                    else "Review support status"
                )

                print(
                    db["name"],
                    version,
                    status
                )

    except Exception as error:
        print(
            db["name"],
            "Connection failed:",
            str(error)
        )

The example uses a placeholder for the password source. In a production implementation, retrieve credentials from a secure secret manager rather than hardcoding them.

Also, a failed connection does not mean the server is not running PostgreSQL 14. It means the inventory process could not verify its version.

Possible causes include:

• Incorrect credentials.

• Network restrictions.

• Firewall rules.

• Database availability issues.

• Missing connection permissions.

• Incorrect host or port information.

Record these failures separately so that unverified instances are not mistakenly excluded from the inventory.

Use a central inventory instead of relying on manual lists

A production inventory should contain more than the database version.

For example:

This inventory becomes the foundation for the upgrade project.

Find PostgreSQL 14 Databases in Cloud Environments

Not every PostgreSQL database is installed on a server that your team manages directly.

Organizations often use managed database services.

Examples include:

• Amazon RDS for PostgreSQL.

• Amazon Aurora PostgreSQL-Compatible Edition.

• Azure Database for PostgreSQL.

• Google Cloud SQL for PostgreSQL.

• Self-managed PostgreSQL instances running on virtual machines or containers.

The discovery process depends on the platform.

Amazon RDS

For Amazon RDS, AWS CLI can list PostgreSQL database instances.

aws rds describe-db-instances \
  --query "DBInstances[?Engine=='postgres'].[DBInstanceIdentifier,EngineVersion,DBInstanceStatus]" \
  --output table

This helps identify PostgreSQL instances and their engine versions.

For Aurora PostgreSQL, inspect the relevant database clusters separately because Aurora cluster information and instance information are managed through different AWS resources.

Do not assume that every PostgreSQL-compatible database uses the same upgrade path as a standard PostgreSQL installation.

Azure Database for PostgreSQL

For Azure Database for PostgreSQL Flexible Server, Azure CLI can list server information.

az postgres flexible-server list \
  --query "[].{Name:name,Version:version,State:state,Location:location}" \
  --output table

This provides a starting point for identifying older database versions.

Verify the actual service configuration and supported upgrade paths for each server.

Google Cloud SQL

For Cloud SQL PostgreSQL instances:

gcloud sql instances list \
  --format="table(name,databaseVersion,state,region)"

The databaseVersion field helps identify the PostgreSQL major version.

Managed database providers have their own maintenance schedules, supported upgrade paths, and operational constraints. Review the provider's documentation before selecting a migration method.

Identify Which Applications Depend on PostgreSQL 14

Finding a PostgreSQL 14 server is only the first part of the investigation.

The next question is more important:

Which applications depend on this database?

An organization may have a PostgreSQL 14 instance that hosts several databases used by different services.

For example:

PostgreSQL 14 Server
    |
    +-- customer_db
    |       |
    |       +-- Customer API
    |
    +-- payment_db
    |       |
    |       +-- Payment Service
    |
    +-- reporting_db
            |
            +-- Reporting Application

Upgrading the server affects all databases and applications hosted on that instance.

Before planning the migration, identify:

• Application connection strings.

• Database users and roles.

• Background jobs.

• Reporting tools.

• ETL pipelines.

• External integrations.

• Monitoring services.

• Replication consumers.

• Backup and recovery processes.

Inspect active database connections

PostgreSQL provides the pg_stat_activity system view for monitoring current sessions.

For example:

SELECT
    datname AS database_name,
    usename AS database_user,
    application_name,
    client_addr,
    state,
    COUNT(*) AS connection_count
FROM pg_stat_activity
WHERE datname IS NOT NULL
GROUP BY
    datname,
    usename,
    application_name,
    client_addr,
    state
ORDER BY connection_count DESC;