Before PostgreSQL 14 Support Ends in 2026, How Do You Check Extension Compatibility?

PostgreSQL’s official version policy sets November 12, 2026, as the end of updates for PostgreSQL 14. Do not treat that date as proof that your extensions are ready: verify that the target installation has compatible extension files and an update path, then test the application in an isolated environment before production cutover.

Suitable for: DBAs maintaining self-hosted PostgreSQL 14 who need to inventory extensions and check upgrade prerequisites.
Suitable for: Backend engineers verifying that application features backed by extensions still work.
Not suitable for: Teams looking for a full PostgreSQL major-version selection guide or a substitute for an upgrade rehearsal.

Last reviewed October 28, 2026. The support date and PostgreSQL behavior below were checked against the official version policy, release information, and documentation. Recheck those sources and the documentation from each extension maintainer before scheduling your change.

A support deadline does not prove compatibility

PostgreSQL 14’s support deadline gives you a reason to plan, but it does not tell you whether a specific extension works with your destination version. Compatibility depends on the extension, its installed version, the files available on the destination, and the way your application uses it. The PostgreSQL 14.24 release announcement is an official release reference; it is not a compatibility list for every third-party extension.

Keep this review focused on extension blockers. Choosing a PostgreSQL destination version and planning the full migration are separate decisions. For this check, your immediate question is narrower: can the exact extensions and features your application depends on be supplied, updated, and verified on the target?

Do not move production merely because the calendar is close to the support date. If you have not inventoried dependencies, confirmed the target’s extension files, and rehearsed application behavior, the safer course is to keep the current production system in place while you resolve those gaps and plan an appropriate supported-version path.

Inventory what is installed and what the application uses

An extension listed as installed is not a complete application dependency list. PostgreSQL records installed extensions per database, so inspect every database in the instance rather than relying on one connection. The pg_extension catalog documentation describes the catalog that records installed extensions.

Connect to each database and run:

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Record the database name alongside the result. The output tells you which extensions PostgreSQL has installed there and which versions it records. It does not tell you which extension features are called by the application, whether an extension is available on the destination, or whether the target version supports an update from the installed version.

Next, inspect the target server separately:

SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;

The official view documentation explains the available-extension fields. installed_version being empty on the target may simply mean the extension is not installed in that database yet; it does not establish that the required package or library files are present and usable. Confirm those files through the target operating system’s package and deployment process, following the extension maintainer’s instructions.

Complete the inventory outside the catalog as well. Search schema and application migration scripts, deployment configuration, database objects, and source code for extension-specific functions, types, operators, and indexes. Ask application owners which features are actually exercised in production. A dependency can be present in a migration script but unused at runtime, or actively used even when a simple inventory does not show its full role.

A matching extension name is not a compatibility check

PostgreSQL extensions use installation files and definitions that must be available to the server. The extension mechanism documentation explains how extensions are packaged and installed. Consequently, finding the same extension name in the current and target environments does not prove that the target can load the required files, install the needed version, or upgrade the extension’s database objects.

For every installed extension, record the following in your migration notes:

• Whether the target environment supplies the required extension files, and how those files will be installed.
• Which extension version is present now and which versions the target makes available.
• Whether the maintainer documents support for your target PostgreSQL major version.
• Whether an update path exists from the current extension version to the intended target version.
• Which application features, schema objects, and operational tools rely on it.

Where supported by the extension and PostgreSQL installation, inspect update paths on the target:

SELECT name, source, target, path
FROM pg_extension_update_paths('extension_name');

Replace extension_name with the extension under review. Treat an empty or missing path as something to investigate, not as permission to remove the extension or skip its update. Confirm the result against the extension maintainer’s instructions and a test installation. PostgreSQL’s ALTER EXTENSION documentation describes how extension updates are requested; the command does not supply missing files or create a valid migration path by itself.

Choose the next step from the blocker you found

Use these conditions to decide what to do next:

• If the target supplies the required files, the extension maintainer supports the target PostgreSQL version, and an update path is documented, proceed to an isolated upgrade rehearsal and test the application’s real extension-dependent features.
• If the extension is absent from the target, find out whether a supported package or build process exists. Do not assume that copying a library from the old server is safe.
• If the extension is present but no update path is available, consult the maintainer’s migration guidance and test a supported intermediate or replacement route. Keep production unchanged until that route is verified.
• If the extension’s status is unknown or contradictory, treat it as a blocker. Reproduce the environment in isolation and obtain evidence from the maintainer or a controlled test before deciding.
• If a precheck passes but an application feature fails, diagnose and test that feature separately. A successful structural check is not an application acceptance test.

Keep the original extension objects in place while investigating. Removing or replacing an extension may affect database objects and application behavior. Record the change, the observed failure, and the recovery route so that the team can decide whether to continue, fix the target environment, or defer the production cutover.

Separate upgrade-tool findings from application tests

Run the target PostgreSQL version’s pg_upgrade in check mode as part of the rehearsal. The official pg_upgrade documentation explains its checks and operating requirements. Use the documentation for your intended target version, and preserve the full output rather than recording only whether the command exited successfully.

Classify each failure before you act:

