How to Install PostgreSQL on Arch Linux

PostgreSQL is an advanced open-source relational database system used for web applications, data warehousing, geospatial analysis, and anywhere data integrity matters. It handles complex queries, JSON storage, full-text search, and advanced features like table inheritance and custom data types.

This guide covers installing PostgreSQL on Arch Linux, initializing the database cluster with secure defaults, configuring authentication for both local and remote access, and managing the service through systemd. By the end, you will have a working PostgreSQL server with a dedicated application database and user, ready for development or production use.

Update Arch Linux

Before installing new packages, synchronize the package database and upgrade all installed packages to ensure compatibility:

sudo pacman -Syu

On a rolling-release distribution, keeping packages synchronized prevents dependency conflicts during installation.

Install PostgreSQL on Arch Linux

Install the PostgreSQL server package from the official Arch Linux repositories:

sudo pacman -S postgresql

This installs the PostgreSQL server, client utilities (psql, pg_dump, createdb, etc.), and creates a system user called postgres that owns the database files and runs the server process.

Verify the installation by checking the installed package version:

pacman -Qi postgresql | grep -E "^(Name|Version)"

Name            : postgresql
Version         : 18.1-2

Initialize the Database Cluster

Unlike distributions that automatically initialize PostgreSQL during installation, Arch Linux expects you to configure the database cluster yourself. This gives you control over locale, encoding, and authentication settings from the start.

Switch to the postgres system user and run the initialization command:

sudo -iu postgres initdb -D /var/lib/postgres/data

The -iu postgres flags log you in as the postgres user with their environment loaded. This creates the database cluster in /var/lib/postgres/data/, including system databases (postgres, template0, template1), configuration files (postgresql.conf, pg_hba.conf), and the initial superuser account.

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are enabled.

creating directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgres/data -l logfile start

For production environments, initialize with specific authentication methods and the C.UTF-8 locale to avoid collation version warnings after glibc updates:

sudo -iu postgres initdb -D /var/lib/postgres/data --locale=C.UTF-8 --encoding=UTF8 --auth-local=peer --auth-host=scram-sha-256

This command sets the locale to C.UTF-8 (avoiding collation version mismatches when glibc updates), configures peer authentication for local Unix socket connections, and requires SCRAM-SHA-256 password authentication for network connections.

PostgreSQL 18 enables data page checksums by default, so the --data-checksums flag is no longer needed. Checksums detect silent data corruption from storage failures or bit rot, with minimal performance impact. You can verify checksums are enabled after initialization with sudo -iu postgres psql -c "SHOW data_checksums".

If your database directory resides on a Btrfs filesystem, the PostgreSQL package automatically sets the C (No_COW) attribute via systemd-tmpfiles to disable copy-on-write, which would otherwise conflict with PostgreSQL’s write-ahead logging. ZFS users should set recordsize=8K or 16K on the dataset containing the data directory. See the Arch Wiki PostgreSQL page for filesystem-specific guidance.

Start and Enable the PostgreSQL Service

With the database cluster initialized, start PostgreSQL and configure it to launch automatically at boot:

sudo systemctl enable postgresql --now

The --now flag combines enable and start into a single command. Verify the service is running:

systemctl status postgresql

● postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; preset: disabled)
     Active: active (running) since Sat 2026-02-01 10:25:18 UTC; 5s ago
    Process: 1234 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data (code=exited, status=0/SUCCESS)
   Main PID: 1235 (postgres)
      Tasks: 6 (limit: 4915)
     Memory: 28.5M
        CPU: 125ms
     CGroup: /system.slice/postgresql.service
             ├─1235 /usr/bin/postgres -D /var/lib/postgres/data
             ├─1236 "postgres: checkpointer "
             ├─1237 "postgres: background writer "
             ├─1238 "postgres: walwriter "
             ├─1239 "postgres: autovacuum launcher "
             └─1240 "postgres: logical replication launcher "

Confirm the installation by checking the PostgreSQL version:

psql --version

psql (PostgreSQL) 18.1

Configure PostgreSQL Authentication

PostgreSQL authentication is controlled by the pg_hba.conf file (Host-Based Authentication) in the data directory. By default, the trust authentication method allows any local user to connect as any database user without credentials, which is convenient for initial setup but insecure for anything beyond single-user development machines.

Restrict Superuser Access

The postgres database superuser has unrestricted access to all databases and can modify any data. To prevent accidental or malicious access, restrict superuser connections so only the system postgres user can connect as the database superuser:

sudo nano /var/lib/postgres/data/pg_hba.conf

Find the line for local connections:

# "local" is for Unix domain socket connections only
local   all             all                                     trust

Change it to use peer authentication for the postgres user:

# "local" is for Unix domain socket connections only
local   all             postgres                                peer

