• HOME
  • PostgreSQLのインストールと初期設定方法（Ubuntu・RHEL系、接続設定とユーザー作成まで）

2026年7月30日

  • シェア
  • ツイート

    • 2026年7月30日

    PostgreSQLのインストールと初期設定方法（Ubuntu・RHEL系、接続設定とユーザー作成まで）

    PostgreSQL は、OS のパッケージか PostgreSQL 公式のリポジトリ（PGDG）からインストールし、そのあと「接続を受け付ける範囲」「認証方式」「アプリ用のユーザーとデータベース」の3点を設定すれば、アプリから使える状態になります。この記事では、Ubuntu・Debian 系と RHEL 系（Rocky Linux、AlmaLinux など）でのインストール、最初に確認する設定ファイル、pg_hba.conf による接続制限、ユーザーとデータベースの作り方、メモリまわりの初期値、バックアップの準備までを順に説明します。

    なお、WordPress のコアは MySQL と MariaDB を対象にしており、PostgreSQL は公式にはサポートされていません。この記事は、WordPress と同じサーバーで動かす別のアプリや、分析用のデータベースとして PostgreSQL を使う場面を想定しています。

    バージョンとインストール元を選ぶ

    PostgreSQL はおおむね毎年秋に新しいメジャーバージョンが出て、各メジャーバージョンは約5年間保守されます。新しく構築するなら、公式サイトのバージョン方針のページで、保守期間が長く残っているバージョンを選びます（2026年10月現在の状況は公式サイトで確認してください）。

    インストール元は2つあります。

    • OS のパッケージ：手軽で、OS のセキュリティ更新と一緒に管理できます。ただし、入るメジャーバージョンは OS のリリースごとに固定です。
    • PGDG のリポジトリ：PostgreSQL のプロジェクトが提供するリポジトリで、新しいメジャーバージョンも選べます。アプリが特定のバージョンを求める場合はこちらを使います。

    以下の例では、メジャーバージョンを 18 として書いています。実際に使うバージョンの数字に読み替えてください。

    Ubuntu・Debian 系でのインストール

    OS のパッケージをそのまま使うなら、次の1行で入ります。

    sudo apt update
sudo apt install -y postgresql

    PGDG のリポジトリを使う場合は、postgresql-common に含まれる設定用スクリプトでリポジトリを追加してから、バージョンを指定して入れます。

    sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install -y postgresql-18

    Debian 系では、インストールと同時にデータベースの「クラスタ」（1つのサーバープロセスが管理するデータの集まり）が作られ、サービスも起動します。状態は次のコマンドで確認します。

    pg_lsclusters
sudo systemctl status postgresql@18-main

    設定ファイルは /etc/postgresql/18/main/ に、データは /var/lib/postgresql/18/main/ に置かれます。

    RHEL 系でのインストール

    RHEL 系では、PGDG のリポジトリ用パッケージを入れ、OS 標準の PostgreSQL モジュールを無効にしてから入れるのが一般的な手順です。リポジトリ用パッケージの URL は OS のバージョンによって変わるため、公式サイトのダウンロードページで、自分の環境を選んで表示されるコマンドを使ってください。

    # 例：EL 9 系・x86_64 の場合（URL は公式のダウンロードページで確認する）
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf -qy module disable postgresql
sudo dnf install -y postgresql18-server

# クラスタの初期化と起動
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18

    RHEL 系では、Debian 系と違ってクラスタは自動では作られないため、initdb を実行します。設定ファイルとデータは、どちらも /var/lib/pgsql/18/data/ に置かれます。

    最初の接続と文字コードの確認

    インストール直後は、OS の postgres ユーザーだけが、データベースの管理者ロール postgres として接続できます。この方式は、同じサーバー内のソケット接続で OS のユーザー名を確認する peer 認証によるものです。

    sudo -u postgres psql

    接続できたら、まずクラスタの文字コードとロケールを確認します。

    \l
SHOW server_encoding;

    Encoding が UTF8 になっていれば、日本語のデータを扱えます。Debian 系では、クラスタ作成時の OS のロケール設定が引き継がれるため、最小構成のサーバーなどで想定と違う値になっていることがあります。データを入れてからの変更は手間がかかるので、この時点で確認しておきます。

    アプリ用のユーザーとデータベースを作る

    アプリから管理者ロール postgres で接続するのは避け、アプリごとにロールとデータベースを分けます。

    # パスワードを対話で入力する（シェルの履歴に残さないため）
