PostgreSQL Drops Support for Older RHEL Versions

PostgreSQL is retiring repositories for RHEL 10.0 and 9.6, cutting off systems from future updates and security patches.

The PostgreSQL project is retiring its main software repositories for Red Hat Enterprise Linux (RHEL) versions 10.0 and 9.6, according to PostgreSQL News. This directly impacts not only RHEL users but also those on popular derivatives like Rocky Linux and AlmaLinux who are running these specific minor versions. The change means that systems configured to use these repositories will no longer receive any new package updates, including bug fixes and critical security patches for the database software. While the existing packages are not being deleted, they are being moved to a separate archive location. This shift effectively ends active support for these older minor OS releases within the main PostgreSQL distribution channel, signaling a clear need for administrators to review their infrastructure. The rolling repositories for the latest EL-9 and EL-10 versions are unaffected, isolating the impact to users who have intentionally pinned their systems to these now-outdated points in time.

At a technical level, this change affects the YUM and DNF package managers used by the RHEL family of operating systems. These tools rely on repository files that point to specific URLs where software packages, or RPMs, are stored. The PostgreSQL project maintains these repositories to make installation and updates seamless. By retiring the RHEL 9.6 and 10.0 repositories, the project is essentially changing the address for these specific versions to a static archive. The "rolling" EL-9 and EL-10 repositories, by contrast, are designed for users who keep their systems updated to the latest minor release of RHEL. This is the recommended practice, as it ensures continuous access to both OS and third-party software updates. The move to an archive means the packages for 9.6 and 10.0 will be frozen in time. While they remain available for download, they will not be updated with patches for newly discovered vulnerabilities or compatibility fixes, creating a growing security and operational debt for any systems that remain on them.

This decision by the PostgreSQL community is a standard and necessary part of the software lifecycle, not an arbitrary inconvenience. Maintaining build and test environments for every minor version of every supported operating system is a significant resource drain for any open-source project, even one as large as PostgreSQL. By focusing support on the latest, actively maintained OS versions, projects can allocate their resources more effectively toward developing new features and patching security issues that affect the widest number of users. This move underscores a fundamental tension in enterprise IT: the desire for stability versus the need for security. Many organizations pin their servers to specific minor OS versions to prevent unexpected changes from breaking applications. However, this strategy only works as long as the entire software ecosystem continues to support that specific version. When a key component like a database vendor moves on, it forces a re-evaluation of that stability-focused strategy, highlighting the importance of having a proactive plan for regular OS and application updates.

For teams managing PostgreSQL on RHEL or its derivatives, the immediate takeaway is the need for action. The first step is to audit your server fleet to identify any instances running on the affected 9.6 or 10.0 minor releases. The best course of action is to schedule an upgrade of the underlying operating system to a more recent, supported minor version. This will align the system with the rolling EL-9 or EL-10 repositories and restore the flow of updates for both the OS and PostgreSQL. If an immediate OS upgrade is not feasible due to operational constraints, a temporary workaround is to reconfigure the system's package manager to point to the new PostgreSQL YUM archive URL. This should be seen as a short-term fix while planning a proper upgrade, as running unpatched database software is a significant and unacceptable security risk for any production environment. Ultimately, this event serves as a critical reminder to regularly review and update all components of the technology stack.

For developers and IT teams, this change breaks the update pipeline for PostgreSQL on specific RHEL versions. Without action, servers will miss critical security patches and bug fixes, creating significant vulnerability and operational risk. It forces an immediate review of system configurations and update strategies.

Companies running PostgreSQL on affected RHEL versions face an immediate security risk from unpatched vulnerabilities. This can lead to compliance failures, data breaches, and costly emergency remediation. The change necessitates unplanned engineering work to update systems, diverting resources from product development.