こんにちは！開発現場の裏側で、データベースやAPIのインフラ周りを整えるのが大好きな先輩エンジニアです。
今回は、PostgreSQLを触るなら必ずと言っていいほどお世話になるWebベースのGUIクライアント「pgAdmin 4」の、ちょっと危うい「裏側の秘密」についてお話しします。
「pgAdmin 4をサーバーモード（複数人で共有するモード）で長期間動かしていたら、ある日突然サーバーのディスクがパンクした……」
そんな恐怖の体験をしたことはありませんか？ 原因の多くは、ログでもPostgreSQLのデータでもなく、pgAdmin自身がこっそり溜め込んでいるセッションファイルとログの肥大化です。
これをマスターすれば、深夜の容量アラートに怯えることも、謎のディスク圧迫に頭を悩ませることもなくなりますよ。さあ、一緒にその仕組みと対策を紐解いていきましょう！
—
そもそも「pgAdmin 4」とは何をするツールなのか？
初心者の方に向けて少しだけ整理しておくと、pgAdmin 4はPostgreSQLデータベースを視覚的に操作・管理するための強力なWebクライアントです。
従来のデスクトップアプリ型（pgAdmin 3など）とは異なり、pgAdmin 4は内部でPython（Flask）製のエコシステムを動かす「Webアプリケーション」として設計されています。そのため、個人のPCにサクッと入れる「デスクトップモード」だけでなく、チーム共有用の「サーバーモード（Webサーバー上でホストする方式）」としても運用できるのが大きな特徴です。
初めてのインストールと、絶対に外せない「基礎セットアップ」
もしこれからサーバーモードでpgAdmin 4を構築するなら、Dockerを使うのが現代のベストプラクティスです。余計な依存関係でOSを汚しません。
以下の `docker-compose.yml` を見てください。これがプロダクション運用の最短にして最強のスタートラインです。
version: ‘3.8’
services:
pgadmin:
image: dpage/pgadmin4:latest
container_name: pgadmin4_production
restart: always
environment:
# 初期管理者アカウントの設定（必ず変更してください）
PGADMIN_DEFAULT_EMAIL: “admin@example.com”
PGADMIN_DEFAULT_PASSWORD: “SuperSecretPassword123”
# サーバーモードで起動するための指定
PGADMIN_LISTEN_PORT: 80
ports:
- “8080:80”
volumes:
# 【重要】データとセッションを永続化するためのボリュームマウント
- pgadmin_data:/var/lib/pgadmin
volumes:
pgadmin_data:
external: false
これを `docker-compose up -d` で立ち上げれば、`http://localhost:8080` にアクセスして「Hello, World!」ならぬ、ピカピカのPostgreSQL管理画面に出会えます。
—
なぜ起きる？ ディスクをジワジワと蝕む「ストレージ肥大化」のメカニズム
さて、ここからが本題です。
先ほどの `docker-compose.yml` でマウントした `/var/lib/pgadmin` ディレクトリ。ここには、あなたが実行したクエリの履歴、保存したサーバー接続情報、そしてユーザーのログインセッション情報が保存されます。
サーバーモードで運用していると、以下の2つの要因でストレージが爆発的に肥大化します。
1. SQLiteセッションDBの肥大化
pgAdmin 4は、内部のメタデータやセッション管理に軽量なRDBであるSQLite（通常 `sess.db` など）を使用しています。ユーザーがブラウザでログインし、作業し、ブラウザを閉じ……という日常の裏で、古いセッションデータがゴミ（ゴミデータ）としてSQLiteの中に残存し続けます。これが掃除されないまま数ヶ月経つと、数百MB、ひどい時には数GBの「中身がほぼゴミのDBファイル」に成長します。
2. ログファイルの野放し増加
PythonのFlaskログやGunicornのエラーログがローテーション（古いものを自動削除する仕組み）されず、一つのファイルに無限に追記され続けることがあります。
—
撃退法：セッションファイルの自動クリーンアップとログローテーション
この肥大化を防ぐには、「ため込まない仕組み」をあらかじめ設定しておく必要があります。現場のエンジニアが実践している具体的な対策を見ていきましょう。
1. 設定ファイル（`config_local.py`）でセッションの寿命を制御する
pgAdmin 4には、デフォルトの挙動を上書きするための設定ファイル（`config_local.py`）を読み込ませる機能があります。ここに「古いセッションをどれくらいの期間で自動パージ（削除）するか」のパラメータを記述します。
コンテナの `/pgadmin4/config_local.py` として以下の設定をマウントするか、配置します。
==========================================
pgAdmin 4 カスタム設定ファイル
==========================================
セッションの有効期限を明示的に設定（例: 7日間で期限切れにする）
これにより、放置された古いセッションが自動的にクリーンアップ対象になります。
PERMANENT_SESSION_LIFETIME = 86400 7 # 秒単位（7日）
セッションデータベースの自動VACUUM（最適化）を促進する設定
SQLiteはデータを削除してもファイルサイズが縮小しない（領域が空きにならない）特性があるため、
定期的なVACUUMが必要になります。
2. 定期的なSQLiteの `VACUUM` メンテナンス（シェルスクリプト）
SQLiteの厄介なところは、`DELETE` 文でデータを消しても「ファイルの物理サイズが縮小しない」という点です。空いた領域は内部の再利用のために取っておかれますが、長期間の運用で断片化が進み、無駄にディスクを食いつぶします。
そのため、外側から定期的に `VACUUM`（データベースのデフラグ＆容量圧縮）を実行するcronジョブを組むのがプロの技です。
以下のようなメンテナンススクリプト（`vacuum_pgadmin.sh`）をホストOS側に用意します。
!/bin/bash
=================================================================
pgAdmin 4 の SQLiteセッションDBを最適化（VACUUM）するスクリプト
=================================================================
Dockerボリューム内のSQLiteファイルパスを特定（環境に合わせて変更してください）
※Docker名前付きボリュームの実際のパスは /var/lib/docker/volumes/… ですが、
コンテナ経由で実行するのが最も安全です。
CONTAINER_NAME=”pgadmin4_production”
DB_PATH=”/var/lib/pgadmin/sess.db”
echo “[$(date)] pgAdminセッションDBの最適化を開始します…”
コンテナ内でsqlite3コマンドを使い、VACUUMを実行して断片化を解消する
docker exec -i $CONTAINER_NAME sqlite3 $DB_PATH “VACUUM;”
if [ $? -eq 0 ]; then
echo “[$(date)] 成功: SQLiteデータベースの最適化と容量解放が完了しました。”
else
echo “[$(date)] エラー: 最期に失敗しました。” >&2
exit 1
fi
このスクリプトに実行権限を与え (`chmod +x vacuum_pgadmin.sh`)、ホストOSの `crontab` に登録します。
毎月1日の深夜3時に自動でストレージをスリム化する
0 3 1 /path/to/vacuum_pgadmin.sh >> /var/log/pgadmin_maintenance.log 2>&1
これで、ディスクが勝手にパンクする悪夢から解放されます。
—
まとめ：スマートな運用が、エンジニアの心を軽くする
今回は、pgAdmin 4のサーバーモード運用において避けて通れない「ストレージ肥大化問題」と、その具体的な対策について解説しました。
- pgAdmin 4は内部でSQLiteのセッションDBを持っており、放置すると肥大化する。
- セッションのライフタイムを適切に設定し、古いゴミを残さない。
- SQLite特有の仕様（削除してもファイルサイズが縮小しない）に対し、定期的な `VACUUM` で物理容量を解放する。
ツールは「ただ動かす」だけでなく、「健全な状態で長く回り続けるようにデザインする」ところにエンジニアの腕の見せ所があります。ぜひ今回の設定をあなたのインフラ環境にも取り入れて、快適なデータベース管理ライフを送ってくださいね！