Hosting: Vercel function region (iad1) vs Supabase/testers — cross-region latency

[harshitsinghbhandari]

Context

Spun out of the perf investigation in PR perf/page-load (#TBD). The code-level fixes there reduce DB round-trip count, but the dominant latency multiplier is hosting/region and is out of scope for a code PR (per the perf brief's "don't touch hosting unless provably hosting").

What was measured

Warm, anonymous requests from India against https://dev.agentlab.in/:

• Every response carries x-vercel-id: bom1::iad1 → the function executes in iad1 (US East) while testers/operator are in India (bom1 edge).
• Edge static baseline (favicon): ~0.11s.
• Each PostgREST round-trip costs ~150-200ms — consistent with cross-continent hops.

Open questions

1. Supabase's own region is unknown. The URL isn't in the client bundle (server-only/next-auth), so I couldn't confirm whether function↔Supabase is also cross-region. If Supabase is NOT in us-east, moving the Vercel function region (preferredRegion) to match it would cut every per-query RTT.
2. Operator is in India. Even with co-located function+DB, the document hop India→US is inherent to an iad1 deployment. A region closer to the primary audience (or multi-region) is a product/hosting decision.

Suggested next steps

• Confirm the Supabase project region (dashboard).
• Decide target function region(s) given the launch audience.
• Provide DB connection string / SQL-editor access so EXPLAIN ANALYZE can confirm query plans against production data (couldn't run it from the worker — no creds).

Not blocking launch correctness

Perf is a launch-quality issue. The code PR lands the surgical wins; this issue tracks the hosting lever separately.

[harshitsinghbhandari]

Spun out of PR #72 (perf/page-load). The code-level round-trip reductions landed there; this issue tracks the hosting/region lever.