リージョンとレイテンシ
Drizzle はクエリを1本ずつ往復させるので、速さは『アプリとDBの距離』で決まる。東京リージョンの有無より、まず両者を同一リージョンに同居させるのが最優先
Web アプリの速さを決めるのは、ユーザーとの距離よりアプリと DB の距離です。まず両者を同じリージョンに置く『同居』が最優先です。
- クエリは 1 本ずつ往復 — 10 本なら距離の差も 10 倍
- 同一リージョン内 1〜2ms、東京↔シンガポール約 70ms
- 東京同居なら Supabase、Neon 継続なら海外同居
Web アプリはどこに置けば速くなる?
Web アプリを公開するとき、つい『利用者に近い場所に置けば速い』と考えがちです。CDN で配る静的なサイトならそれで正解ですが、画面のたびに DB へ何度も問い合わせるアプリでは、効いてくる距離が変わります。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
クエリのたびに海を越える — 10 本なら遅れも 10 倍
この図をテキストで読む
構成図「アプリとDBを「離す」か「同じ場所に置く」か」。ブロック6個、つながり4本。 枠: 離して置く（別リージョン）（ブロック3個）、同じ場所に置く（同居）（ブロック3個）。 【ブロック】 - 日本のユーザー: 東京付近にいる - アプリ（東京）: ap-northeast-1 - DB（別リージョン）: 例: シンガポール - アプリ: DBと同じリージョン - DB: アプリの隣 - 日本のユーザー: 遠いのは最初だけ 【流れ】 - ❌ 離す：クエリのたびに長距離（×N）: 日本のユーザー → アプリ（東京） → DB（別リージョン） - ✅ 同居：長距離は最初の1回だけ: アプリ → DB → 日本のユーザー
配置パターンでレイテンシはこう変わる（早見表）
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。3列 × 5行。 【列】 1. A. 東京＋遠いDB（分離（なりがち）） 2. B. 海外で同居（例: シンガポール） 3. C. 東京で同居（Supabase Tokyo 等） 【比較】（観点ごとに） ■ アプリとDBの配置 - A. 東京＋遠いDB: 東京 / 遠い / 別リージョン - B. 海外で同居: 海外 / 同じ海外 / 同一リージョン - C. 東京で同居: 東京 / 東京 / 同一リージョン ■ ユーザー→アプリ - A. 東京＋遠いDB: 約5ms / ユーザーに近い - B. 海外で同居: 約70ms / 日本→海外 - C. 東京で同居: 約5ms / ユーザーに近い ■ アプリ→DB（10クエリ） - A. 東京＋遠いDB: 約700ms / 10×約70ms - B. 海外で同居: 約10ms / 10×約1ms - C. 東京で同居: 約10ms / 10×約1ms ■ 体感の合計 - A. 東京＋遠いDB: 約700ms超 / 遅い - B. 海外で同居: 約80ms / 速い - C. 東京で同居: 約15ms / 最速 ■ 評価 - A. 東京＋遠いDB: ✗ 分離は最悪 / 近づけたつもりで逆効果 - B. 海外で同居: ○ 同居で良好 / Aより速い - C. 東京で同居: ◎ 同居＋東京で最速 / 理論上のベスト 【観点】 - A を見る: A. 東京＋遠いDB - B を見る: B. 海外で同居 - C を見る: C. 東京で同居
Neon と Supabase を見くらべる（早見表）
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 6行。 【列】 1. Neon（現状採用） 2. Supabase（比較対象） 【比較】（観点ごとに） ■ 東京リージョン - Neon: なし / 最寄りは Singapore - Supabase: あり / ap-northeast-1 ■ APACの最寄り - Neon: Singapore / Sydney / 東京から約70ms - Supabase: Tokyo・Singapore 他 / 東京を選べる ■ Drizzle の接続 - Neon: neon-http / postgres.js / HTTPドライバが軽い - Supabase: Supavisor プーラ / transaction mode (6543) ■ サーバーレス相性 - Neon: HTTPで枯れにくい / Lambda 向き - Supabase: プーラで吸収 / 6543 を使う ■ ブランチ / 自動停止 - Neon: ◎ ブランチ＋scale to zero / POC・多テナント向き - Supabase: △ ブランチは弱め / 有料は常時起動寄り ■ 乗り換えコスト - Neon: ゼロ（現状維持） / SSL等チューニング済み - Supabase: 移行コストあり / 接続方式の作り替え 【観点】 - Neon を見る: Neon - Supabase を見る: Supabase
まず同居、リージョンは次
最初に決めるのは Neon か Supabase かではなく、アプリと DB を同じリージョンに置くことです。現状は Neon 採用なので、アプリを Neon と同じリージョンへ寄せるのが移行コストゼロの最短ルート。東京の体感が重要になったら Supabase 東京への移行を検討します。
押さえておきたい用語
- リージョン
- クラウドのデータセンターがある地域（東京＝ap-northeast-1 など）。アプリや DB を置く場所を選ぶ単位。
- レイテンシ / RTT
- 通信の往復にかかる時間（Round Trip Time）。同一リージョン内は1〜2ms、東京↔シンガポールは約70msと、ほぼ距離で決まる。
- co-location（同居）
- アプリと DB を同じリージョンに置くこと。クエリ往復を短くする最大の手。
- クエリのバッチ
- 複数の SQL を1往復にまとめて送ること。Drizzle は自動ではまとめないので、Promise.all などで明示的に書く。
- エッジ実行
- 利用者に近い世界中の拠点でコードを動かす方式。DB をあまり叩かない配信向き。DB ヘビーなアプリでは、DB の隣の単一リージョンで動かす方が速い。
- コネクションプーラ
- 多数の接続を束ねて DB の接続枯渇を防ぐ仕組み。Supabase は Supavisor（ポート6543）経由、Neon は HTTP ドライバでも枯渇を避けられる。
ここから先へ
この解説とつながりのあるページ