Backend for Vibe Coders: Database, Auth and Storage

Understand the three core parts of a backend through Supabase, plus Row Level Security and which keys must never leak, before real users arrive.

The app you vibe coded may look complete on screen, but when you refresh the page everything you entered is gone, or a friend opens the link on another device and sees nothing. That is a sign your app only has a "front of house" and no "back of house" yet. This article explains the three core parts of a backend that vibe coders need to understand, using Supabase as the example, since many vibe coding tools can connect to it.

What is a backend?

The backend is the part that runs on a server, invisible to users. Its job is to store data, verify who is who, and decide who can do what. The frontend is the screen that runs in the user's browser. The key point: anything in the frontend can be seen by a user who wants to look. Permission decisions must therefore always live in the backend.

Supabase's Features page explains that every project is a full Postgres database, with Auth, Storage, Edge Functions, Realtime and more in one place. Lovable describes a native Supabase integration for adding login, a database and file storage, and Bolt also supports connecting Supabase.

Part 1: Database, data stored in tables

Think of linked Excel sheets

A Postgres database stores data in tables, each with clear columns, linked by IDs. For example, a "students" table and a "submitted homework" table are linked by student ID.

What to ask the AI

• Ask the AI to propose the table structure in plain language first, then check it is complete
• Ask "if I delete a student, what happens to their homework?" to think through data relationships
• Change the table structure early; it is easier than fixing it after real data exists

Part 2: Auth, knowing who is who

Auth (authentication) is the login system. Supabase's Features page lists email, phone, social login, SSO and MFA. Once a user logs in, the system knows who each request comes from, and that is the foundation for the permissions in the next section.

Do not confuse authentication (who you are) with authorization (what you are allowed to do). Many apps have login but forget to limit whether a logged-in user can see other people's data.

Part 3: Storage, keeping files

Images, PDFs and attachments should not be stored directly in tables. They go into Storage, a file store, and the table keeps only the file's location. The decision you must make is which buckets are public (such as product photos) and which must be private (such as payment slips or job application documents).

The key piece: Row Level Security

Supabase's "Securing your data" guide explains that Row Level Security (RLS) controls which rows a user can read or change, and recommends enabling RLS on every table exposed through the Data API, with policies that grant only the access needed. For example, "students see only their own homework" or "teachers see homework from every student in the classes they teach".

The same guide explains two kinds of keys. The publishable key (or anon key in older projects) is safe in the frontend because every request is checked against RLS. The service role key or secret key bypasses RLS entirely, so it must stay on the backend and never appear in front-end code. If you need server-side logic that uses secrets, put it in Edge Functions.

Example: a tutoring school in Nakhon Pathom

A teacher who owns a tutoring school wants students to submit homework as photos through a website. She plans tables for students, classes and submissions, uses Auth so students and teachers log in with email, stores homework photos in a private bucket, and tells the AI: "Enable RLS on every table. Students can see and submit only their own work. Teachers see work from the classes they teach." Before launch she creates two test student accounts and tries to open one account's work from the other. It is not visible. This is the most important test of all.

Login tells the system who you are; RLS decides what you can see.

Things to watch out for

• Never paste a service role key, secret key or connection string into an AI chat or front-end code
• If the AI suggests "turn off RLS for now so it works", stop and ask for the correct way to write the policy instead
• Files containing personal data must be in a private bucket. Test that a direct link opened on a logged-out device shows nothing
• Data about users in Thailand falls under the PDPA. Collect only what you need and have a way to delete it when a user asks

How to get started

1. List the data your app must store and every user role
2. Write the permission rules in plain language: who sees what, who can edit what
3. Ask the AI to create the tables, enable RLS and write policies following those rules
4. Create at least two test accounts and try to access each other's data

For the big picture of building an app from scratch, read From PRD to App, or build an app with a real database in the course Build a stock management app with Lovable on Plants.work.