DB connection scaling: verify Supavisor txn-pooler + query-shape pass (pre-scale)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-19
• wi-cli-venus commented · 2026-06-19
  Plan of record from 3-PM brainstorm bs-mql6t5a7bg7 (coordinated 3-app WI; parallels MARS-145; venus already on Supavisor). Pluto legs: (A) VERIFY Vercel prod DATABASE_URL host = Supavisor *.pooler.supabase.com:6543 (txn mode); migrate if not. BLOCKED: Vercel prod env is type=Encrypted, unreadable by any agent. Readable config (venus .env.local) shows legacy db.<ref>.supabase.co:6543 (legacy PgBouncer, being sunset) — port 6543 alone != Supavisor, the HOST distinguishes. Needs Vercel-dashboard read or Elazar. Region per venus-port memory = aws-1-sa-east-1. (B) Pool-max: NO CHANGE. Pluto DB_POOL_MAX=2 is correct/deliberate (traditional serverless, Fluid OFF, 1 req/container). Sizing: max_connections=60, ~44 headroom / 2 = ~22 safe concurrent instances (vs venus@10 ~4, mars@16 ~3.5). Pluto is the model. (B-durable) Query-shape pass: collapse wide per-request fan-outs into set-based SQL/RPC/views (push-compute-to-Postgres). mapWithConcurrency limiter (DB_POOL_MAX) is the STOPGAP; this is the real fix. Targets: /informes, /practicas, /alumnos. (C) Supabase paid-tier upgrade trigger before scale — needs Elazar's Supabase token (free tier caps conns+egress). Priority P2: Pluto currently healthy (22-instance headroom, live 16/60, 1 active) — pre-scale hardening, not an outage. A blocked on Elazar; B done; B-durable is the substantive coder/db work.
• wi-cli-venus commented · 2026-06-19
  TEMPLATE from venus EVO-6 (SHA 0711a66): venus collapsed getPracticaLookups from ~10 concurrent pool.query into ONE json-CTE (1 conn + 1 RTT) on the hot práctica-form path, eliminating the pool-acquire-timeout class at the source + a latency win. Pluto has the same getPracticaLookups-style fan-out — this is the proven query-shape pattern for Pluto's leg of this WI (the durable 'collapse wide per-request fan-outs to set-based SQL' layer; the DB_POOL_MAX limiter is only the stopgap). Per-lookup SQL stayed byte-equivalent (same views/columns/ORDER BY). Mirror under this WI when scheduled.
• wi-cli-venus commented · 6w ago
  Pool-headroom lever noted (from PLUTO-189 close): pg-pool max:2 is deliberately tiny for serverless; a single-user burst on /practicas + /practicas/[id] can starve concurrent renders on pool-acquire. The real fix is cheaper queries (PLUTO-471 option-query cost + 472 caching), but if scaling needs belt-and-suspenders, raising max with Supavisor txn-pooler headroom is the lever to evaluate here — coder can scope on request.