The backend

What runs where

Supabase provides four things Prysm uses: managed Postgres, Auth (email code and Google), Storage, and Edge Functions written for Deno.

• Postgres holds the game catalog and every user's data, and runs the ranking, feed and notification logic.
• Auth issues the session token the app sends with every request.
• Storage keeps profile pictures and post images.
• Edge functions are the only place third-party credentials exist.

Postgres does most of the work

Search ranking, title normalisation, roulette selection, the feed, notification fan-out and the free-tier game cap are all SQL. Each rule has one implementation, in the database, so the edge functions, the seed scripts and the app cannot drift apart.

Title normalisation is the clearest example. It is a single database function, run by a trigger on every catalog insert and applied to every incoming search query. Both sides are flattened the same way, so they always compare like with like.

Three extensions carry the load:

• pg_trgm for fuzzy matching, which is what makes a typo or a half-remembered title still find the game.
• unaccent so Pokémon and Pokemon are the same word.
• pg_cron and pg_net to call scheduled functions over HTTP.

Edge functions

There are 21 edge functions, one per directory, sharing code through a common folder: the IGDB client, the shape of a catalog game, link-preview lookups, the Steam and Xbox clients, the push client and the language-model client.

They fall into groups: catalog and search, sharing, vague search, platform linking and imports, account deletion, and background work. Functions that act for a user work from that user's session. The scheduled and vendor-facing ones are closed to the app and reachable only by the systems they serve.

Scheduled sweeps

Three jobs run on a schedule. Each one is a pg_cron entry that calls an edge function.

Storage

Two public buckets: avatars (2 MB limit) for profile pictures and post-images (5 MB) for images in posts. Each user can only write inside their own folder, and the buckets accept common image types only.

Schema as code

The schema lives in SQL migrations applied in order, more than sixty of them, so the tables, policies and functions can be rebuilt from the repository. The one exception is the sweep schedules, which are set up separately because they reference credentials that must not be committed.

Bulk work such as seeding the catalog runs in Node scripts, not inside edge functions, because edge functions have CPU and time limits that a bulk load would exceed. Each feature also has a verification script that exercises it against real signed-in test users.