FastAPIの初期実装は非常に快適です。しかし運用フェーズに入ると、次のような症状が出てきます。

• 一覧APIのレスポンスが急に遅くなる
• 同時接続が増えるとp95が跳ねる
• CPUは余っているのにタイムアウトが増える
• DB接続数が上限に張り付く

こうした問題の多くは「Pythonが遅い」のではなく、SQLAlchemyの使い方とDBアクセス設計 に起因します。

本記事では、FastAPI + SQLAlchemy + PostgreSQL構成を前提に、実際の改善手順を計測ベースで整理します。

1. 最初に測るべき指標

最適化は、体感ではなく数値で進めます。最低限、以下を可視化します。

• APIのp50/p95/p99レイテンシ
• エンドポイント別SQL発行回数
• 1リクエストあたりのDB滞在時間
• connection pool待ち時間
• slow query件数（200ms以上など）

OpenTelemetryやNew Relicを使っているなら、アプリspanとDB spanを必ず紐付けてください。これだけでボトルネック特定速度が上がります。

2. N+1問題を最優先で潰す

最も頻出するのがN+1です。例えばユーザー一覧でプロフィールを参照すると、ユーザー数分の追加クエリが発行されます。

2.1 悪い例

1
2
3
4
5
6
7
8

users = session.query(User).limit(100).all()
result = []
for u in users:
    result.append({
        "id": u.id,
        "name": u.name,
        "profile": u.profile.bio,
    })

2.2 改善例（joinedload/selectinload）

1
2
3
4
5
6
7
8

from sqlalchemy.orm import selectinload

users = (
    session.query(User)
    .options(selectinload(User.profile))
    .limit(100)
    .all()
)

joinedload と selectinload はデータ量で使い分けます。

• 1対1/少量: joinedload
• 1対多/件数多め: selectinload

闇雲に joinedload を増やすと行爆発が起きるため、EXPLAINで確認しながら適用します。

3. SQLAlchemy 2.xスタイルへ揃える

旧query APIと新APIが混在すると可読性と最適化精度が落ちます。2.xスタイルへ統一しましょう。

1
2
3
4
5
6
7
8
9

from sqlalchemy import select

stmt = (
    select(Order)
    .where(Order.status == "paid")
    .order_by(Order.created_at.desc())
    .limit(50)
)
orders = session.execute(stmt).scalars().all()

この形式は、EXPLAIN の追跡や再利用がしやすく、レビュー品質も上がります。

4. 必要な列だけ取る（過剰フェッチの削減）

ORMは便利ですが、何も考えずモデル全体を取ると不要データまで転送されます。特にJSONカラムやTEXTが重い場合、ここが効きます。

1
2

stmt = select(User.id, User.name, User.email).where(User.active.is_(True))
rows = session.execute(stmt).all()

一覧APIはDTO用の軽量SELECTを使い、詳細APIでのみ重いカラムを取得する設計が安定します。

5. 接続プール設定を環境に合わせる

pool_size を適当に増やすだけでは逆効果です。PostgreSQL側上限とアプリ台数を合わせて設計します。

1
2
3
4
5
6
7
8

engine = create_engine(
    DB_URL,
    pool_size=20,
    max_overflow=10,
    pool_timeout=10,
    pool_recycle=1800,
    pool_pre_ping=True,
)

設計の目安:

• DB max_connections = 300
• API Pod = 6
• 1 Podあたりpool_size 20

この時点で理論最大120接続。バッチや管理接続も見込み、余白を残すのが安全です。

6. トランザクション境界を短くする

長いトランザクションはロック競合とスループット低下を招きます。

悪い例:

1. DB更新
2. 外部API呼び出し
3. メール送信
4. commit

この順は危険です。外部I/Oをトランザクション外へ逃がします。

改善例:

1. DB更新 + commit
2. 外部通知は非同期ジョブで実行

これだけで同時処理性能が目に見えて改善します。

7. インデックス設計をAPI単位で見直す

「インデックスはある」だけでは不足です。実際のWHERE + ORDER BYに合っているかが重要です。

例: 注文履歴API

1
2
3
4
5

SELECT id, total_amount, created_at
FROM orders
WHERE user_id = $1 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

この場合、次の複合indexが有効です。

1
2

CREATE INDEX CONCURRENTLY idx_orders_user_status_created_at_desc
ON orders (user_id, status, created_at DESC);

単独indexを乱立させるより、アクセスパターンに合わせた複合indexを厳選した方が効きます。

8. キャッシュ導入は「遅い理由の解決後」に行う

キャッシュは万能ではありません。N+1やスロークエリを放置したまま載せると、整合性事故の温床になります。

導入順序:

1. SQL最適化
2. 接続プール調整
3. 必要なエンドポイントに限定してRedis cache

キャッシュキーは resource:id:version 形式にし、更新時の無効化戦略を先に定義してください。

9. 負荷試験シナリオ（k6例）

最適化の成果は負荷試験で確認します。最低3シナリオが必要です。

