Supabase — the database under Focaccia VoteConcept

Supabase is a hosted Postgres database with an admin dashboard and an instant API bolted on. Today you learn what that actually means — what Postgres is, what a table and a row are — by reading the real votes table Focaccia Vote has been writing to.

Postgres is a database engine — a program whose whole job is to store structured data and answer questions about it fast. Think of it as a folder of ruthlessly organized spreadsheets: each <strong>table</strong> is one sheet (votes, users, candidates), each <strong>column</strong> is a typed field (a timestamp, a piece of text, a number — and the type is enforced, you cannot put 'banana' in a date column), and each <strong>row</strong> is one record — one vote, one user, one event. That's 90% of the mental model.

Supabase is not a different database — it's Postgres that someone else runs for you, wrapped in three conveniences: a web dashboard so you can browse tables without writing code, an auto-generated API so your app can read/write rows over HTTPS with one JS call, and a bundled auth system. When Focaccia Vote 'saves a vote', it's really making an HTTPS call to Supabase's API, which inserts one row into the <code>votes</code> table. No server of your own anywhere — that's why it's the DB + Auth default in your stack doc.

The failure mode to respect: the API is reachable by anyone on the internet, and what stops a stranger from reading or spam-writing your table is <strong>Row Level Security (RLS)</strong> — per-table rules about who may do what. A table with RLS off and a public anon key is an open guestbook. You don't need to master RLS today; you need to know it exists and check whether your votes table has it on.

Worked example

Three queries to run in the Supabase SQL Editor (dashboard → SQL Editor → New query) — each answers something the app's UI can't:

-- 1. How many votes total?
select count(*) from votes;

-- 2. The five most recent votes, newest first
select * from votes
order by created_at desc
limit 5;

-- 3. What columns does the table actually have?
select column_name, data_type
from information_schema.columns
where table_name = 'votes';

• count(*) collapses the whole table to a single number — the canonical 'is data actually landing?' check. This is the verify-the-side-effect rule from your automation hygiene doc, applied to a database.
• order by created_at desc limit 5 is the SQL idiom you'll use constantly: sort by the timestamp column, newest first, and only show 5. select * means 'all columns'.
• Query 3 reads Postgres's own catalog — the database describing itself. information_schema is a built-in set of tables ABOUT your tables; this is how you discover a schema you didn't write down.

Gotchas

• Two API keys live in Settings → API: the <strong>anon</strong> key (safe-ish to ship in a public app, RLS is what protects you) and the <strong>service_role</strong> key (bypasses ALL security — never put it in frontend code, a repo, or a chat).
• Supabase's free tier pauses projects after about a week with no traffic. A paused project means the app's reads/writes silently fail until you wake it from the dashboard — if Focaccia Vote ever 'just stops working', check this first.
• The Table Editor lets you edit and delete rows with a click, like a spreadsheet — but there's no undo. Treat it as read-only when you're browsing production data; do deliberate changes through SQL where you can see exactly what you ran.