How to Create Your First Database Table
Column types, defaults, required fields and relationships — designed so you are not migrating data in three weeks.
Published 24 Aug 2026 · Tested with Lovable as of 24 Aug 2026

Overview
A table is a spreadsheet with rules. The rules — types, defaults, required fields, relationships — are what stop bad data getting in.
Beginner explanation: Decide what one row represents before you create anything. "One row is one booking" is a complete design decision.
Technical explanation: Prefer explicit types and NOT NULL with sensible defaults. Add a foreign key to the owning user for anything user-specific, and index the columns you will filter on.
Steps
- Write down what one row represents.
- List every field and its type.
- Decide which fields are required and what the defaults are.
- Decide who owns the row — usually a user reference.
- Ask for the table and its access rules in one prompt.
:::tip Timestamps are free and always useful. Include a created date on every table. :::
What to check afterwards
- Inserting a row from the app succeeds
- Required fields reject empty values
- Rows are linked to the right owner
Common problems
- Everything stored as text. Dates and numbers should be dates and numbers.
- No owner column. You cannot write per-user access rules later.
- Nullable everything. Broken rows appear months later.
Where people get stuck
If you have followed the steps and the result still is not right, the fastest path is usually to describe the exact behaviour you expected, the behaviour you got, and any error text, then ask for a fix in one focused follow-up prompt. If that loop is not converging, hand it over.