Peer authentication ties database access to your Linux system account. When you switch to the postgres system user (via sudo -iu postgres), you can access the postgres database superuser without a password because Linux has already verified your identity. Other system users cannot impersonate the database superuser because they cannot authenticate as the postgres Linux user.

Enable Password Authentication for Application Users

Application users (web apps, scripts, services) typically need password-based authentication rather than peer authentication, since they run under different system accounts. Add a rule for SCRAM-SHA-256 authentication, which is the most secure password method available:

# "local" is for Unix domain socket connections only
local   all             postgres                                peer
local   all             all                                     scram-sha-256

This configuration creates a two-tier access model: the postgres superuser connects via peer authentication (system identity), while application users connect with SCRAM-SHA-256 passwords. Reload the configuration to apply changes without restarting the server:

sudo systemctl reload postgresql

Connect to PostgreSQL

With peer authentication configured, connect to PostgreSQL as the database superuser by first switching to the postgres system user:

sudo -iu postgres psql

The PostgreSQL prompt confirms a successful connection:

psql (18.1)
Type "help" for help.

postgres=#

Exit the shell with \q or press Ctrl+D.

Useful psql Commands

The psql shell uses backslash meta-commands for database administration tasks. These commands work inside the psql prompt (indicated by postgres=# or dbname=>):

Command	Description
\l	List all databases
\c dbname	Connect to a specific database
\dt	List tables in the current database
\du	List all users and their roles
\d tablename	Describe a table structure
\?	Show all meta-commands
\q	Quit the psql shell

Create a Database and User

Production applications should never use the postgres superuser for database access. Create dedicated databases and users with limited privileges for each application. Connect as the superuser:

sudo -iu postgres psql

Create a new database and user with appropriate permissions:

CREATE USER myapp_user WITH ENCRYPTED PASSWORD 'secure_password';
CREATE DATABASE myapp_db OWNER myapp_user;
\q

Replace myapp_db, myapp_user, and secure_password with your actual values. The OWNER clause grants the user full control over the database, including creating and dropping tables. Use a strong password with mixed case, numbers, and special characters.

Test the connection with the new user:

psql -U myapp_user -d myapp_db

If you configured SCRAM-SHA-256 authentication, you will be prompted for the password. A successful connection displays the psql prompt with your database name:

Password for user myapp_user:
psql (18.1)
Type "help" for help.

myapp_db=>

Creating a PostgreSQL user with the same name as your Linux username allows you to connect without specifying -U username. The psql client defaults to your system username when no user is specified.

Configure Network Access

By default, PostgreSQL only accepts connections through Unix domain sockets and localhost (127.0.0.1). This is the most secure configuration for databases accessed only by applications on the same machine. To accept connections from other hosts on the network, modify both the server configuration and authentication rules.

Enable Network Listening

Edit the main configuration file to specify which network interfaces PostgreSQL should listen on:

sudo nano /var/lib/postgres/data/postgresql.conf

Find the listen_addresses setting and modify it:

# Listen on all interfaces (use specific IPs for production)
listen_addresses = '*'

Using '*' binds to all available interfaces, which is convenient for development but exposes the database to any network the server can reach. For production, specify only the IP addresses that need to accept connections:

listen_addresses = 'localhost,192.168.1.100'

Allow Remote Client Connections

Listening on a network interface is not enough; you must also add authentication rules for remote clients. Edit pg_hba.conf:

sudo nano /var/lib/postgres/data/pg_hba.conf

Add a line for the remote network or specific IP addresses:

# IPv4 remote connections
host    all             all             192.168.1.0/24          scram-sha-256

This rule allows any user to connect to any database from the 192.168.1.0/24 subnet using password authentication. Adjust the IP range to match your network, or use a specific IP with /32 for single-host access. Restart PostgreSQL to apply the network configuration change:

sudo systemctl restart postgresql

PostgreSQL uses TCP port 5432 by default. If you have a firewall configured on your Arch Linux system, allow incoming connections on this port: sudo ufw allow 5432/tcp. Only open this port if you need remote database access; local connections through Unix sockets do not require firewall rules.

Manage the PostgreSQL Service

Control the PostgreSQL service through systemd. Most configuration changes only require a reload, which applies settings without dropping active connections:

# Stop the service (terminates all connections)
sudo systemctl stop postgresql

# Start the service
sudo systemctl start postgresql

# Restart the service (required for listen_addresses changes)
sudo systemctl restart postgresql

# Reload configuration without dropping connections (pg_hba.conf changes)
sudo systemctl reload postgresql

# Check service status
systemctl status postgresql

# Disable automatic startup at boot
sudo systemctl disable postgresql

# Re-enable automatic startup
sudo systemctl enable postgresql

Use reload for authentication and logging changes; use restart for network configuration changes like listen_addresses or port.

Upgrade PostgreSQL

Arch Linux’s rolling release model means PostgreSQL major version upgrades arrive through regular pacman -Syu updates. Unlike minor updates (18.0 to 18.1), major version upgrades (17.x to 18.x) require migrating your database cluster because the internal storage format changes between major releases.

Before upgrading, always back up your databases. Use pg_dumpall to create a logical backup that can be restored to any PostgreSQL version: sudo -iu postgres pg_dumpall > backup.sql

The postgresql-old-upgrade package provides binaries from the previous major version, allowing pg_upgrade to migrate your cluster in place. This is significantly faster than dump/restore for large databases because it copies data files directly rather than re-importing through SQL. See the Arch Wiki PostgreSQL upgrade section for detailed step-by-step instructions.

To prevent accidental upgrades before you are ready to migrate, add PostgreSQL packages to the IgnorePkg line in /etc/pacman.conf:

IgnorePkg = postgresql postgresql-libs

Remove the packages from IgnorePkg when you are ready to upgrade, perform the migration, then re-add them until the next major version.

Troubleshoot Common Issues

Most PostgreSQL problems fall into three categories: service startup failures, authentication errors, and connection issues. The journal and PostgreSQL logs provide the information needed to diagnose each.

Service Fails to Start

If PostgreSQL fails to start after installation or a configuration change, check the systemd journal for error messages:

journalctl -xeu postgresql

The -x flag adds helpful context, -e jumps to the end, and -u postgresql filters to the PostgreSQL service. Common causes include:

• Missing data directory initialization: Run initdb as shown in the installation section
• Permission issues: Ensure the postgres user owns /var/lib/postgres/data
• Port already in use: Another process may be using port 5432

Fix permission issues with:

sudo chown -R postgres:postgres /var/lib/postgres/data

Authentication Failed

Authentication errors appear as “Peer authentication failed” or “password authentication failed” when connecting. The fix depends on which authentication method you intended to use:

• Peer authentication failed: You are connecting as a Linux user that does not match the database user. Either switch to the correct Linux user (sudo -iu postgres) or change pg_hba.conf to use password authentication for that user
• Password authentication failed: The password is wrong or the user does not have a password set. Set one with ALTER USER username WITH ENCRYPTED PASSWORD 'newpassword'; from a superuser session

After modifying pg_hba.conf, reload the configuration:

sudo systemctl reload postgresql

Collation Version Mismatch Warning

On a rolling release distribution like Arch Linux, glibc updates can change how text collation works. After such updates, you may see:

WARNING: database "postgres" has a collation version mismatch

This warning indicates that indexes using locale-dependent collations may return results in a different order than when they were created. While the data is not corrupt, index ordering could be wrong. Reindex affected databases and refresh the collation version to clear the warning:

sudo -iu postgres psql -c 'REINDEX DATABASE postgres'
sudo -iu postgres psql -c 'ALTER DATABASE postgres REFRESH COLLATION VERSION'

Repeat this for each database that shows the warning. To avoid collation warnings entirely on new installations, initialize the cluster with the C.UTF-8 or C locale as shown in the production initdb example. These locales do not depend on glibc’s collation data.

Cannot Connect from Remote Host

If remote connections fail, check these settings in order:

1. Verify listen_addresses in postgresql.conf includes the server IP or '*' (default is localhost only)
2. Check that pg_hba.conf has a rule matching the client IP address and authentication method
3. Ensure your firewall allows TCP port 5432: sudo ufw status should show 5432 allowed
4. Restart PostgreSQL after configuration changes: sudo systemctl restart postgresql

Test connectivity from the client:

psql -h server_ip -U myapp_user -d myapp_db

Remove PostgreSQL

To completely remove PostgreSQL from your system, stop and disable the service to prevent it from running or restarting:

sudo systemctl stop postgresql
sudo systemctl disable postgresql

Remove the package along with its dependencies and configuration files:

sudo pacman -Rns postgresql

The -Rns flags remove the package (-R), unneeded dependencies that were installed with it (-s), and backup configuration files created by pacman (-n).

The database files in /var/lib/postgres/ are preserved by pacman to prevent accidental data loss. If you want to completely remove all databases, back up any data you need with pg_dumpall first, then manually delete the data directory.

To remove the database directory after confirming you have backed up all needed data:

sudo rm -rf /var/lib/postgres

Verify removal by checking for the package:

pacman -Qi postgresql

error: package 'postgresql' was not found

Frequently Asked Questions

Conclusion

You now have PostgreSQL configured on Arch Linux with secure authentication, a dedicated application database and user, and an understanding of service management and major version upgrades. For web applications, always create dedicated database users with limited privileges rather than exposing the postgres superuser. If you need a MySQL-compatible database for applications that require it, see the MariaDB installation guide for Arch Linux. The Arch Wiki PostgreSQL page and PostgreSQL official documentation cover advanced topics including replication, backup strategies, and performance tuning.