PostgreSQL RPM repository gets a simpler-to-configure website

Anyone who deploys PostgreSQL on RHEL, Rocky Linux, AlmaLinux, Fedora, SLES, or openSUSE via the official package knows the ritual: go to yum.postgresql.org or zypp.postgresql.org, browse documentation pages until finding the right combination of distribution, operating system version, architecture, and PostgreSQL major version, copy the repository RPM URL, and only then install. This Monday, September 28, 2026, Devrim Gündüz, PGDG (PostgreSQL Global Development Group) maintainer for RPM packages and Principal Systems Engineer at EDB, posted on his personal blog on Planet PostgreSQL that this flow has been simplified: the homepage of both sites now resolves the search in a single form.

What Changed in Practice

According to Gündüz himself, the user selects operating system, version, architecture, and PostgreSQL version directly on the homepage, and the site returns instructions already ready to copy and paste into the terminal. In his own words: "Users no longer have to navigate through pages on the website. Instead, the front page has a clear layout and easy-to-follow instructions." This eliminates the manual step of digging through documentation to find which repository RPM corresponds exactly to the combination of EL9 x86_64 with PostgreSQL 17, for example, a task that historically led to installations with the wrong repository, an outdated GPG key, or, worse, a PostgreSQL major version different from the one planned for the environment.

The announcement also brings a new feature: a "copy link" button that generates a customizable URL pointing to the chosen combination of options. This URL can be pasted into blog posts, internal documentation, or, what matters more to those automating infrastructure, referenced and parsed by provisioning scripts. This means that Ansible playbooks, Chef recipes, Terraform modules, or Dockerfiles that today manually pin the repository RPM URL (something like the pgdg-redhat-repo or pgdg-sles-repo package, following the already familiar PGDG convention) now have a single, versionable source of truth, instead of depending on someone copying the right URL once and replicating it from memory across other projects.

Why the Wrong RPM Is a Real Production Problem

For those who work with databases, the difference between installing the right repository and the wrong one is not cosmetic. PGDG maintains separate repositories by PostgreSQL major version and by operating system version, precisely to prevent the package manager from resolving dependencies against the wrong version of system libraries. A repository RPM pointing to EL8 installed on an EL9 host, or a PostgreSQL 16 repository used on a cluster planned to run 17, does not necessarily fail at install time: sometimes the error only appears later, in a failed pg_upgrade, in an extension plugin that fails to compile against the wrong libpq version, or in a replica that refuses to start because the binary does not match the data directory's PG_VERSION. Reducing the surface of human error in this initial choice therefore has a direct effect on the integrity of the environment even before any query is executed.

The announcement also mentions that the instructions for the extra packages repository (extra packages) and for the non-free repository became clearer. These two repositories concentrate extensions and drivers that are not part of the PostgreSQL core package due to licensing or because they are not part of the official project, and that tend to be a source of confusion about which repository to enable to get, for example, a specific connectivity driver or a third-party extension packaged by PGDG itself.

A Day of Several Adjustments to the Same Repository

The announcement of the new site is not an isolated event. On the same day, September 28, 2026, Gündüz also posted that the RPMs of the repositories for RHEL, Rocky Linux, and AlmaLinux now follow the operating system's minor version, and that the PostgreSQL repository has arrived on Amazon Linux 2023. Together, the three announcements from the same day outline a movement toward maturing RPM-based distribution: more precision about which build corresponds to which minor version of the host distro, one more cloud platform covered (Amazon Linux 2023, common in EC2 and in managed images on AWS), and now, an interface that reduces the friction of finding the right commands for all of this. It's worth noting that PGDG itself had already been on this path for a while: the blog lists, in previous months, support for openSUSE Leap 16.0 in March 2026 and installation improvements on SLES 15 since February 2024, a sign that RPM distribution coverage is an ongoing effort, not a one-off.

What the Overhaul Doesn't Solve

The new site makes it easier to find the right command, but it does not eliminate responsibilities that remain the administrator's. Importing the PGDG GPG key before trusting the repository is still a manual step, and no infrastructure team should skip validating that signature before pointing production to an external repository, no matter how trustworthy the source is. The form also doesn't replace the decision to pin a version: in production environments, it's recommended practice to lock the exact PostgreSQL minor version in the dnf or zypper configuration file (via exclude or versionlock), preventing a routine dnf update from bumping the minor version without a planned maintenance window. This matters even more after the adjustment announced the same day about RPMs following the operating system's minor version: the more granular the pairing between package and distro becomes, the more it matters to automate this check instead of relying on memory.

Another point: the new feature only covers the YUM (Red Hat, Rocky, AlmaLinux, Fedora, Amazon Linux) and ZYPP (SUSE, openSUSE) ecosystems. Those who run PostgreSQL via APT on Debian or Ubuntu are not affected by this specific change, since PGDG's APT repository is maintained separately. And for those who already have mature provisioning pipelines with the repository URL fixed in an environment variable or in an internal infrastructure-as-code module, the immediate gain is smaller: the value is concentrated among those who still configure hosts manually, those who spin up test environments frequently, or those who are designing the automation of a PostgreSQL cluster on RPM for the first time.

Even so, for a piece of infrastructure as central as the package repository of a relational database widely used in production, reducing the chance of error in the first step (choosing the right repository) is a discreet governance improvement, but one with a direct effect on the reliability of everything that comes after: installation, upgrade, and, eventually, backup restoration to a compatible version.