How to Create a Database Table in Supabase
Every app needs somewhere to store its data. Here's how that actually happens inside Supabase, using the visual Table Editor instead of writing SQL by hand.
Your MissionForge guide lives inside your browser
An overlay appears directly on top of Supabase and Lovable. No tab switching, no re-reading docs.
Copy your Project URL
Find the Project URL field below and click the copy icon. We will use this in Lovable’s environment settings.
Stylized preview. The real guide is interactive, not a screenshot.
Create a table
Open the Table Editor and create a new table. A simple example most people start with is a tasks table, since it's easy to picture how the rows should look.
Notice the id column is already there
Every new table comes with an id column by default. That's the primary key, the value that keeps every row unique even if every other column happens to match another row.
Add your columns
Columns decide what kind of information the table can hold. For a tasks table, that typically means a title column as text and a completed column as a boolean checkbox.
Insert your first row
Add one row with a title and leave completed unchecked. This is the fastest way to see the table actually holding real data instead of an empty structure.
Update and delete a row
Try checking the completed box on your row, then delete the row entirely. Both actions update the database instantly, and both are worth practicing once so they're not unfamiliar later.
A new table is not locked down by default
A freshly created table is readable and writable by anyone with a valid API key until Row Level Security is turned on and a policy is attached. That's a separate step from creating the table itself, worth doing before the table holds anything user specific.
Table Editor versus writing SQL directly
Supabase gives you two ways to build the same table: the Table Editor's visual form, or the SQL Editor with a CREATE TABLE statement. Both produce identical results underneath, since the Table Editor is really just generating that SQL for you. For a first table, the visual editor tends to be the faster path because the fields and types are already laid out, and there's less room to typo a column definition.
Why the four basic actions matter as a first test
Create, read, update, and delete, often shortened to CRUD, cover essentially every way an app touches its own data. Practicing all four on a throwaway table before building real features means you've already confirmed the table works end to end, rather than discovering a typed column or missing permission only after wiring it into an actual app.
Want to build this for real instead of just reading about it?
Frequently asked questions
Do I need to know SQL to create a table in Supabase?
No. The Table Editor lets you create a table, name its columns, and set their types through a visual form. Supabase generates the underlying SQL for you, so writing it by hand is optional, not required.
What is the id column that appears automatically?
It's the table's primary key, a value Supabase adds by default to keep every row unique. You generally don't need to fill it in yourself, it's handled automatically as rows get created.
Is a new Supabase table secure by default?
No. A new table is readable and writable by anyone holding a valid API key until you turn on Row Level Security and attach a policy. That's a separate step from creating the table, and it matters as soon as the table holds anything user specific.
What column types can I use in Supabase?
Standard Postgres types are all available, text, numbers, booleans, timestamps, and more. For a first table, text and boolean columns cover most simple use cases, like a title and a completed checkbox.
Can I edit or delete rows without writing SQL?
Yes. The Table Editor supports inserting, editing, and deleting rows directly, the same as creating the table itself. It's the fastest way to confirm a table works before connecting it to a real app.
Practice all four CRUD actions before building on top of the table
Create, read, update, and delete a test row before wiring the table into a real feature. It's much easier to catch a typed column or wrong type now than after a form depends on it.
Turn on Row Level Security as soon as the table holds user data
A new table is open by default. Add RLS the moment a table stores anything tied to a specific user, not after.
Keep column types specific from the start
A boolean column for a yes or no field is easier to work with later than a text column holding "true" and "false" as strings. Match the type to what the data actually is.
Use the Table Editor for a first table, SQL for anything repeatable
The visual editor is faster for a one off table. Once you're recreating the same structure more than once, a saved SQL script becomes the more reliable path.
Why people drop off before they finish
You're not the problem. The format is. Here's what changes when you switch to an interactive mission.
- ✕Pause, rewind, pause again, repeatedly
- ✕The UI has changed since recording
- ✕No feedback when you complete a step
- ✕Lose context every time you switch tabs
- ✓Live overlay, no tab switching ever
- ✓Always current: guides track the real UI
- ✓Instant confirmation at every step
- ✓Full context stays open in your browser
Looking for the next thing to build? Browse every mission and find one that matches what you are trying to ship.
Browse all missions