Supabase Realtime は『3つの異なるユースケース』をカバー
Supabase Realtime は Postgres 変更通知・カスタムブロードキャスト・プレゼンスの3機能を提供します。本記事では編集部の視点で、深掘りした使い方を公開情報をもとに整理します。Supabase 実践 もご参考に。
3つの主要機能
(1) Postgres Changes：DB 変更通知。(2) Broadcast：カスタムメッセージ。(3) Presence：オンラインユーザー追跡。(4) WebSocket ベース。(5) JWT 認証統合。
Postgres Changes
(1) WAL 経由でDB変更を購読。(2) INSERT/UPDATE/DELETEを検知。(3) RLS 適用：自動権限制御。(4) filter：行レベルの絞り込み。(5) レイテンシ数百ms(公開情報をもとに)。PostgreSQL 実践 もご参考に。
Broadcast
(1) 任意のメッセージ送信。(2) チャンネル単位でルーティング。(3) 低レイテンシ。(4) DB 経由なし：高速。(5) チャット/コラボに最適。
Presence
(1) オンラインユーザー一覧。(2) state 同期：マウス位置等。(3) track/untrack API。(4) 分散同期：CRDT ベース。(5) マルチプレイヤーに最適。WebRTC 実践 もご参考に。
典型的なユースケース
(1) チャット：Broadcast。(2) 共同編集：Postgres + Broadcast。(3) ダッシュボード：Postgres Changes。(4) マルチプレイヤーゲーム：Presence + Broadcast。(5) 通知配信：Postgres Changes。
パフォーマンスチューニング
(1) row level filter：必要分のみ。(2) channel 数制限。(3) throttle：高頻度更新。(4) buffer 設計。(5) 監視メトリクス。Observability 実践 もご参考に。
セキュリティと RLS
(1) RLS でデータ保護。(2) JWT クレームでフィルタ。(3) service_role 経由は要注意。(4) channel 単位の認可。(5) 監査ログ。
スケールの限界
(1) 同時接続数：プラン別(公開情報をもとに)。(2) メッセージレート制限。(3) 大規模なら独自インフラ移行。(4) ロック競合：DB 負荷。(5) マネージドの利点と引き換え。
失敗しがちなパターン
(1) RLS 設定忘れ：全件購読可能に。(2) filter なし：負荷大。(3) service_role をクライアント側。(4) channel 量産：管理困難。(5) 再接続戦略不足。対策は、(1)RLS 必須、(2)WHERE 条件、(3)サーバー側のみ、(4)channel 集約、(5)exponential backoff、です。