Supabaseのリージョンをムンバイから東京へ移行した結果、DBレイテンシが1/3に改善した詳細な手順とハマりポイント
本記事は、個人開発の日本株分析サービス「株AI分析」を運営する大学生が、バックエンドサービスSupabaseのリージョンをムンバイ（インド）から東京へ移行した経験を詳細に記した技術解説記事である。サービスは日本ユーザー向けであるにもかかわらず、初期設定時にSupabaseのリージョンがMumbai (ap-south-1)に設定されていたため、日本からのAPIリクエストが「日本 → Render origin（米国 or シンガポール）→ Supabase Mumbai → DB」という長距離経路を辿り、大きなレイテンシ（遅延）が発生していた。具体的には、日本とMumbai間の往復遅延（RTT）が130〜150msに達し、ユーザー体験を著しく損なっていた。これを東京リージョンへ移行した結果、DBレイテンシは大幅に改善し、複数のクエリを叩く画面での体感速度が劇的に向上した。
移行手順は、Supabaseが既存プロジェクトのリージョン変更をサポートしていないため、新プロジェクトを東京リージョンで作成し、スキーマ、RLSポリシー、認証設定、APIキーの再設定といった手動の切り替え作業が必要であった。筆者は、ユーザーが0人というタイミングを最大限に利用し、データ移行をスキップして空のDBに切り替えることで作業を簡略化した。
記事では、移行過程で遭遇した複数の「ハマりポイント」を詳細に解説している。一つ目は、APIキーのURLをダッシュボードURLと誤認し、誤った形式で環境変数に貼り付けてしまうミス。正しくはプロジェクトIDから`.supabase.co`を付与する必要がある。二つ目は、APIキーの形式が旧式のJWT形式から新しい`sb_publishable_`や`sb_secret_`形式に変わっている点。三つ目は、セキュリティ設定で「Automatically expose new tables」をOFFにした際に、新規テーブルへの権限（GRANT）が自動付与されないため、手動で`GRANT ALL`などのSQLを実行する必要がある点。最後に、初回サインアップのメールテンプレート（Confirm signup）が、想定のOTPコード形式になっていなかったため、テンプレートの書き換えが必要であった。
移行後の効果として、`/api/watchlist`のGETリクエストは380msから130msへ、`/api/portfolio`のGETリクエストは520msから200msへと、それぞれ大幅な改善を達成し、サービス全体の体感速度が向上した。
背景
本ニュースは、個人開発者がバックエンドサービスSupabaseを利用する際、リージョン選択の重要性とその影響を実体験に基づいて解説した技術記事である。初期設定のミス（リージョン選択）が、サービスのパフォーマンスに致命的な遅延（レイテンシ）を引き起こすという具体的な問題提起から始まっている。
重要用語解説
- Supabase: オープンソースのFirebase代替サービス。データベース、認証、ストレージなど、Webアプリケーション開発に必要なバックエンド機能一式を提供するプラットフォーム。
- レイテンシ (Latency): データが送信元から目的地に到達するまでにかかる時間遅延のこと。この記事では、地理的な距離がレイテンシに与える影響を指摘している。
- RLS (Row Level Security): データベースのセキュリティ機能の一つ。テーブル全体ではなく、行（レコード）単位でアクセス権限を制御し、ユーザーごとに表示できるデータを制限する仕組み。セキュリティ強化に必須である。
今後の影響
個人開発者やスタートアップにとって、バックエンドサービスのリージョン選択は、ユーザー体験（UX）に直結する極めて重要な要素となる。本記事は、単なる技術解説に留まらず、開発初期段階での設計ミスを防ぐための具体的なチェックリストを提供しており、今後の開発プロセス全体に影響を与える知見となる。