Skip to content
Every tutorial here is 100% free — and always will be
LSLovableStudent

How do I create database tables?

Last checked 31 Aug 2026

Short answer

Describe the table's purpose and fields in plain language to Lovable — including which fields are required, their types, and any relationships to other tables — and Lovable generates the table with appropriate row-level security policies.

Describe data in business terms, not SQL

You don't need to write SQL. Describe what the table is for and what it holds:

Create a bookings table: customer name, email, phone (optional), appointment date and time, service selected, and status (pending/confirmed/cancelled), defaulting to pending.

Lovable translates this into an actual Postgres table with appropriate types (text, timestamp, enum-style status) and creates it directly.

Relationships between tables

If one table refers to another, say so explicitly:

Add a service_id column on bookings that references the services table.

Lovable adds the foreign key relationship rather than a loose text field that happens to hold matching values.

Always specify access rules

Every new table needs a decision about who can read and write it. Don't leave this implicit:

Anyone can insert a new booking. Only logged-in admins can view, update or delete bookings.

This becomes a row-level security (RLS) policy on the table. For role checks, always use a separate user_roles table rather than a role field on a user/profile row — this avoids a common privilege-escalation mistake.

Editing tables later

Adding columns, changing types, or adding constraints works the same way — describe the change:

Add a notes text column to the bookings table for internal staff comments, not visible to customers.

What usually goes wrong

  • No RLS policy defined: a table with no policy can end up either fully locked (nothing works) or unexpectedly open — always state the intended access rule explicitly and ask Lovable to confirm what policy it applied.
  • Ambiguous field types: "store the date" is ambiguous about time zones and whether time is included — be specific ("date and time, in the user's local time zone").
  • Not planning for growth: if you'll need to query or filter a table often (e.g. by status or date), mention that so Lovable can add appropriate indexing.

See how do I create an enquiry management dashboard for a worked example of building on top of a table once it exists.

Sources

Was this answer helpful?

Related questions

Website made, maintained and hosted by PromptSites.com

PromptSites logo