sudo -u postgres createuser --pwprompt appuser
sudo -u postgres createdb --owner=appuser appdb

    --owner でデータベースの所有者をアプリ用のロールにしておくと、そのロールがデータベース内でテーブルを作れます。PostgreSQL 15 以降では、public スキーマに誰でもテーブルを作れる、という以前の既定の権限が外されているため、古い手順のまま所有者を指定せずに作ると、権限エラーになることがあります。

    SQL で作る場合も、パスワードは \password で対話的に設定すると、ログや履歴に残りにくくなります。

    CREATE ROLE appuser LOGIN;
\password appuser
CREATE DATABASE appdb OWNER appuser;

    接続を受け付ける範囲を設定する

    既定では、PostgreSQL は同じサーバーからの接続（localhost）だけを受け付けます。アプリが同じサーバーにあるなら、この設定のままにしておくのが安全です。

    別のサーバーから接続する必要がある場合は、2つの設定を変えます。

    1. 待ち受けるアドレス（postgresql.conf）

    # 全アドレスではなく、必要なネットワーク側のアドレスだけを指定する
listen_addresses = 'localhost,10.0.0.5'

    この設定は再起動しないと反映されません。

    2. 接続の許可と認証方式（pg_hba.conf）

    # TYPE  DATABASE  USER     ADDRESS        METHOD
host    appdb     appuser  10.0.0.0/24    scram-sha-256

    pg_hba.conf は上から順に評価され、最初に一致した行が使われます。データベース名・ユーザー名・接続元をできるだけ絞り、認証方式には scram-sha-256 を使います。trust はパスワードなしで接続を許す設定なので、検証目的でも外部からの接続には使わないでください。古い資料にある md5 は互換のために残っている方式で、PostgreSQL 14 以降はパスワードの保存方式の既定が scram-sha-256 になっています。

    pg_hba.conf の変更は再読み込みで反映できます。

    sudo systemctl reload postgresql@18-main   # Debian 系
sudo systemctl reload postgresql-18         # RHEL 系

    あわせて、ファイアウォールでポート 5432 を接続元のネットワークだけに開けます。データベースのポートをインターネット全体に公開するのは避けてください。

    sudo ufw allow from 10.0.0.0/24 to any port 5432 proto tcp

    メモリまわりの初期値を見直す

    PostgreSQL の既定値は、小さなマシンでも起動できるよう控えめに設定されています。専用のサーバーで使うなら、最低限次の値を見直します。

    • shared_buffers：PostgreSQL が使う共有メモリ。公式ドキュメントでは、専用サーバーなら物理メモリの25%程度が出発点として挙げられています。
    • effective_cache_size：OS のファイルキャッシュも含めて、どれだけメモリが使えるかの目安。実際にメモリを確保する設定ではなく、実行計画の判断に使われます。
    • work_mem：並べ替えなどに使うメモリ。1つのクエリの中で複数回使われ、接続数分だけ掛け算で増えるため、大きくしすぎるとメモリが足りなくなります。
    ALTER SYSTEM SET shared_buffers = '1GB';
ALTER SYSTEM SET effective_cache_size = '3GB';

    ALTER SYSTEM は postgresql.auto.conf に書き込み、postgresql.conf より優先されます。shared_buffers は再起動が必要です。値はメモリ4GBの専用サーバーを想定した一例なので、同じサーバーで WordPress や PHP も動いている場合は、それらの分を差し引いて控えめにしてください。

    遅いクエリを見つけるために、log_min_duration_statement で一定時間以上かかったクエリをログに残す設定もしておくと、あとの調整に役立ちます。

    バックアップを用意してから使い始める

    最後に、データを入れる前にバックアップの手順を決めます。小規模なら、pg_dump で毎日ダンプを取り、別の場所に保存するところから始められます。

    sudo -u postgres pg_dump -Fc appdb > /backup/appdb-$(date +%Y%m%d).dump

    -Fc は独自形式で、pg_restore で一部のテーブルだけを戻すこともできます。取ったダンプを、別のサーバーやステージング環境で実際に戻せるかも確認しておきます。

    まとめ

    • OS のパッケージか PGDG のリポジトリから入れ、保守期間が長く残るメジャーバージョンを選ぶ
    • Debian 系はクラスタが自動で作られ、RHEL 系は initdb が必要。文字コードが UTF8 かを最初に確認する
    • アプリ用のロールとデータベースを分け、データベースの所有者をアプリ用ロールにする
    • 外部から接続するときは listen_addresses と pg_hba.conf を絞り、scram-sha-256 を使う
    • メモリの初期値を見直し、データを入れる前にバックアップと復元の手順を確かめる
    Views: 40

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