supabase-admin

Supabase 管理のエキスパート

本番アプリケーション向けに、Supabase のスキーマ設計、Row Level Security ポリシー、マイグレーション、パフォーマンス最適化を習得します。

使用する場面

✅ このスキルを使用する場面：

• Row Level Security（RLS）ポリシーの設計とデバッグ
• データベースのマイグレーションとスキーマ変更
• Auth の統合（トリガー、プロフィールの作成）
• クエリのパフォーマンス最適化
• Supabase 固有の SQL パターン（auth.uid()、auth.jwt()）

❌ 使用しない場面：

• Supabase Auth UI の設定 → Supabase ダッシュボードのドキュメントを使用してください
• Edge Functions → cloudflare-worker-dev スキルを使用してください
• Supabase のコンテキストがない一般的な PostgreSQL → 標準の SQL リソースを使用してください
• クライアント側の Supabase SDK の使用 → Supabase JS ドキュメントを使用してください

主な専門分野

1. Row Level Security（RLS）

ユーザーテーブルでは常に RLS を有効にします：

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

ポリシーパターン：

-- Public read, authenticated write
CREATE POLICY "Public read" ON posts FOR SELECT USING (true);
CREATE POLICY "Owners can write" ON posts FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Owner-only access
CREATE POLICY "Users own their data" ON profiles
  FOR ALL USING (auth.uid() = id);

-- Role-based access
CREATE POLICY "Admins can do anything" ON content
  FOR ALL USING (
    EXISTS (
      SELECT 1 FROM profiles
      WHERE profiles.id = auth.uid()
      AND profiles.role = 'admin'
    )
  );

パフォーマンスが重要な場合：auth.uid() 列にインデックスを作成します：

-- 100x performance improvement for RLS policies
CREATE INDEX idx_posts_user_id ON posts(user_id);
CREATE INDEX idx_profiles_id ON profiles(id);

JWT 関数のサブクエリ最適化：

-- BAD: JWT parsed for every row
CREATE POLICY "slow" ON posts FOR SELECT
  USING (user_id = auth.uid());

-- GOOD: JWT parsed once via subquery
CREATE POLICY "fast" ON posts FOR SELECT
  USING (user_id = (SELECT auth.uid()));

2. マイグレーションのベストプラクティス

ファイルの命名規則：

supabase/migrations/
├── 001_initial_schema.sql
├── 002_add_profiles_trigger.sql
├── 003_forum_tables.sql
└── 004_add_rls_policies.sql

マイグレーションのテンプレート：

-- Migration: 005_feature_name
-- Description: What this migration does
-- Author: name
-- Date: YYYY-MM-DD

-- Up migration
BEGIN;

-- Your DDL here
CREATE TABLE ...;
ALTER TABLE ...;
CREATE POLICY ...;

COMMIT;

-- Down migration (as comment for reference)
-- DROP TABLE ...;
-- DROP POLICY ...;

安全なマイグレーションパターン：

-- Add column with default (no table lock)
ALTER TABLE users ADD COLUMN status text DEFAULT 'active';

-- Add NOT NULL constraint safely
ALTER TABLE users ADD COLUMN email text;
UPDATE users SET email = '[email protected]' WHERE email IS NULL;
ALTER TABLE users ALTER COLUMN email SET NOT NULL;

-- Create index concurrently (no lock)
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

3. Auth の統合

サインアップ時にプロフィールを自動作成：

-- Function to create profile
CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO public.profiles (id, email, display_name)
  VALUES (
    NEW.id,
    NEW.email,
    COALESCE(NEW.raw_user_meta_data->>'display_name', split_part(NEW.email, '@', 1))
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

-- Trigger on auth.users
CREATE TRIGGER on_auth_user_created
  AFTER INSERT ON auth.users
  FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

ポリシーで Auth の状態を確認：

-- Authenticated users only
CREATE POLICY "Authenticated access" ON data
  FOR SELECT USING (auth.role() = 'authenticated');

-- Get current user's ID
SELECT auth.uid();

-- Get current user's JWT claims
SELECT auth.jwt();

4. 一般的なスキーマパターン

デフォルト値付きのタイムスタンプ：

CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid REFERENCES auth.users(id) ON DELETE CASCADE,
  content text NOT NULL,
  created_at timestamptz DEFAULT now(),
  updated_at timestamptz DEFAULT now()
);

-- Auto-update updated_at
CREATE OR REPLACE FUNCTION update_updated_at()
RETURNS TRIGGER AS $$
BEGIN
  NEW.updated_at = now();
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER update_posts_updated_at
  BEFORE UPDATE ON posts
  FOR EACH ROW EXECUTE FUNCTION update_updated_at();

ソフトデリートパターン：

ALTER TABLE posts ADD COLUMN deleted_at timestamptz;

CREATE POLICY "Hide deleted" ON posts
  FOR SELECT USING (deleted_at IS NULL);

全文検索：

-- Add search vector column
ALTER TABLE posts ADD COLUMN search_vector tsvector;

-- Create GIN index
CREATE INDEX idx_posts_search ON posts USING GIN(search_vector);

-- Update function
CREATE OR REPLACE FUNCTION posts_search_update()
RETURNS TRIGGER AS $$
BEGIN
  NEW.search_vector := to_tsvector('english', COALESCE(NEW.title, '') || ' ' || COALESCE(NEW.content, ''));
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Search query
SELECT * FROM posts
WHERE search_vector @@ plainto_tsquery('english', 'search terms');

5. RLS の問題のデバッグ

よくある問題：結果が空で、エラーも表示されない

-- Check if RLS is enabled
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';

-- List all policies
SELECT * FROM pg_policies WHERE tablename = 'your_table';

-- Test as specific role
SET ROLE anon;
SELECT * FROM your_table LIMIT 1;
RESET ROLE;

-- Test with specific user
SET request.jwt.claims TO '{"sub": "user-uuid-here"}';
SELECT * FROM your_table;

診断クエリ：

-- Check what the current user can see
SELECT
  auth.uid() as current_user,
  auth.role() as current_role,
  (SELECT count(*) FROM your_table) as visible_rows;

クイックリファレンス

タスク	コマンド
RLS を有効化	ALTER TABLE t ENABLE ROW LEVEL SECURITY;
ポリシーを作成	CREATE POLICY "name" ON t FOR action USING (condition);
ポリシーを削除	DROP POLICY "name" ON t;
ポリシーを確認	SELECT * FROM pg_policies WHERE tablename = 't';
現在のユーザー	SELECT auth.uid();
所有者に RLS を強制	ALTER TABLE t FORCE ROW LEVEL SECURITY;

参考資料

詳しいガイドは /references/ を参照してください：

• rls-patterns.md - 高度な RLS ポリシーパターン
• migration-checklist.md - デプロイ前のチェックリスト
• performance-tuning.md - クエリとインデックスの最適化
• social-schema.md - ソーシャル機能向けのスキーマパターン