Fedora 44 ships PostgreSQL 18 by default, which is fine for new deployments but not for application stacks that still depend on the 14.x branch. To install PostgreSQL 14 on Fedora, use the official PGDG repository instead of Fedora’s own postgresql-server package.
That keeps you on the PostgreSQL 14 release line while still using normal DNF updates. PGDG currently publishes PostgreSQL 14.23 for Fedora 44, and DNF will track later 14.x minor updates from the same repo. The workflow covers the repo setup, the versioned postgresql-14.service unit, psql access, remote connections, troubleshooting, and clean removal.
Install PostgreSQL 14 on Fedora
Fedora 44 points postgresql-server at PostgreSQL 18, so PGDG is the clean path when you need PostgreSQL 14 specifically. Use Fedora’s default package when you want the current Fedora branch; use PGDG when an application or extension still requires the older major.
| Source | Fedora 44 branch | Server package | Service unit | Best fit |
|---|---|---|---|---|
| Fedora updates repo | 18.x | postgresql-server | postgresql.service | New installs that want Fedora’s current PostgreSQL branch |
| PGDG repo | 14.x | postgresql14-server | postgresql-14.service | Applications that still need PostgreSQL 14 specifically |
PostgreSQL’s support matrix lists PostgreSQL 14 as supported through November 12, 2026. The official PGDG Fedora and Red Hat instructions also note that Fedora’s short lifecycle makes it a better fit for development, testing, and compatibility work than for long-lived server deployments.
Update Fedora and confirm the default PostgreSQL package
Start with a normal Fedora package refresh so DNF5 has current metadata before you add PGDG packages.
sudo dnf upgrade --refresh
These commands use
sudofor tasks that need root privileges. If your account is not in the sudoers file yet, follow the guide to add a user to sudoers on Fedora first.
Check the default candidate package if you want to confirm what Fedora would install without PGDG.
sudo dnf info postgresql-server.x86_64
On Fedora 44, Fedora Packages currently lists the default postgresql-server package as PostgreSQL 18.3 from the updates repository; DNF output on a live system may show a newer 18.x build later. That source boundary is why the PostgreSQL 14 workflow uses PGDG’s versioned package names instead of Fedora’s unversioned PostgreSQL 18 packages.
Add the PGDG repo package
The file named pgdg-fedora-repo-latest.noarch.rpm installs the repository definitions and the matching PGDG key file for your Fedora release.
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/F-$(rpm -E %fedora)-x86_64/pgdg-fedora-repo-latest.noarch.rpm
Verify that the repo package is installed before you move on.
rpm -q pgdg-fedora-repo
A successful query returns the installed pgdg-fedora-repo package name. The current Fedora 44 release RPM is pgdg-fedora-repo-42.0-46PGDG.noarch.
Import the PGDG signing key and keep only PostgreSQL 14 enabled
Import the PGDG Fedora key explicitly so the package install stays non-interactive. On Fedora 44, this avoids the Is this ok [y/N] prompt that otherwise appears the first time DNF hits the signed PGDG metadata.
sudo rpm --import /etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-Fedora
You can confirm the key is in the RPM database with:
rpm -q gpg-pubkey --qf "%{VERSION}-%{RELEASE} %{SUMMARY}\n" | grep PostgreSQL
A matching PostgreSQL RPM Repository public key entry should appear before you continue.
The Fedora 44 repo package enables stable PGDG repositories for PostgreSQL 14 through 18 plus the shared common packages. This workflow only needs PostgreSQL 14 and pgdg-common. No DNF module reset is needed because PGDG uses versioned package names such as postgresql14-server.
Install the DNF5 config-manager provider before changing persistent repo options on a minimal Fedora system.
sudo dnf install -y 'dnf5-command(config-manager)'
sudo dnf config-manager setopt \
pgdg14.enabled=1 \
pgdg15.enabled=0 \
pgdg16.enabled=0 \
pgdg17.enabled=0 \
pgdg18.enabled=0 \
pgdg-common.enabled=1
Verify that only the PostgreSQL 14 repo and the shared PGDG common repo remain enabled.
sudo dnf repo list --enabled | grep '^pgdg'
The enabled list should include pgdg14 and pgdg-common. If pgdg15, pgdg16, pgdg17, or pgdg18 still appears, rerun the config-manager setopt block before installing the server.
Install the PostgreSQL 14 server package
The postgresql14-server package installs the versioned server unit, and it pulls in the postgresql14 client package as a dependency.
sudo dnf install -y postgresql14-server
DNF should resolve postgresql14-server from pgdg14 and pull in postgresql14 and postgresql14-libs. If DNF instead offers Fedora’s unversioned postgresql-server, stop and recheck the enabled PGDG repositories.
Use the client-only package instead if you just need psql from this Fedora host and do not want a local PostgreSQL server.
sudo dnf install -y postgresql14
If you already installed
postgresql14-server, skip the client-only command. The server package already pulled inpostgresql14and registeredpsqlthrough Fedora’s alternatives system.
Initialize the database cluster and start PostgreSQL 14
PGDG packages do not create the data directory automatically. Run the versioned setup tool once, then enable the service.
sudo /usr/pgsql-14/bin/postgresql-14-setup initdb
sudo systemctl enable --now postgresql-14
The setup command should report a successful initialization, and systemd should enable the versioned postgresql-14.service unit.
Check the service state after the first start.
systemctl is-active postgresql-14
The command should return active before you continue.
Verify psql and pg_isready
The generic psql launcher is available through /usr/bin/psql, but the readiness probe stays versioned under /usr/pgsql-14/bin/pg_isready.
psql --version
/usr/pgsql-14/bin/pg_isready
A successful check reports a PostgreSQL 14.x psql version and an accepting connections readiness line.
Manage PostgreSQL 14 on Fedora
PGDG packages use a versioned systemd unit and the standard postgres operating-system account. Use these commands for routine service work after the install.
Connect to PostgreSQL as the postgres user
Use the postgres account for the first administrative login so you do not run into the common Fedora error where psql tries to use your Linux username as a database role.
sudo -u postgres psql
A successful login opens a postgres=# prompt. Leave the PostgreSQL prompt with \q when you are done.
Create a database and login role
For application access, create a dedicated login role and give it ownership of a dedicated database instead of using the postgres superuser. Replace myappuser and myappdb with values that match your application. The password prompt keeps the secret out of shell history.
sudo -u postgres /usr/pgsql-14/bin/createuser --pwprompt myappuser
sudo -u postgres /usr/pgsql-14/bin/createdb --owner=myappuser myappdb
Verify the new credentials with a local TCP connection, then enter the password you set when psql prompts for it.
psql -h 127.0.0.1 -U myappuser -d myappdb -c "SELECT current_database(), current_user;"
The result should show myappdb as the current database and myappuser as the current user.
Common PostgreSQL 14 service commands
Use restart after changes to listen_addresses. Use reload when you only changed pg_hba.conf and do not need a full restart.
sudo systemctl stop postgresql-14
sudo systemctl start postgresql-14
sudo systemctl restart postgresql-14
sudo systemctl reload postgresql-14
For deeper tuning and authentication options, the official PostgreSQL 14 documentation is the reference for every server parameter and SQL administration command.
Allow Remote PostgreSQL 14 Connections on Fedora
Skip this section if your application and PostgreSQL run on the same Fedora host. The default Fedora 44 configuration listens on localhost and uses password authentication for TCP connections on 127.0.0.1 and ::1.
Keep
listen_addresses = 'localhost'and skip the firewalld change if PostgreSQL is only used locally. Opening5432/tcpis only necessary when remote clients need to reach the database server.
Edit postgresql.conf and pg_hba.conf
Edit the versioned PostgreSQL 14 configuration files under /var/lib/pgsql/14/data/. The first file controls which interfaces PostgreSQL listens on, and the second file controls which clients may authenticate.
sudo nano /var/lib/pgsql/14/data/postgresql.conf
sudo nano /var/lib/pgsql/14/data/pg_hba.conf
Set a listen address in postgresql.conf that matches the access you want to allow.
listen_addresses = '*'
Then add a narrow network rule to pg_hba.conf. Replace the sample subnet with the source IP range that should be allowed to connect.
host all all 192.168.1.0/24 scram-sha-256
Restart PostgreSQL after you change listen_addresses, then check the listening sockets.
sudo systemctl restart postgresql-14
ss -tln '( sport = :5432 )'
The socket list should show a non-local listener such as 0.0.0.0:5432 or [::]:5432 when listen_addresses = '*' is active. If that command still shows only 127.0.0.1:5432 and ::1:5432, PostgreSQL is still local-only and remote clients will be refused.
Open firewalld for PostgreSQL
Fedora’s default firewall already includes a postgresql service definition. Use a source-restricted rich rule unless the active zone already contains only trusted database clients.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" service name="postgresql" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rules
The final command should list the rich rule that allows your chosen source range to reach the PostgreSQL service.
If firewall-cmd is missing or the service is inactive on your system, install firewalld on Fedora before you expose PostgreSQL to the network.
If a local Nginx or Apache application still cannot connect after
pg_hba.confand firewalld are correct, Fedora’s default SELinux policy may be blocking the web server domain. Allow database connections for web server domains, then inspect recent SELinux denials.
sudo setsebool -P httpd_can_network_connect_db 1
sudo ausearch -m avc -ts recent
If ausearch is missing, install the audit package first with sudo dnf install audit.
Troubleshoot PostgreSQL 14 on Fedora
psql says role does not exist
This happens when you launch psql as your normal Linux user before a matching PostgreSQL role exists. The client tries your current Linux username by default, so the same fix applies when the missing role is named root, your login name, or another local account.
psql: error: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: FATAL: role "joshua" does not exist
Connect as postgres for the first admin session, or create a login role for the Linux account you want to use.
sudo -u postgres psql
sudo -u postgres psql -c "\du"
The role list should include the application role you created and the built-in postgres administrative role.
TCP login fails with password authentication errors
Password errors over localhost usually mean you are connecting over TCP as a role that has no password, or the application password does not match the role you created. Use the local postgres operating-system account for admin work unless you deliberately set a password on the PostgreSQL postgres role.
psql: error: connection to server at "localhost" (::1), port 5432 failed: FATAL: password authentication failed for user "postgres" psql: error: connection to server at "localhost" (::1), port 5432 failed: fe_sendauth: no password supplied
Reset the application role password from a peer-authenticated admin session, then retry the TCP connection as the application role. Run the backslash commands at the PostgreSQL prompt, not in your shell.
sudo -u postgres psql
\password myappuser
\q
psql -h 127.0.0.1 -U myappuser -d myappdb -c "SELECT 1;"
psql says no such file or directory or connection refused
This usually means the service is stopped or the database cluster was never initialized.
psql: error: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: No such file or directory Is the server running locally and accepting connections on that socket?
Check the service first. If the cluster has not been initialized yet, run the PostgreSQL 14 setup command again before you restart the service.
systemctl status postgresql-14 --no-pager
sudo /usr/pgsql-14/bin/postgresql-14-setup initdb
sudo systemctl enable --now postgresql-14
/usr/pgsql-14/bin/pg_isready
The readiness check should end with accepting connections.
postgresql.service not found after the PGDG install
That error usually appears when Fedora’s default package names are mixed with PGDG’s versioned service names. PGDG 14 uses postgresql-14.service, not postgresql.service.
systemctl list-unit-files 'postgresql*'
systemctl status postgresql-14 --no-pager
If the versioned unit appears, use postgresql-14.service for service management commands.
Remove PostgreSQL 14 from Fedora
Remove the PostgreSQL 14 packages and the PGDG repo package when you no longer need this major version, then confirm whether any versioned data files are still present.
Stop the service and remove the packages
sudo systemctl disable --now postgresql-14
sudo dnf remove 'postgresql14*'
Remove the PGDG repo package
sudo dnf remove pgdg-fedora-repo
Check for leftover PostgreSQL data files
Package removal does not replace a backup plan. Check for the versioned data directory before you delete anything else, because /var/lib/pgsql/14/ can contain databases, WAL files, and local configuration.
if sudo test -d /var/lib/pgsql/14; then
sudo find /var/lib/pgsql/14 -maxdepth 0 -type d -print
else
printf '%s\n' "No PostgreSQL 14 data directory found"
fi
If the command prints the versioned directory, back up anything you need before removing it. Run the deletion only when you intentionally want to remove the PostgreSQL 14 cluster data.
sudo rm -rf -- /var/lib/pgsql/14
Verify that PostgreSQL 14 is gone
rpm -qa 'postgresql14*'
dnf repo list --enabled | grep '^pgdg' || printf '%s\n' "No PGDG repositories are enabled"
find /etc/yum.repos.d -maxdepth 1 -name 'pgdg*.repo' -print
sudo grep -R '^\[pgdg' /etc/dnf/repos.override.d 2>/dev/null || printf '%s\n' "No PGDG override sections found"
No PostgreSQL 14 package names, no pgdg*.repo files, and no PGDG override sections should remain. If an override file contains only PGDG settings from this workflow, remove it; if it also contains other repository settings, edit only the PGDG sections.
Conclusion
PostgreSQL 14 is running on Fedora 44 with the PGDG repo trimmed to the 14.x branch, the versioned postgresql-14.service unit enabled, and psql ready for local administration. If this database will back a web stack, install Nginx on Fedora next, and keep host firewall rules narrow before accepting remote database clients.


Formatting tips for your comment
You can use basic HTML to format your comment. Useful tags currently allowed in published comments:
<code>command</code>command<strong>bold</strong><em>italic</em><blockquote>quote</blockquote>