Keeping PostgreSQL in service over the long term also means keeping its extensions, application connectors, and operational tools maintainable. The benefits of a feature are visible when you adopt it; the arrangements that keep it maintained years later can be harder to see.

David Wheeler has invited participants to “A Postgres Ecosystem Foundation?” at PGConf.EU to discuss that continuity. The invitation opens a discussion about supporting extensions and tools. It does not announce a completed foundation launch.

How does this organizational discussion connect to running PostgreSQL? Following the requirements for extension upgrades shows why maintenance continuity also matters to future upgrade plans.

PostgreSQL upgrades also depend on external extensions

PostgreSQL has a versioning policy that supports each major version for five years after its initial release. That policy alone cannot establish the compatibility status of external projects used alongside it.

Consider a major upgrade with pg_upgrade. The PostgreSQL 18 documentation requires matching shared libraries for the new server when extensions use them. It also explicitly states that pg_upgrade cannot check the binary compatibility of external modules.

The operational implication is that a migration procedure for the server and a workable migration for its required extensions need separate verification. If a compatible extension build is unavailable, a plan to upgrade while retaining that dependency needs reconsideration. This is where ongoing maintenance becomes part of the technical upgrade process.

The foundation proposal raises questions about succession and shared costs

Wheeler proposes discussing abandoned projects, maintainer retirement and succession, and the sharing of maintenance effort and costs. Funding and common services such as packaging are also candidates. These are topics to develop with participants, rather than committed support programs.

For context, PostgreSQL already has supporting organizations. Its official donation page describes the PostgreSQL Community Association, which manages and protects key assets such as domains and trademarks, and PostgreSQL Europe, which supports groups in Europe. This discussion is taking place alongside existing support structures.

The question is how interested parties can sustain maintenance across extensions and tools. From an operator’s perspective, a useful proposal needs to specify which projects it supports, what work it takes on, and how the continuing costs are shared.

An organizational name alone does not establish compatibility or a maintenance period for an extension. Support arrangements need to be connected to what individual projects actually deliver.

Use pg_extension to identify dependencies whose maintenance you need to track

An inventory of installed extensions makes this discussion more concrete. The pg_extension catalog records installed extensions, with extname for the name and extversion for the version. The following read-only query uses the fields documented in the PostgreSQL 18 catalog reference.

-- List extension names and versions installed in the connected database.
SELECT extname, extversion
FROM pg_catalog.pg_extension
ORDER BY extname;

A practical approach is to run it in each relevant database, then add official repository or distribution links and compatibility information for the intended PostgreSQL version. The query establishes what is installed; it does not predict future compatibility. Application drivers and external backup tools belong in the inventory separately.

Use that inventory to identify available compatible releases, maintenance contacts, and the people responsible for internal validation. Where work is missing, it becomes easier to discuss providing test results, contributing fixes, or funding maintenance. This is a suggested operational practice, not a procedure adopted by the foundation proposal.

Bring dependency-specific maintenance problems to PGConf.EU

The session is scheduled for October 23, 2026, from 09:00 to 12:30 in Audit 3B in Valencia, Spain, using the local program’s times. The official session page lists the schedule and room. Attendance requires the Community Events Day add-on described on the registration page.

Participants can prepare examples that connect a dependency to missing work: an extension needing compatibility testing, for example, or a package distribution process needing continuity. Those details make the work to be supported concrete, including the question of whether a foundation is the right structure.

Long-term PostgreSQL operations involve both when to upgrade the server and how to sustain the components around it. Understanding your dependencies and the people maintaining them gives you a basis for evaluating future support proposals and deciding where your own team can contribute.

Source

• Title: David Wheeler: PGConf.EU Community Day: A Postgres Ecosystem Foundation?
• URL: https://postgr.es/p/9xC