• Missing library or control file: The target environment may not have the extension’s required files. Verify the package, build, and installation source for that target.
• No supported update path: The extension may need a maintainer-supported intermediate update, a different migration plan, or a replacement. Do not infer a route from the extension name alone.
• Object dependency or schema issue: Inspect dependent objects before altering or removing anything. Reproduce the change in a test database and verify the resulting schema.
• Application failure despite a clean check: Test the actual queries and features that use the extension. pg_upgrade checks cannot confirm every application-level behavior.

Also check client libraries, ORM behavior, migration scripts, and backup and restore tools against the intended destination. These components can fail independently of whether the extension is present. Record the target PostgreSQL version, extension versions, test steps, error messages, and rollback plan in one review record. Do not turn a check-mode result into a performance claim or a guarantee of a successful migration.

Validate application behavior before setting a cutover date

Build an isolated test environment that resembles the production database closely enough to exercise the relevant extension dependencies. Install the target PostgreSQL version and its extension files using the intended deployment process. Restore a suitable test copy, run the planned upgrade procedure, and then execute application tests for each identified dependency.

Test more than extension installation. Include the queries and functions the application calls, the indexes and data types it relies on, and the migration scripts used during deployment. Verify that normal application traffic can connect through the production client and ORM stack. If an extension affects scheduled jobs, maintenance tasks, or data import and export, include those paths too.

For each test, record the expected result, actual result, and any failure. Define a recovery path before testing a change that might alter extension objects or database files. The PostgreSQL backup and restore documentation describes the available backup approaches; choose and test a method that fits your environment, then store a backup copy outside the database host. A backup is not proven usable until you have restored it in a separate environment.

FAQ: Extension checks before the upgrade

How do I find installed extensions before upgrading PostgreSQL 14?

Connect to every database and query pg_extension for extension names and versions. Then compare that inventory with pg_available_extensions on the target. The catalog results are a starting point, not a complete dependency map: also inspect application code, schema objects, deployment files, and migration scripts for extension-specific functions and other features.

How can I check whether an extension will work on a newer PostgreSQL version?

Confirm that the target environment has the required extension files and that the extension maintainer documents compatibility with the target major version. Check the installed and target extension versions, then verify the update path. Finally, test the features your application actually uses. A shared name between environments is not evidence that loading or upgrading will work.

What does pg_upgrade check for extension problems?

Use the target version’s check mode and review its complete output for problems it can detect in the upgrade environment. It does not replace application tests or prove that every extension feature works. If the check identifies missing files or an update issue, resolve that specific blocker; if it passes, still test queries, indexes, client connections, and migration scripts.

Do PostgreSQL extensions need a separate update after the server upgrade?

They may. The target server’s extension files must be available, and the extension’s database objects may also require a supported update. Check the extension’s documented versions and update path, then rehearse the change. Verify dependent objects and application behavior before production. Do not remove an extension or run an update command simply because the server’s major version changed.

Check the deployment environment only after compatibility is understood

Once the extension review and application rehearsal are complete, confirm that the planned server can run the tested target environment. OSFP Cloud’s supplied product information lists AMD EPYC 7543P servers, DDR4-3200 ECC memory options, and directly attached NVMe drives. The listed systems include supported Linux distributions and SSH access. Confirm the actual selected configuration and operating system against the current product details before planning deployment; these hardware options do not include database extension installation, migration, or database operations services.

For storage planning, decide separately how you will handle redundancy and backups: the listed NVMe drives are direct-attached, with no hardware RAID, so you must plan software RAID or replication if required and place recoverable backups off-host. The storage and memory planning notes can help you frame those resource checks. If you plan to administer a Linux server over SSH, review the SSH access guide and confirm that your deployment procedure works with the selected operating system.

If your tests pass, your backup restores, and your rollback route is documented, you can schedule a production cutover with evidence rather than guesswork. If any extension remains unverified, keep that dependency visible in the release plan and defer the cutover until you can resolve it. For a self-hosted database that needs stable, dedicated resources over sustained operation, an OSFP Cloud bare-metal server may suit the deployment better than a shared instance whose CPU, storage behavior, or configuration options are not dedicated to your database. Check the actual server options against the workload you tested before choosing the destination.

Questions

How can I list extensions installed before upgrading PostgreSQL 14?

Connect to each database and query pg_extension for installed extension names and versions. Then compare those results with pg_available_extensions on the target server. Neither query reveals every application dependency, so also inspect migration scripts, database objects, deployment files, and application code for extension-specific functions, types, operators, or indexes.

How do I tell whether a PostgreSQL extension works on a newer major version?

Check the extension maintainer's compatibility information and confirm that the target PostgreSQL installation has the required control and library files. Then check whether an update path exists from the installed extension version. A matching extension name alone does not prove that it can load, upgrade, or support the features your application uses.

Can pg_upgrade identify every extension compatibility problem?

No. Run the target version's pg_upgrade in check mode to catch issues it can detect in the upgrade environment, and review its complete output. This does not replace testing application queries, extension functions, indexes, client drivers, or migration scripts. Treat missing files, missing update paths, and application failures as separate issues.

Do I need to update extensions separately after upgrading PostgreSQL?

Sometimes. Installing PostgreSQL's target-version extension files and updating an extension's SQL objects are distinct tasks. Check the extension's available versions and update paths, then apply an update only when the maintainer and your test environment support it. Confirm application behavior and recovery steps before making the same change in production.