• steady: 通常トラフィック
• burst: 短時間ピーク
• soak: 長時間連続実行（リーク検知）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 50 },
    { duration: '1m', target: 200 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://api.example.com/orders?limit=50');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

改善前後で p95, SQL回数, DB CPU を比較し、定量で判断します。

10. 本番での改善手順テンプレート

1. ボトルネックendpointの特定
2. SQLログとEXPLAIN ANALYZE取得
3. N+1解消
4. 必要列取得へ変更
5. インデックス追加（CONCURRENTLY）
6. pool設定調整
7. 負荷試験再実施
8. 段階リリース（10%→50%→100%）

この手順を運用チーム全体でテンプレ化すると、パフォーマンス問題への対応速度が上がります。

まとめ

FastAPI + SQLAlchemyの性能改善は、派手なテクニックより 計測→原因分離→小さく改善 の積み重ねが効きます。

• N+1解消
• 過剰フェッチ削減
• 接続プール最適化
• インデックスの再設計
• 負荷試験で再検証

この5点を回せば、遅いAPIは高確率で改善できます。まずは「1リクエストあたりのSQL発行数」を可視化するところから始めるのが最短です。

付録: 改善施策の優先順位（最短で効く順）

時間が限られる現場では、まず「SQL発行回数削減 → インデックス最適化 → connection pool調整」の順で着手すると効果が出やすいです。特に、N+1解消だけでp95が半減するケースは珍しくありません。改善後は必ず同一負荷条件で再計測し、数字で効果を残しておくと、次の改善投資判断が通りやすくなります。

PostgreSQL運用で最も危険なのは「バックアップがある」という安心感です。実際の障害では、バックアップ自体より 復旧手順の不整合 で時間を失います。たとえば、WAL保管期間が足りず目標時刻に戻せない、暗号鍵が見つからず復号できない、復旧後の整合性確認が曖昧で再開判断ができない、といった問題です。

本記事では、PostgreSQLの Point-in-Time Recovery（PITR）を、机上ではなく本番レベルで回すための実装手順を解説します。pgBackRest を例にしていますが、考え方は他ツールでも共通です。

1. PITRの前提: 3つ揃わないと復旧できない

PITRは次の3要素で成立します。

1. ベースバックアップ（フルまたは差分）
2. WALアーカイブ（継続的）
3. 目標時刻情報（いつまで戻すか）

どれか1つでも欠けると成立しません。特に本番で多いのは「WALが途中で消えていた」ケースです。S3保存していても、ライフサイクル設定や権限変更で欠落することがあります。

2. まず決めるべきRTO/RPO

技術論の前に、業務要件を決めます。

• RTO（復旧に許容される時間）: 例 60分
• RPO（失ってよいデータ時間）: 例 5分

この2つで設計が変わります。

• RPO 5分以内ならWALアーカイブ遅延監視が必須
• RTO 60分以内なら復旧訓練を定期実施し、手順を自動化する必要あり

要件不明のまま「毎日バックアップ」だけ実施しても、障害時に役立たないことが多いです。

3. 推奨アーキテクチャ（単一リージョンの最小構成）

• DBサーバ: PostgreSQL 15/16
• バックアップツール: pgBackRest
• 保存先: S3互換ストレージ（バージョニングON）
• 監視: Prometheus + Alertmanager
• 復旧先: 別ホスト（本番と同一ネットワーク）

重要なのは、本番DBと別ホストで実際に復旧できること を定期検証する点です。

4. 実装手順（pgBackRest）

4.1 PostgreSQL設定

postgresql.conf 例:

wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
max_wal_senders = 10
wal_compression = on

archive_command は失敗時に非0を返す必要があります。ここが曖昧だとWAL欠落に気づけません。

4.2 pgBackRest設定

/etc/pgbackrest/pgbackrest.conf 例:

[global]
repo1-type=s3
repo1-path=/pgbackrest
repo1-s3-bucket=prod-db-backup
repo1-s3-endpoint=s3.ap-northeast-1.amazonaws.com
repo1-s3-region=ap-northeast-1
repo1-retention-full=14
start-fast=y
process-max=4
compress-type=zst

[main]
pg1-path=/var/lib/postgresql/16/main

初期化:

1
2

pgbackrest --stanza=main stanza-create
pgbackrest --stanza=main --type=full backup

4.3 WAL到達の監視

• pg_stat_archiver の failed_count
• 最終成功時刻と現在時刻の差分
• repoの最新WALタイムスタンプ

例: 10分以上WALが更新されない場合にCriticalアラート。

5. 復旧訓練（Drill）を標準化する

運用で差が出るのはここです。訓練の目的は「復旧できること」ではなく、予測可能な時間で安全に復旧できること です。

5.1 月次ドリル手順（テンプレート）

1. 目標時刻を決める（例: 当日 08:35:00 JST）
2. 復旧専用ホストを初期化
3. バックアップ + WALからリストア
4. DB起動後、整合性チェックを実行
5. アプリのスモークテストを実行
6. RTO実測値と課題を記録

5.2 実コマンド例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 復旧先でデータディレクトリを準備
systemctl stop postgresql
rm -rf /var/lib/postgresql/16/main/*

# 指定時刻までリストア
pgbackrest --stanza=main \
  --type=time \
  --target="2026-03-06 08:35:00+09" \
  --delta \
  restore

# 起動
systemctl start postgresql

PostgreSQL 12+では recovery.conf ではなく postgresql.auto.conf + standby.signal 形式に変わっている点に注意してください。

6. 復旧後の整合性チェック項目

「起動したからOK」は危険です。最低限、次を確認します。

• 主要テーブル件数（基準値との差分）
• 直近トランザクション時刻
• 重要集計値（売上、注文、在庫など）
• アプリの read/write スモークテスト
• レプリカ再構築可否

SQL例:

1
2
3

SELECT now();
SELECT max(created_at) FROM orders;
SELECT count(*) FROM users;

件数だけでなく「業務上重要な指標」を入れるのが実務的です。

7. 失敗しがちなポイントと対策

7.1 WAL保持期間が短すぎる

• 対策: RPO/RTOに基づき、最低でも7〜14日保持
• 削除はバックアップ整合性確認後に実行

7.2 暗号鍵・認証情報の保管ミス

• 対策: KMS/Secret Managerに分離保管
• 緊急時アクセス手順をRunbook化

7.3 手順が個人依存

• 対策: RunbookをGit管理
• ドリル時に“当番以外”が実行して再現性を検証

7.4 復旧はできるが遅すぎる

• 対策: 差分バックアップ頻度見直し
• 復旧先マシンスペックの最低保証
• リストア並列度（process-max）調整

8. 自動化の実装例（CIでドリルを回す）

本番同等データを使えない場合は、匿名化済みスナップショットで定期検証します。

• 毎週日曜 03:00 に復旧ジョブ起動
• 復旧後にSQLチェック + APIスモーク
• 結果をSlack/Discordへ通知
• 失敗時は翌営業日のSRE定例でレビュー

この「半自動ドリル」を導入すると、障害時の初動が劇的に安定します。

9. 監査対応のための証跡

監査や顧客説明で必要になるのは、次の証跡です。

• バックアップ成功ログ（日次）
• WAL連続性の証跡
• 復旧ドリルの実行記録（日時、担当、RTO実測）
• 改善アクション履歴

「やっています」ではなく「この月にこの結果でした」と示せる状態を作っておきましょう。

10. 現場向けチェックリスト

• フルバックアップ成功率 99%以上
• WAL遅延アラートが有効
• 目標時刻指定の復旧手順がRunbook化
• 月次ドリル実施済み
• 復旧後整合性チェックSQLが整備済み
• KMS/鍵管理手順が文書化済み

このチェックリストを満たして初めて「PITR対応」と言えます。

まとめ

PITRは設定項目の話ではなく、復旧可能性を継続的に検証する運用 です。

• RTO/RPOを先に決める
• バックアップ + WAL + 監視をセットで設計する
• 月次ドリルで実測し、Runbookを改善する
• 復旧後整合性チェックまで標準化する

バックアップがあることはゴールではありません。障害時に「何分で、どこまで戻せるか」を言える状態こそが、プロダクション品質です。

付録: 実運用で使えるPITRドリル手順（90分版）

以下は、現場でそのまま回せる最小ドリル手順です。月次で固定化すると、障害対応の心理的負荷を下げられます。

1. 開始宣言（5分）
   • 担当者、開始時刻、目標RTO/RPOをチケットに記録
2. 復旧環境準備（15分）
   • 復旧先PostgreSQLを起動
   • バックアップ世代と目標復旧時刻（例: 10:32:00 JST）を確定
3. リストア実行（25分）
   • pg_restore もしくはベースバックアップ展開
   • WAL適用完了ログを保存
4. 整合性検証（20分）
   • 件数チェックSQL、外部キー整合性、直近注文IDの連続性を確認
   • APIスモーク（ログイン/一覧/作成）を実施
5. 振り返り（25分）
   • 実測RTO/RPOを記録
   • 失敗ポイントをRunbookに即反映

重要なのは「成功したか」だけではなく、どこで何分消費したかを毎回残すことです。これを3回続けるだけで、復旧手順のボトルネックがかなり明確になります。

本番障害でよくあるのが、too many clients already や remaining connection slots are reserved です。アプリ側から見ると「急にDBに繋がらない」、ユーザー側から見ると「全機能が遅い・失敗する」という最悪の体験になります。

厄介なのは、接続枯渇が「DBサーバー性能不足」だけで起こるわけではない点です。リーク、タイムアウト設定、長時間トランザクション、プールサイズ不整合など、複数要因が重なって起きます。

この記事では、接続枯渇に対して 発生時の初動 → 根本原因の特定 → 恒久対策 の順で、手順を実務レベルでまとめます。

1. まず初動：サービス継続を優先する

障害対応では、完璧な原因究明より「止血」が先です。以下を順番に実施します。

1. 直近リリース有無を確認（機能フラグ含む）
2. アプリの接続数・待機数・エラー率を確認
3. DB側で pg_stat_activity を取得
4. 長時間実行クエリを必要に応じて停止
5. 一時的にアプリ Pod 数を制限して雪だるま増幅を止める

pg_stat_activity の基本クエリ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT
  pid,
  usename,
  application_name,
  client_addr,
  state,
  wait_event_type,
  wait_event,
  now() - query_start AS query_duration,
  now() - xact_start  AS xact_duration,
  left(query, 120) AS query_head
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY xact_start NULLS LAST, query_start NULLS LAST;

ここで見るべきは、state='idle in transaction' と異常に長い xact_duration です。これがあるとコネクションを握ったまま解放されず、枯渇の引き金になります。

2. 典型原因を4パターンで切り分ける

パターンA: アプリ接続プールサイズが過大

よくあるのが、以下のような構成です。

• Pod 20個
• 各Podのプール max 20
• 理論最大接続 400
• PostgreSQL max_connections=300

この時点で設計破綻です。さらに管理接続やメンテ接続を引くと余裕ゼロになります。

対策:

• プールサイズ設計は「全インスタンス合計」で管理
• max_connections の70〜80%以内に通常運用を収める
• ピーク時はワーカ数/Pod数で制御

パターンB: コネクションリーク

finally で close していない、ORMセッションの寿命が長い、例外時に返却されない、といった実装ミスです。

Python（SQLAlchemy）の悪い例:

1
2
3
4

session = SessionLocal()
user = session.query(User).filter(User.id == user_id).first()
# 例外時にcloseされない可能性
return user

改善例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from contextlib import contextmanager

@contextmanager
def get_session():
    session = SessionLocal()
    try:
        yield session
        session.commit()
    except Exception:
        session.rollback()
        raise
    finally:
        session.close()

FastAPI なら dependency でセッションスコープを統一し、endpointごとに確実に返却させるのが安全です。

パターンC: 長時間トランザクション

バッチ処理で 1トランザクションに大量更新を詰め込むと、ロック競合と接続占有が同時発生します。

対策:

• バッチをチャンク分割（例: 500件単位）
• statement_timeout、idle_in_transaction_session_timeout を設定
• 長時間処理はキュー化して非同期実行

パターンD: プールとDBのタイムアウト不一致

アプリの接続再利用時間が長すぎると、DB側で切断済み接続を使って失敗し、リトライで更に接続圧を上げます。

対策:

• プールの maxLifetime を DB/NLB timeout より短く
• 接続取得待ち時間（acquire timeout）を短くし、早めに失敗させる
• 失敗時リトライは指数バックオフ + ジッター

3. 具体的な設定例（PgBouncer + PostgreSQL）

高トラフィック環境では、アプリ直結より PgBouncer を挟むのが安定します。

pgbouncer.ini の例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
pool_mode = transaction
max_client_conn = 5000
default_pool_size = 80
reserve_pool_size = 20
server_reset_query = DISCARD ALL
server_idle_timeout = 30

PostgreSQL 側の最小設定例:

max_connections = 300
shared_buffers = 4GB
idle_in_transaction_session_timeout = 60000
statement_timeout = 30000
log_min_duration_statement = 1000

pool_mode=transaction は接続効率が高い一方、セッション依存機能（一時テーブルや session variable）の扱いに注意が必要です。導入前に該当クエリを洗い出してください。

4. Kubernetes運用での落とし穴

Kubernetes では、HPA がスケールアウトすると同時に接続数が急増しやすいです。

4.1 設計式を最初に決める

最大接続見積もり = maxPods × perPodPoolMax + 管理余白

例:

• maxPods=30
• perPodPoolMax=8
• 管理余白=30
• 合計 270 → max_connections=320 なら許容

この計算を IaC へコメントで残しておくと、後任が壊しにくくなります。

4.2 readiness に DB接続必須チェックを入れすぎない

Pod起動時に全Podが同時にDBへ接続テストすると、再起動時にスパイクが起きます。readiness は軽量化し、重い初期化はバックグラウンドへ逃がすのが無難です。

5. 監視項目：再発防止の最低ライン

以下を可視化し、閾値アラートを設定します。

• numbackends / max_connections
• 接続待ち時間（アプリメトリクス）
• idle in transaction セッション数
• 95/99パーセンタイルのクエリ時間
• DBエラー率（connection refused, timeout）

推奨アラート例:

• numbackends > 85% が 5分継続で Warning
• numbackends > 92% が 2分継続で Critical
• idle in transaction > 10 が 3分継続で調査開始

6. 障害後レビュー（ポストモーテム）で必ず決めること

「接続が足りませんでした」で終えると再発します。次の観点を明文化します。

1. なぜ早期検知できなかったか
2. どの設定が設計値と乖離していたか
3. コード修正・設定修正・監視修正の担当と期限
4. 次回同様インシデント時の runbook 更新点

運用改善は「学びをコード化する」ことです。ドキュメントだけでなく、Terraform や Helm values に反映して初めて再発率が下がります。

7. 実務向けチェックリスト

最後に、現場で使いやすいチェックリストを置いておきます。

• max_connections と総プール上限の関係を計算済み
• 接続リーク防止（close/return保証）が実装されている
• 長時間トランザクションに timeout が設定済み
• PgBouncer の pool_mode が要件に適合している
• numbackends と接続待ち時間のアラートがある
• 障害時 runbook に SQL コマンドと判断基準が書かれている

まとめ

PostgreSQL 接続枯渇は、単なるパラメータ不足ではなく、アプリ実装・スケーリング設計・監視不足が重なって起こる複合障害です。だからこそ、

• 初動で止血する
• パターン別に切り分ける
• 設定と実装を同時に直す
• 監視と runbook に落とし込む

この流れを徹底するだけで、同じ障害の再発率は大きく下げられます。次に障害が起きたとき、慌てず順番に潰せる状態を今日作っておくのが最善です。

PostgreSQL を長期運用すると、遅かれ早かれぶつかるのが bloat（テーブル/インデックス肥大化）です。CPU やメモリを増やしても、実体は不要領域の蓄積なので、根本原因を処理しない限り性能は戻りません。

本記事では、サービス停止なしで bloat を抑える運用を目標に、Autovacuum 設計、監視、メンテ手順を実践ベースで解説します。

1. なぜ肥大化が起きるのか

PostgreSQL は MVCC を採用しているため、UPDATE/DELETE で古い行バージョンが即時削除されません。不要バージョンは VACUUM で回収されますが、追いつかないと肥大化します。

肥大化が進むと以下が起こります。

• 同じデータ量でも I/O が増える
• インデックス探索が遅くなる
• キャッシュ効率が落ち、p95 レイテンシが悪化
• 自動メンテの時間がさらに伸びる（悪循環）

重要なのは、「遅くなってから対処」だと回復コストが高いという点です。

2. 最初に見るべき指標

運用でまず可視化するのは次の4つです。

1. n_dead_tup（死んだタプル数）
2. last_autovacuum（最後に vacuum が走った時刻）
3. テーブルサイズ・インデックスサイズ推移
4. age(relfrozenxid)（XID 消費進行）

確認クエリ例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  last_autovacuum,
  last_vacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

XID の健全性チェック:

1
2
3
4
5

SELECT
  datname,
  age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;

xid_age が高いのに vacuum が遅れている場合は、緊急度が高いです。

3. Autovacuum の基本パラメータ設計

デフォルト設定は小規模環境向けで、更新量が多い本番には不足しやすいです。まずは「全体設定 + ホットテーブル個別設定」に分けて調整します。

代表的パラメータ:

• autovacuum_max_workers
• autovacuum_naptime
• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_threshold

考え方:

• 更新頻度が高いテーブルは scale_factor を下げる（例: 0.2 → 0.02）
• 小さなテーブルは threshold 主体、大きなテーブルは scale factor 主体
• まず vacuum が「間に合う」状態を作る

個別テーブル例:

1
2
3
4
5
6

ALTER TABLE events
  SET (
    autovacuum_vacuum_scale_factor = 0.01,
    autovacuum_vacuum_threshold = 5000,
    autovacuum_analyze_scale_factor = 0.02
  );

4. インデックス肥大化の見落としに注意

テーブル側だけ見ていて、実際のボトルネックがインデックス側というケースは非常に多いです。特に更新頻度の高い B-Tree インデックスで顕著です。

実務では次を定期確認します。

• 使用頻度が低い巨大インデックス
• 重複インデックス
• インデックスサイズ増加率（週次）

重複候補を探す SQL（簡易）:

1
2
3
4
5
6

SELECT
  indexrelid::regclass AS index_name,
  indrelid::regclass AS table_name,
  pg_get_indexdef(indexrelid)
FROM pg_index
WHERE indisvalid = true;

実際は pg_stat_user_indexes と組み合わせ、idx_scan がほぼゼロのものを優先削減します。

5. REINDEX と pg_repack の使い分け

肥大化したインデックスを戻すには REINDEX が基本ですが、ロック影響を避けたい場合は REINDEX CONCURRENTLY を選びます。

• 影響小で安全重視: REINDEX INDEX CONCURRENTLY
• まとめて再編成: pg_repack（導入・権限管理が必要）

例:

1

REINDEX INDEX CONCURRENTLY idx_orders_created_at;

注意点:

• ディスク空き容量を事前確認（再構築時に追加領域が必要）
• 長時間トランザクションがあると完了しない
• 実行ウィンドウを決め、監視を付ける

6. vacuum が進まない時の切り分け

「Autovacuum が動いているのに改善しない」時は、次の順で確認します。

1. 長時間トランザクションが残っていないか
2. レプリカ遅延や hot_standby_feedback で cleanup が妨げられていないか
3. I/O 飽和で vacuum が極端に遅くなっていないか
4. freeze 対象の backlog が巨大化していないか

長時間トランザクション確認:

1
2
3
4
5

SELECT pid, usename, state, xact_start, now() - xact_start AS tx_age, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start ASC
LIMIT 20;

tx_age が長い接続は、vacuum の前進を阻害する最優先要因です。

7. 実運用で効くスケジュール設計

本番では「毎晩まとめて重い処理」より、小さく高頻度に回す方が安定します。

• 日中: autovacuum でこまめに回収
• 深夜: 重いテーブルの VACUUM (ANALYZE) を計画実行
• 週次: 重要インデックスの肥大化確認
• 月次: 上位肥大化テーブルの再編成計画レビュー

ANALYZE を外すとプランが古くなるため、統計更新を一体運用にします。

8. 典型インシデントと復旧手順

ケースA: API レイテンシ急上昇

兆候:

• CPU は高くないがクエリ時間が増加
• 特定テーブルの n_dead_tup が急増

対処:

1. 長時間トランザクションを特定
2. 対象テーブルに VACUUM (VERBOSE, ANALYZE)
3. 重度ならインデックス再構築を計画

ケースB: ストレージ逼迫

兆候:

• disk 使用率が短期間で増加
• UPDATE 多発テーブルが存在

対処:

1. サイズ上位テーブル・インデックスを抽出
2. 不要インデックス削除
3. REINDEX CONCURRENTLY / pg_repack を段階実行

ケースC: wraparound 警告

兆候:

• autovacuum: preventing wraparound ログ

対処:

1. 緊急度を最優先に切替
2. 長時間 TX を停止
3. freeze 対象テーブルを優先 vacuum

9. 導入時チェックリスト

• 上位更新テーブルに個別 autovacuum パラメータがある
• n_dead_tup と last_autovacuum を監視している
• 長時間トランザクションのアラートがある
• インデックス使用率 (idx_scan) を定期レビューしている
• REINDEX 実行時の空き容量基準を定義している
• wraparound 対応 runbook がある

10. 30日改善プラン（最短で効果を出す）

Week 1

• 現状計測（dead tuple、サイズ、xid age）
• ホットテーブル上位10件を特定

Week 2

• テーブルごとに autovacuum 個別設定
• 長時間 TX 監視アラート導入

Week 3

• 低利用/重複インデックス整理
• 対象インデックスを REINDEX CONCURRENTLY

Week 4

• 実行後の p95 クエリ時間、ストレージ増加率を比較
• 設定の再チューニングと runbook 更新

PostgreSQL の肥大化対策は、一発のメンテで終わる作業ではありません。観測 → 個別設定 → 段階的再編成 → 監視改善を繰り返すことで、停止なしでも安定して性能を維持できます。

本番運用で厄介なのは、エラーが「たまに」しか出ない障害です。PostgreSQL のデッドロックはその代表で、発生頻度は低くてもビジネス影響が大きいことが多いです。決済や在庫更新で発生すると、リトライが雪だるま式に増え、アプリ全体の遅延を引き起こします。

本記事では、デッドロック発生時に現場でそのまま使える手順を、初動対応・再現・恒久対策の順で整理します。

1. まず理解すべき前提

デッドロックは「どちらかが悪い」ではなく、ロック順序が循環したときに必ず起きる現象です。PostgreSQL は循環を検出すると、どちらか一方のトランザクションを強制中断します。

典型的な症状:

• ERROR: deadlock detected
• API の一部がランダムに 500 を返す
• リトライ実装により DB 負荷が上振れ

ここで重要なのは、単純なタイムアウトと混同しないことです。タイムアウトは待ち時間超過、デッドロックは循環待ちです。対策が違います。

2. 初動でやること（5〜15分）

2-1. エラーログの採取

まず、DB 側ログに詳細を出す設定があるか確認します。

1
2
3

SHOW log_lock_waits;
SHOW deadlock_timeout;
SHOW log_min_error_statement;

推奨設定（本番）:

log_lock_waits = on
deadlock_timeout = '1s'
log_min_error_statement = error

deadlock_timeout を短めにすることで、待ちが長引いたケースの追跡がしやすくなります。

2-2. 現在のロック状況を確認

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT
  a.pid,
  a.usename,
  a.application_name,
  a.state,
  a.query,
  l.locktype,
  l.mode,
  l.granted,
  a.query_start
FROM pg_stat_activity a
JOIN pg_locks l ON a.pid = l.pid
WHERE a.datname = current_database()
ORDER BY a.query_start;

見るべき点は「長く生きているトランザクション」と「granted = false が連鎖している箇所」です。

3. 再現手順を作る（原因特定の最短ルート）

デッドロックは再現しないと直せません。以下のような単純ケースをまず作ります。

セッション A

1
2
3
4
5

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- ここで待機
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

セッション B

1
2
3
4
5

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 2;
-- ここで待機
UPDATE accounts SET balance = balance + 50 WHERE id = 1;
COMMIT;

更新順序が逆なので、容易に循環が起きます。

この再現が取れたら、アプリコード上でも「同じテーブルを複数行更新する順序」が一定かどうかを調べます。

4. 原因の8割は「更新順序の不一致」

多くのプロダクトで見つかるのは次のパターンです。

1. バッチ処理は id ASC で更新
2. API リクエストは受信順で更新
3. 並行処理時に順序が逆転

この場合、解決策は明確で、全経路でロック取得順序を統一します。

例（Node.js / TypeScript）:

1
2
3
4
5

const ids = [fromAccountId, toAccountId].sort((a, b) => a - b);

await tx.query('SELECT id FROM accounts WHERE id = ANY($1) ORDER BY id FOR UPDATE', [ids]);

// その後に更新

FOR UPDATE を先に順序付きで取得することで、アプリ層の揺らぎを DB で吸収できます。

5. 実装レベルの対策パターン

5-1. トランザクションを短くする

デッドロックは「ロック保持時間」が長いほど発生しやすくなります。トランザクション内で外部 API 呼び出しをしていないか確認してください。これは最優先で排除します。

5-2. 失敗時のリトライを制御する

無制限リトライは障害増幅器です。指数バックオフ + 上限回数で制御します。

1
2
3
4
5
6
7
8

for (let attempt = 1; attempt <= 3; attempt++) {
  try {
    return await runTx();
  } catch (e: any) {
    if (!String(e.message).includes('deadlock detected') || attempt === 3) throw e;
    await sleep(50 * 2 ** attempt);
  }
}

5-3. 楽観ロックの導入

更新競合が多い領域では version カラムを使った楽観ロックが有効です。衝突時にアプリで再計算できます。

6. 監視・運用面の改善

恒久対策を完了させるには、再発を検知できる状態を作る必要があります。

推奨メトリクス:

• deadlock 発生回数 / 分
• lock wait 時間 p95
• 失敗リトライ回数
• 長時間トランザクション件数

SQL 例（長時間 tx 検知）:

1
2
3
4
5

SELECT pid, now() - xact_start AS tx_age, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND now() - xact_start > interval '30 seconds'
ORDER BY tx_age DESC;

この結果を可視化し、閾値超過で通知するだけでも再発時の初動が速くなります。

7. 障害対応時の意思決定フレーム

デッドロックが継続しているとき、現場は次の順序で判断すると迷いません。

1. 影響範囲（どの API / どの機能か）を確定
2. 失敗処理を一時停止できるか判断（バッチ停止、機能フラグ）
3. ロック順序統一のホットフィックス可否
4. デプロイまでの間、リトライ制御で被害抑制

「根本修正が間に合わない」ケースでも、リトライと負荷制御でユーザー影響を減らせます。

8. よくあるアンチパターン

アンチパターン1: SERIALIZABLE に上げて解決した気になる

隔離レベルを上げるだけでは、設計上の競合は消えません。むしろリトライ増加で負荷が悪化することがあります。

アンチパターン2: SELECT ... FOR UPDATE を乱用する

広範囲ロックは別の待ちを生みます。最小対象だけをロックし、順序を統一することが本質です。

アンチパターン3: アプリログだけ見て DB ログを見ない

デッドロックの循環情報は DB 側ログにしか出ないことが多いです。必ず DB ログを一次情報として扱ってください。

9. すぐ使えるチェックリスト

• deadlock detected の実例ログを保存した
• ロック状況を pg_stat_activity と pg_locks で取得した
• 再現 SQL を作成し、原因パターンを確認した
• 更新順序を全経路で統一した
• リトライ回数とバックオフを制限した
• 監視メトリクスを追加した

まとめ

PostgreSQL デッドロック対策は、魔法の設定値を探す作業ではありません。ポイントは一貫しており、

• ログで事実を取る
• 再現を作る
• ロック順序を統一する

この 3 ステップで大半の問題は改善します。障害対応時は焦って設定を増やすより、まず「どの順序で誰がロックを取ったか」を可視化することが最短ルートです。

10. チーム運用に落とし込むためのルール化

技術対策ができても、運用ルールがないと再発します。特に効果が高いのは「PR テンプレートにロック観点を入れる」ことです。たとえば 複数行更新の順序は統一されているか、トランザクション内で外部I/Oをしていないか をチェック項目にするだけで、設計時点で多くの問題を防げます。

さらに、負荷試験シナリオに競合ケース（同時更新）を追加してください。通常の性能試験は平均応答時間を見るだけで終わりがちですが、デッドロックは並行競合を作らないと検出できません。QA と開発が協調して「再現しにくい障害を再現するテスト」を用意できると、運用品質が一段上がります。

「CPUは余っているのに画面が遅い」「特定時間帯だけ API が詰まる」。この手の問題の多くは、アプリではなく SQL の実行計画に原因があります。特に PostgreSQL では、インデックス設計と統計情報の状態が性能をほぼ決めます。

本記事では、実務で使う手順に沿って、遅延クエリの改善を再現可能な形で解説します。単なる理論紹介ではなく、調査順序、判断基準、リリース時の注意点まで含めてまとめます。

まず守るべき3原則

1. 推測でインデックスを作らない 体感で追加すると write 性能とストレージが悪化します。必ず実行計画を見てから判断します。
2. 改善前後を数値で比較する P95、rows、shared read blocks を記録し、効果を証明します。
3. 本番反映は CONCURRENTLY を基本にする テーブルロックで事故らないため、CREATE INDEX CONCURRENTLY を優先します。

ケース設定：注文一覧APIが遅い

次のクエリが遅いとします。

1
2
3
4
5
6
7

SELECT id, user_id, status, total_amount, created_at
FROM orders
WHERE tenant_id = $1
  AND status IN ('paid', 'shipped')
  AND created_at >= NOW() - INTERVAL '30 days'
ORDER BY created_at DESC
LIMIT 50;

データ量は orders 1.2億件、1テナントあたり数百万件。現象は「特定テナントだけ 3〜6 秒」です。

手順1：pg_stat_statementsで優先度をつける

まずは遅い順ではなく、**影響度順（総時間）**で見るのが現場では正解です。

1
2
3
4

SELECT queryid, calls, total_exec_time, mean_exec_time, rows, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

ここで対象クエリの calls が多く、mean_exec_time が高いことを確認。改善効果が大きいと判断できます。

手順2：EXPLAIN ANALYZE BUFFERSでボトルネックを特定

1
2

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT ...;

典型的な悪い例は次の通りです。

• Seq Scan on orders
• Rows Removed by Filter が極端に多い
• Sort Method: external merge Disk（メモリ不足でディスクソート）

この状態では、絞り込み条件に合うインデックスが不足しています。

手順3：最小コストで効くインデックス設計

今回の条件は tenant_id, status, created_at です。ORDER BY も created_at DESC。したがって候補は次です。

1
2

CREATE INDEX CONCURRENTLY idx_orders_tenant_status_created_at_desc
ON orders (tenant_id, status, created_at DESC);

ここで順序が重要です。先頭列は等価条件（tenant_id）、次に低カーディナリティ条件（status）、最後に範囲・並び替え列（created_at）を置きます。

部分インデックスの検討

status が多数あるが実際に使うのが paid/shipped だけなら、部分インデックスでさらに削減できます。

1
2
3

CREATE INDEX CONCURRENTLY idx_orders_recent_paid_shipped
ON orders (tenant_id, created_at DESC)
WHERE status IN ('paid', 'shipped');

この方式はサイズが小さく、キャッシュ効率が高いのが利点です。

手順4：改善効果を検証

同一条件で再度 EXPLAIN ANALYZE を実施します。

確認ポイント:

• Index Scan か Bitmap Heap Scan に変わっているか
• 実行時間が目標値（例: 200ms 未満）に入ったか
• shared read blocks が大幅に減ったか
• rows=50 を早期に取り出せているか

改善後に 4.2 秒 → 120ms 程度まで落ちるケースは珍しくありません。

それでも遅い場合の追加施策

1) カバリングインデックス（INCLUDE）

取得列が多いとテーブルアクセスが残ります。PostgreSQL では INCLUDE が使えます。

1
2
3

CREATE INDEX CONCURRENTLY idx_orders_covering
ON orders (tenant_id, status, created_at DESC)
INCLUDE (total_amount, user_id);

2) 統計情報の更新

データ偏りが強いと planner が誤判定します。

1
2
3

ANALYZE orders;
ALTER TABLE orders ALTER COLUMN status SET STATISTICS 1000;
ANALYZE orders;

3) パーティショニング

30日検索が多いなら、月次パーティションで読み取り範囲を削るのも有効です。既存移行はコストが高いので、まずは新規データから段階導入します。

リリース時の安全手順

本番では速度改善より安全性が優先です。次の順番を守ると事故が減ります。

1. 負荷が低い時間帯を選ぶ
2. CREATE INDEX CONCURRENTLY を実行
3. 進捗確認: pg_stat_progress_create_index
4. 完了後に代表クエリで実行計画を確認
5. 監視（CPU、I/O、lock wait、replication lag）を 30 分観察
6. 不要化した旧インデックスは別日に削除

いきなり削除しない理由は、想定外クエリで回帰する可能性があるためです。1〜2日観測してから DROP INDEX CONCURRENTLY するのが安定運用です。

アンチパターン集

• LIKE '%keyword%' に B-tree インデックスを貼る
  • → pg_trgm + GIN を使う
• すべての列に単体インデックスを作る
  • → planner が迷う、write コスト増
• UUID主キーだけ見て満足する
  • → 実際の検索条件列を優先
• autovacuum 設定を放置
  • → bloat 増で index scan が遅くなる

計測テンプレート（運用向け）

改善作業を属人化しないために、次のテンプレートで記録すると再利用できます。

• 対象クエリID（pg_stat_statements）
• 改善前 mean/P95
• 改善前実行計画（テキスト保存）
• 追加したインデックスDDL
• 改善後 mean/P95
• 副作用（write増、ストレージ増、vacuum時間）
• ロールバック手順

このフォーマットをWiki化しておくと、次回の性能障害対応が非常に速くなります。

まとめ

PostgreSQL の性能改善は、魔法のパラメータよりも「再現・診断・検証」の手順で決まります。特にインデックスは効果が大きい反面、副作用もあるため、実行計画と計測値で判断することが重要です。

遅延問題に直面したら、まず pg_stat_statements で対象を絞り、EXPLAIN ANALYZE BUFFERS で事実を取り、CONCURRENTLY で安全に改善する。この流れをチーム標準にすれば、DB運用の安定性は確実に上がります。

現場で使うトラブルシュート手順（夜間障害対応向け）

実際の障害対応では、理想的な調査順序を守れないことがあります。そこで夜間当番でも使える短縮手順を用意しておくと有効です。

1. まず pg_stat_activity で待機イベントを確認（lock か I/O か）
2. 次に pg_locks で競合トランザクションを特定
3. 対象クエリの EXPLAIN (ANALYZE, BUFFERS) を取得
4. 直近デプロイ差分（SQL/マイグレーション）を確認
5. 即効性のある一時回避（statement timeout、read replica 振り分け）を実施

短期回避後に恒久対策を行う、という二段運用が安定します。

ロック競合の例

ALTER TABLE と長時間 SELECT が競合すると、アプリの体感遅延が一気に悪化します。マイグレーションは LOCK TIMEOUT を短く設定し、失敗時に即リトライしない設計にしましょう。

1
2

SET lock_timeout = '2s';
SET statement_timeout = '30s';

クエリヒントが使えない前提での工夫

PostgreSQL は MySQL のようなヒント句が限定的なため、実行計画の誘導は以下で行います。

• 統計情報を正しく更新
• 不要な関数適用を避ける（索引利用阻害）
• OR 条件を UNION ALL 分割で単純化

例えば WHERE date(created_at) = CURRENT_DATE は index を使いにくいため、次のように書き換えます。

1
2

WHERE created_at >= CURRENT_DATE
  AND created_at < CURRENT_DATE + INTERVAL '1 day'

この1点だけで scan 範囲が激減することがあります。

チーム運用に落とし込むためのルール

最後に、性能改善を個人依存にしないための運用ルールを提案します。

• 新規API追加時は必ず「想定SQL」と「必要インデックス案」を設計レビューに含める
• 週次で slow query 上位10件を確認し、改善オーナーを割り当てる
• 重要テーブルの index hit ratio と bloat 率を定期監視する

この運用が回ると、障害対応だけでなく機能開発の速度も上がります。DB 性能は裏方ではなく、プロダクト体験の中心です。

はじめに

「バックエンドの開発速度を上げたい」「認証やリアルタイム機能を手軽に実装したい」——こうした要求に応えるBaaS (Backend as a Service) は、現代のアプリケーション開発において不可欠な存在です。その代表格であるFirebaseは、多くのプロジェクトで採用され、開発者に多大な恩恵をもたらしてきました。

しかし、プロジェクトが成長し、データ構造が複雑化するにつれて、このような課題に直面したことはないでしょうか？

• 「Firebase (Firestore) のスキーマレスな性質が、逆にデータ整合性の維持を難しくしている…」
• 「複雑なデータ検索や集計を行いたいが、NoSQLのクエリでは表現力に限界がある…」
• 「ベンダーロックインが心配だ。将来的にインフラを移行する必要が出たときに、身動きが取れなくなるのではないか？」
• 「リレーショナルなデータを扱うには、Firestoreは最適とは言えないかもしれない…」

もし、あなたがこれらの課題に少しでも心当たりがあるなら、この記事はあなたのためのものです。

本記事では、「オープンソースのFirebase代替」として注目を集めるSupabaseを取り上げます。Supabaseは、単なるFirebaseのクローンではありません。その核には、40年以上の歴史と絶大な信頼性を誇るリレーショナルデータベースPostgreSQLが据えられています。

この記事を読み終える頃には、あなたはSupabaseがなぜスケーラブルで堅牢なデータベース基盤を構築するための強力な選択肢となるのか、そしてPostgreSQLの力を最大限に活用して、高速な開発と長期的な運用性を両立させる方法を深く理解できるでしょう。

なぜSupabaseが今、注目されているのか？ - 背景と課題

Supabaseの魅力を理解するためには、まずBaaS市場の変遷と、既存のサービスが抱える課題を理解する必要があります。

BaaSの進化とFirebaseがもたらした革命

かつて、Webアプリケーションを開発するには、サーバーのプロビジョニング、データベースのセットアップ、APIサーバーの実装、認証システムの構築など、多くの定型的な作業が必要でした。

BaaSは、これらのバックエンド機能を汎用的なサービスとして提供することで、開発者がフロントエンドやアプリケーションのコアロジックに集中できるようにしました。中でもGoogleのFirebaseは、直感的なAPI、リアルタイムデータベース、強力な認証機能、ホスティングまでをワンストップで提供し、特にモバイルアプリやプロトタイピングの領域で圧倒的な支持を得ました。

Firebase (Firestore) が抱えるスケーラビリティの課題

Firebaseの成功は、その手軽さと開発速度にありました。しかし、プロジェクトが成長し、エンタープライズレベルの要件が求められるようになると、そのアーキテクチャに起因するいくつかの課題が顕在化します。

1. NoSQLデータベースの限界: Firebaseの主要なデータベースであるFirestoreは、ドキュメント指向のNoSQLデータベースです。スキーマレスであるため初期開発は迅速ですが、データ間の複雑なリレーションを扱うのが苦手です。例えば、SNSアプリケーションで「ユーザー」と「投稿」と「コメント」と「いいね」が複雑に絡み合うようなデータモデルを考えたとき、正規化されたリレーショナルデータベースであればJOIN一発で取得できるデータも、Firestoreでは複数回のクエリやデータの非正規化といった工夫が必要になり、コードの複雑化やデータ冗長性を招きます。

2. クエリの表現力不足: SQLのように柔軟で強力なクエリ言語を持たないため、複雑な条件での絞り込み、集計、ソートといった操作に制限があります。GROUP BYやHAVINGのような集計関数を使いたい場合、Cloud Functionsなどを駆使して自前で実装する必要があり、リアルタイム性やパフォーマンスが犠牲になることも少なくありません。

3. ベンダーロックインへの懸念: Firebaseは非常に優れたエコシステムですが、それはGoogle Cloud Platformに深く統合されています。一度Firebaseで大規模なシステムを構築すると、データベースの移行や、他のクラウドサービスとの連携が困難になる「ベンダーロックイン」のリスクが常に伴います。データのエクスポートは可能ですが、セキュリティルールやCloud Functionsで記述したビジネスロジックまで含めた完全な移行は、極めて困難です。

これらの課題は、「開発の初期段階では最高のツールだが、長期的にスケールさせるには不安が残る」という評価につながっていました。

RDBへの回帰とSupabaseの登場

このような背景の中、開発者コミュニティでは、データの整合性、トランザクションの信頼性、そしてSQLという標準化された強力なクエリ言語を持つリレーショナルデータベース (RDB) の価値が再評価されるようになります。

そこに登場したのがSupabaseです。Supabaseは、この流れを見事に捉えました。

「世界で最も信頼されているオープンソースRDBであるPostgreSQLを使い、Firebaseのような開発者体験を提供する」

このコンセプトが、多くの開発者の心を掴んだのです。Supabaseは、BaaSの手軽さと、RDBの堅牢性・柔軟性という、これまでトレードオフの関係にあると考えられていた2つの要素を、見事に両立させました。

SupabaseのアーキテクチャとPostgreSQLの強力な機能

Supabaseが単なるデータベースサービスではないことを理解するために、そのアーキテクチャを見ていきましょう。Supabaseは、既存の優れたオープンソースツール群をPostgreSQLを中心に統合した、いわば「バックエンドのオーケストラ」です。

                    +--------------------------------+
                    |       Your Application         |
                    | (Web, Mobile, etc.)            |
                    +--------------------------------+
                           |         |         |
                           | (SDK)   | (SDK)   |
  +------------------------+---------+---------+--------------------------+
  |                   Supabase Platform (Hosted or Self-hosted)             |
  |                                                                         |
  |  +-----------+   +-------------+   +-----------+   +---------+   +----------+
  |  |  Auth     |   | Realtime    |   |  Storage  |   | Edge    |   | REST API |
  |  | (GoTrue)  |   | (Realtime)  |   | (S3-comp) |   | Functions| |(PostgREST)|
  |  +-----------+   +-------------+   +-----------+   +---------+   +----------+
  |        |                 |               |               |           |
  |        +-----------------+---------------+---------------+-----------+
  |                                    |
  |                          +---------------------+
  |                          |     PostgreSQL      |  <-- THE CORE
  |                          | (Database, RLS,     |
  |                          |  Functions, Exts)   |
  |                          +---------------------+
  +-------------------------------------------------------------------------+

• PostgreSQL: すべての中心です。単なるデータストアではなく、認証情報、セキュリティポリシー、ビジネスロジック（関数）まで、すべてがここに集約されます。
• GoTrue: JWTベースの認証サーバー。ユーザー管理とアクセストークン発行を担当します。ユーザー情報はPostgresのauth.usersテーブルに保存されます。
• PostgREST: データベーススキーマを読み取り、自動的にRESTful APIを生成します。テーブルやビューを作成するだけで、即座に対応するAPIエンドポイントが利用可能になります。
• Realtime: Postgresの論理レプリケーション機能を利用して、データベースの変更をリアルタイムにクライアントにWebSocket経由で配信します。
• Storage: S3互換のオブジェクトストレージ。Postgresを使って権限管理を行います。
• Edge Functions: Denoで書かれたサーバーレス関数。データベースに近い場所でカスタムロジックを実行できます。

このアーキテクチャの最大のポイントは、すべてがPostgreSQLに根ざしていることです。これにより、PostgreSQLが持つ強力な機能を最大限に活用できるのです。

PostgreSQLがもたらすスケーラビリティと柔軟性

SupabaseがFirebaseと一線を画すのは、このPostgreSQLの力です。具体的にどのようなメリットがあるのか見ていきましょう。

1. 厳密なスキーマとリレーション

NoSQLの柔軟性も魅力ですが、大規模なアプリケーションでは厳密なスキーマがデータの整合性を保証し、バグの温床を減らします。Supabaseでは、使い慣れたSQLでテーブルを定義できます。

例: ユーザーと投稿テーブルの作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

-- ユーザーテーブル
CREATE TABLE public.profiles (
  id UUID PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE,
  username TEXT UNIQUE NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- 投稿テーブル
CREATE TABLE public.posts (
  id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  user_id UUID NOT NULL REFERENCES public.profiles(id),
  content TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

このように、FOREIGN KEY制約を使えば、存在しないユーザーからの投稿を防ぐなど、データベースレベルでデータの整合性を担保できます。

そして、リレーショナルデータベースの真骨頂であるJOINが、その威力を発揮します。

例: 投稿とその投稿者のユーザー名を取得する (JavaScript SDK)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY);

async function fetchPostsWithUsernames() {
  const { data, error } = await supabase
    .from('posts')
    .select(`
      id,
      content,
      created_at,
      profiles (
        username
      )
    `);

  if (error) throw error;
  console.log(data);
  // 出力例:
  // [
  //   {
  //     id: 1,
  //     content: 'Hello Supabase!',
  //     created_at: '...',
  //     profiles: { username: 'user1' }
  //   }, ...
  // ]
}

Supabaseのクライアントライブラリは、リレーションを直感的に扱えるように設計されており、JOINの強力な機能を簡単に利用できます。Firestoreでこれと同じことをしようとすると、クライアント側で複数回の読み取りが必要になるケースがほとんどです。

2. 強力なセキュリティ: Row Level Security (RLS)

Supabaseのキラー機能の一つが、PostgreSQLの**Row Level Security (RLS)**です。これは、データベースの行（レコード）単位で、誰がどの操作（SELECT, INSERT, UPDATE, DELETE）を行えるかを定義できるセキュリティ機能です。

FirebaseのセキュリティルールがJSONライクな独自構文で記述するのに対し、RLSはSQLでポリシーを記述します。これにより、極めて柔軟かつ強力なアクセスコントロールが実現できます。

例1: 自分のプロフィール情報しか更新できないようにするポリシー

1
2
3
4
5
6
7
8

-- まずテーブルでRLSを有効化
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

-- UPDATEに対するポリシーを作成
CREATE POLICY "Users can update their own profile."
ON public.profiles
FOR UPDATE
USING ( auth.uid() = id ); -- 現在認証中のユーザーのIDと、行のIDが一致する場合のみ許可

例2: ログインしているユーザーは全ての投稿を閲覧でき、自分の投稿のみ削除できるポリシー

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

ALTER TABLE public.posts ENABLE ROW LEVEL SECURITY;

-- ログインユーザーは全件閲覧可能
CREATE POLICY "Allow logged-in users to read all posts."
ON public.posts
FOR SELECT
USING ( auth.role() = 'authenticated' );

-- 自分の投稿のみ削除可能
CREATE POLICY "Allow users to delete their own posts."
ON public.posts
FOR DELETE
USING ( auth.uid() = user_id );

これらのポリシーはデータベース層で強制されるため、クライアントからどのようなリクエストが来ても、不正な操作はブロックされます。PostgRESTが生成するAPIは、このRLSポリシーを自動的に尊重するため、APIサーバー側で複雑な権限チェックロジックを実装する必要がほとんどありません。

3. トランザクションとビジネスロジック

複数のデータ更新を伴う処理、例えば「銀行振込（A口座から減算し、B口座に加算する）」のような処理では、全ての操作が成功するか、全て失敗するかのどちらかでなければなりません。これを保証するのがトランザクションです。

PostgreSQLは、ACID特性に準拠した強力なトランザクション機能を備えています。Supabaseでは、PostgreSQLの関数をrpc()（Remote Procedure Call）として呼び出すことで、トランザクションを安全に実行できます。

例: 投稿に「いいね」をする関数（重複いいねを防ぐ） まず、PostgreSQLに関数を作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

-- いいねテーブル
CREATE TABLE public.likes (
  post_id BIGINT REFERENCES public.posts(id) ON DELETE CASCADE,
  user_id UUID REFERENCES public.profiles(id) ON DELETE CASCADE,
  PRIMARY KEY (post_id, user_id)
);

-- いいねを追加する関数
CREATE OR REPLACE FUNCTION like_post (post_id_to_like BIGINT)
RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
  -- すでにいいねしている場合は何もしない
  IF NOT EXISTS (SELECT 1 FROM public.likes WHERE post_id = post_id_to_like AND user_id = auth.uid()) THEN
    INSERT INTO public.likes (post_id, user_id)
    VALUES (post_id_to_like, auth.uid());
  END IF;
END;
$$;

この関数は、likesテーブルへのINSERTを試みますが、主キー制約により同じユーザーが同じ投稿に複数回いいねすることはできません。IF文で事前にチェックすることも可能です。

クライアントからは、この関数をシンプルに呼び出すだけです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

async function likePost(postId) {
  const { error } = await supabase.rpc('like_post', {
    post_id_to_like: postId
  });

  if (error) {
    console.error('Error liking post:', error);
  } else {
    console.log('Successfully liked post!');
  }
}

このように、複雑なビジネスロジックやアトミックな操作が必要な処理をデータベース関数としてカプセル化することで、クライアント側のコードはシンプルになり、セキュリティとデータ整合性も向上します。

4. 無限の拡張性: PostgreSQL Extensions

PostgreSQLのもう一つの強みは、その広大なエコシステムと拡張機能（Extensions）です。Supabaseでは、ダッシュボードからワンクリックで様々な拡張機能を有効にできます。

• PostGIS: 地理空間データを扱うためのデファクトスタンダード。位置情報を使った検索や分析がSQLで可能になります。
• pg_cron: 定期的なジョブ実行をデータベース内でスケジューリングできます（例: 毎晩0時に古いログを削除する）。
• pgvector: ベクトルデータを効率的に保存・検索するための拡張機能。AI/MLアプリケーションにおける類似検索（画像検索、推薦システムなど）に不可欠です。
• TimescaleDB: 時系列データを高速に処理するための拡張機能。IoTデータや金融データの分析基盤として利用できます。

これらはほんの一例です。FirebaseではCloud Functionsなどを駆使して外部サービスと連携する必要があるような機能も、SupabaseならPostgreSQLの拡張機能として、データベースと一体化した形で実現できる可能性があります。

Supabase vs Firebase: メリットとデメリットの徹底比較

ここで、両者を客観的に比較し、それぞれのツールの強みと弱みを整理してみましょう。

Supabaseのメリット

• データ整合性と信頼性: RDBの特性により、データの整合性を担保しやすい。
• クエリの表現力: SQLが使えるため、複雑なデータ取得や分析が容易。
• 脱ベンダーロックイン: オープンソースであり、pg_dump一発でデータをエクスポート可能。最悪の場合、自分でPostgreSQLをホストすることもできます。
• PostgreSQLエコシステムの活用: 長年培われてきたPostgreSQLのツール、知見、拡張機能という巨人の肩の上に立つことができます。
• コスト効率: 複雑なクエリをDB層で実行できるため、Cloud Functionsのように読み書きの回数で課金が増大するのを避けられる可能性があります。

Supabaseのデメリット・注意点

• RDBの知識: スキーマ設計、正規化、インデックスの知識など、RDBに関する基本的な理解が求められます。
• スケーリングの考え方: Firestoreは水平スケーリングを前提に設計されていますが、PostgreSQLのスケールは基本的には垂直スケーリング（サーバーのスペックアップ）が中心となります。もちろん、リードレプリカなどでスケールアウトも可能ですが、Firestoreとは思想が異なります。ただし、ほとんどのアプリケーションにとってPostgreSQLのパフォーマンスは十分すぎるほど高性能です。
• エコシステムの成熟度: Firebaseに比べると、コミュニティの規模やサードパーティ製のライブラリ、学習資料などはまだ発展途上な面もあります（しかし、急速に成長しています）。

現場で使える実践的なTips

Supabaseをプロダクションで活用するための、より実践的なヒントをいくつか紹介します。

1. データベースマイグレーションはCLIで管理する

Supabaseのダッシュボード上でGUIでテーブルを操作するのは手軽ですが、プロダクション環境ではスキーマの変更履歴をバージョン管理することが不可欠です。Supabaseは強力なCLIツールを提供しています。

基本的なマイグレーションフロー:

1. ローカル環境と連携:

   1 2	supabase login supabase link --project-ref <your-project-id>

2. ローカルDBのスキーマ変更をダンプ: リモート（本番）DBのスキーマ変更をローカルに反映します。

   1	supabase db pull

3. ローカルでテーブル変更などを行い、差分からマイグレーションファイルを作成:

   1 2	# 例: postsテーブルに "title" カラムを追加したとする supabase db diff -f add_title_to_posts

   これにより、supabase/migrationsディレクトリにSQLファイルが生成されます。

4. マイグレーションをリモートDBに適用:

   1	supabase db push

このフローをCI/CDパイプラインに組み込むことで、データベーススキーマの変更を安全かつ自動的に管理できます。

2. パフォーマンスチューニングの勘所: インデックスと実行計画

アプリケーションのパフォーマンスが低下してきたら、まずクエリを疑います。

• インデックスの作成: WHERE句で頻繁に検索するカラムや、JOINの結合キーとなるカラムにはインデックスを作成しましょう。Supabaseのダッシュボードには、遅いクエリを検出し、インデックス作成を推奨してくれる機能もあります。

  1 2	-- postsテーブルのuser_idカラムにインデックスを作成 CREATE INDEX idx_posts_on_user_id ON public.posts(user_id);

• 実行計画の確認: EXPLAIN ANALYZEを使うと、PostgreSQLがどのようにクエリを実行しているか（実行計画）を確認できます。Seq Scan（全件スキャン）が発生している箇所は、インデックスが効いていない可能性があり、チューニングの対象となります。

  1	EXPLAIN ANALYZE SELECT * FROM public.posts WHERE user_id = '...';

3. ビュー (VIEW) を活用してAPIをシンプルに保つ

複数のテーブルをJOINした複雑なデータ構造を頻繁にクライアントから要求される場合、ビューを作成するのが効果的です。ビューは、保存されたクエリ結果を仮想的なテーブルとして扱える機能です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

CREATE VIEW public.posts_with_username AS
SELECT
  p.id,
  p.content,
  p.created_at,
  u.username
FROM
  public.posts p
JOIN
  public.profiles u ON p.user_id = u.id;

こうすることで、クライアントからはあたかもposts_with_usernameという単一のテーブルがあるかのように見え、シンプルなクエリでデータを取得できます。RLSポリシーもビューに対して設定可能です。

1
2
3
4

// クライアント側のコードがシンプルになる
const { data, error } = await supabase
  .from('posts_with_username')
  .select('*');

4. security definer 関数で権限昇格を安全に行う

通常、rpcで呼び出される関数は、実行したユーザーの権限で動作します（security invoker）。しかし、時には関数の定義者（通常は管理者）の権限で特定の操作を行いたい場合があります。例えば、「ユーザー登録時に、プロフィールテーブルにもレコードを自動で作成する」といったケースです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

-- `auth.users`テーブルに新しい行が挿入されるたびにトリガーされる関数
CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER
LANGUAGE plpgsql
SECURITY DEFINER -- この関数を定義者の権限で実行する
SET search_path = public
AS $$
BEGIN
  INSERT INTO public.profiles (id, username)
  VALUES (new.id, new.raw_user_meta_data->>'username');
  RETURN new;
END;
$$;

-- `auth.users`テーブルへのINSERTをトリガーにする
CREATE TRIGGER on_auth_user_created
  AFTER INSERT ON auth.users
  FOR EACH ROW EXECUTE PROCEDURE public.handle_new_user();

このSECURITY DEFINERを使うと、ユーザーはprofilesテーブルへの直接のINSERT権限を持っていなくても、サインアップするだけで自動的にプロフィールが作成される、という挙動を実現できます。ただし、強力な機能であるため、SQLインジェクションなどの脆弱性を作り込まないよう細心の注意が必要です。

まとめ

本記事では、Supabaseが単なる「Firebaseの代替」ではなく、信頼と実績のあるPostgreSQLを核とした、スケーラブルで堅牢なデータベース基盤であることを、そのアーキテクチャと具体的な機能を通して解説しました。

• BaaSの手軽さ: 認証、リアルタイム、ストレージといったバックエンド機能をすぐに利用開始できます。
• RDBの堅牢性: スキーマ、リレーション、トランザクションにより、データの整合性を高いレベルで保証します。
• SQLの表現力: 複雑なデータ取得や分析も、強力で標準化されたSQLで実現できます。
• 強力なセキュリティ: Row Level Security (RLS)により、データベース層で行レベルのきめ細やかなアクセスコントロールが可能です。
• オープンソース: ベンダーロックインのリスクが低く、PostgreSQLの広大なエコシステムを最大限に活用できます。

どのようなプロジェクトにSupabaseは向いているでしょうか？

• データ整合性が最重要なアプリケーション（金融、業務システムなど）
• 複雑なクエリやデータ分析が必要なサービス（SaaS、分析ツールなど）
• 長期的な運用とスケーラビリティを見据えたプロジェクト
• 開発チームがSQLとRDBに慣れ親しんでいる場合

一方で、スキーマが固まらない超初期のプロトタイピングや、とにかく高速にシンプルなアプリを立ち上げたい場合には、依然としてFirebaseのスキーマレスなアプローチに分があるかもしれません。

しかし、今日のアプリケーション開発において、データの価値はますます高まっています。その大切なデータを、場当たり的な設計ではなく、堅牢な基盤の上で長期的に育てていきたいと考えるならば、Supabaseは検討すべき非常に有力な選択肢です。

Supabaseは、私たち開発者に「BaaSの利便性」と「本格的なデータベース管理」の二者択一を迫るのではなく、その両方を手に入れる道を示してくれました。ぜひ、次のプロジェクトでこのパワフルなデータベース基盤を体験してみてください。