Database & Data
A database is where your app remembers things. When a user signs up, the database remembers them. When they save a post, the database remembers it. When they come back tomorrow, everything they did is still there.
Think of it like a giant, very organised filing cabinet. Every kind of thing your app remembers gets its own drawer. One drawer for users, one for posts, one for orders. Each drawer is called a table.
When you describe a feature, the agent can design the tables, columns, relationships, and privacy policies. It writes complete review-first SQL and tells you where to apply it; it does not silently change your hosted database.
Heads-up: Appsanic's database is powered by Supabase. Read that page first if you haven't connected Supabase yet. It walks through the one-time signup and connection.
What a connected Supabase project can provide
Connect a Supabase project when the app needs shared cloud data. The project and its billing remain in your Supabase account. Connecting supplies public client configuration and, if you opt in, only the bounded account actions listed in the connector.
After you apply the generated schema and security setup, Supabase can provide:
- A real database to store anything your app needs to remember.
- Database-enforced privacy policies that you review and test for each table.
- File storage in the same place (photos, receipts, anything).
- Live updates. When something changes, the app can show it to other users instantly.
What's Supabase? It's a service that gives your app a database, sign-in, and file storage in one place. Like having a backend you didn't have to build. It runs in your account, not Appsanic's. If you cancelled Appsanic tomorrow, your data and users would still be there.
Three prompts that cover most apps
You can describe the data in normal sentences. The agent translates it into app code plus SQL for you to review and apply in Supabase.
1. "Let users save things"
"Let users save favorite recipes. Each favorite remembers the recipe (a link or an in-app one), a note, and a tag. Each user only sees their own favorites."
The agent designs a favorites table, the required columns, user-scoped RLS policies, and the add/remove/list code. You review and apply the SQL before expecting persistence to work.
2. "Let users belong to groups"
"Each habit belongs to an accountability group. Groups have up to 10 people. Each habit belongs to one user, but everyone in the group can see each other's habits."
The agent generates a groups/membership schema and policies for you to review. Group policies are security-sensitive, so test them with at least two users before production.
3. "Make it update live"
"When someone in my accountability group checks off a habit, I want to see that update on my phone without refreshing."
The agent can wire client subscriptions and list the Supabase Realtime settings the table needs. You enable and verify the required server-side configuration. See Realtime Updates for more.
How "each user only sees their own data" actually works
This is one of the most important features of your app and easy to miss because it's invisible.
Without this protection, a bug in your app could accidentally show one user another user's data. With this protection, even if there's a bug, the database itself refuses to hand over the wrong rows. It's a second locked door.
Every generated table plan should enable Row Level Security ("RLS") and include explicit policies. See the Glossary. Do not assume it is active until you apply the SQL and verify the policies in Supabase.
If you ever want to verify it's working, the Supabase dashboard shows the rules for each table under Authentication > Policies.
Looking at your data directly
You don't have to, but you can. From inside Appsanic:
- Open your project.
- Click Supabase dashboard in the top right.
- The Supabase dashboard opens. Sign in to Supabase if that browser session is not already authenticated, then choose the connected project.
From there you can browse every drawer (table), see the cards (rows) inside, and check who's allowed to read what.
Backups
Your data is automatically backed up by Supabase on paid plans. The exact retention depends on your Supabase plan. Check the Supabase dashboard for the details.
For anything truly precious (a customer list, archived journal entries), back it up to a place you control too. Supabase lets you export everything to a file you can save anywhere. It's a button in the dashboard.
Common mistakes (read this before editing data by hand)
If you add a table directly in Supabase, you must add privacy policies yourself. Generated SQL includes policies for review, but Appsanic does not apply arbitrary schema changes automatically.
Also: Supabase gives you two kinds of keys. The "anon key" is safe to bundle into your app. It's designed for browsers and phones. The "service role key" bypasses all your safety rules. Never put it in your app's code or share it publicly. The agent only puts the anon key in places that reach users.
Under the hood (for engineers reading this)
The database is Postgres, hosted by Supabase. An Appsanic export has no managed local supabase/migrations workflow. The agent writes complete SQL files or dashboard steps with SETUP REQUIRED instructions; you apply them in Supabase SQL Editor and regenerate types if your engineering workflow uses them.
Example row-level policy the agent writes for a favorites table:
create policy "favorites read own" on favorites
for select using (auth.uid() = user_id);Queries from the app go through a thin Zustand store wrapping the Supabase client:
const { data, error } = await supabase
.from("favorites")
.select("*")
.order("created_at", { ascending: false });Use the Supabase CLI only if your team deliberately adopts its own local-migration workflow after export. Do not run destructive reset or push commands merely because generated SQL exists.
See Editing Exported Code for the conventions the agent follows.
Next
Want to charge users? Read Payments. Want to know about file uploads? Read File Uploads & Storage.