amara_v git.example.com/amara-okoye/plot-allotment ↗
120 plots, applications every spring, three seasons of history in one applications table. The coordinator page lists this year's applicants with the plot and the applicant name, and takes about 15 seconds. Replit builds it by fetching applications and then looking up the plot and the person for each row in a loop.
One caution on the join version: if a plot or a profile row is missing, the nested select returns null for that side rather than dropping the application, which is what you want here but means the page has to render a blank name instead of crashing. Worth a fallback in the cell, since three years of history almost certainly contains a member who has since been deleted.
That loop is the whole 15 seconds. One query for the list plus two per row is 241 round trips for 120 applicants, and each one pays the network latency to the database.
Fetch it in one query and let Postgres do the joining:
const { data } = await supabase.from('applications')
.select('id, status, created_at, plots(number), profiles(full_name)')
.eq('season', 2026)That is a single request and it will come back in tens of milliseconds. Then add create index on applications (season, status) so the season filter does not scan three years of rows. Three seasons is small enough that the index is a nicety today and the join is the real fix.