Back to Lovable + Supabase

Set up a sound backend.

Start a Lovable database with a small, explicit schema: model the product's nouns, define relationships and secure each table before wiring the UI.

Lovable + Supabase · 8 min read · Updated 2026-06-06

Model the product first

Write down the records the application owns, such as profiles, projects, submissions or orders. Give each record an ID, timestamps and only the fields the product needs. Use a relationship when two records need to stay connected.

  1. Create the tables from the workflow, not from the first screen.
  2. Add foreign keys for relationships and decide what should happen when a parent record is deleted.
  3. Grant only the database access the policies require.
  4. Enable row level security on every user-facing table.
  5. Create policies for each operation instead of relying on the table existing.

Relationships

The list below breaks this down into the parts that matter most. Read through each one and note anything that applies to your own setup.

  • One-to-many: one user owns many submissions.
  • Many-to-many: one project has many tags and one tag has many projects.
  • Reference user identity through the platform auth user ID, not a copied email.
  • Keep roles in a separate roles table and check them server-side.
A schema that is easy to query is usually easier to secure. Avoid a single JSON column for data the app needs to filter or authorize.

Schema review checklist

Before making changes, work through the points below. Each one covers a different part of the picture, so treat them as a set rather than picking favourites.

  • Every table has a primary key and created_at timestamp.
  • Every foreign key has an explicit on delete behaviour, not the default.
  • Nullable columns are nullable on purpose, not by oversight.
  • Enum-like values are constrained with a check constraint or a lookup table.
  • Indexes exist on columns used in filters, joins and RLS policy comparisons.
  • No table stores a duplicate copy of data owned by another table.

Growing the schema safely

Work through these steps in order. Each one builds on the last, so resist skipping ahead even if a step feels familiar.

  1. Add new columns as nullable first, then backfill before making them required.
  2. Write migrations that can run against existing production data without dropping rows.
  3. Rename columns by adding the new one, migrating reads, then removing the old one.
  4. Version any breaking change to a table the UI depends on directly.
  5. Re-check RLS policies whenever a column used in a policy expression changes.

Questions

Before. Screens change far more often than the underlying records the product owns. A schema built around the workflow survives redesigns; one built around the first screen usually needs reworking.

Yes. Enable it from the start. Adding RLS later to a table that already has client traffic is riskier than building policies alongside the schema, and a single-admin app usually grows more roles than expected.

There is no fixed number. Judge it by whether each table represents a distinct record the product needs to query or authorize separately. Splitting data too early adds joins with no benefit; leaving unrelated data in one table makes policies harder to write correctly.

Want your app built properly?

We take Lovable prototypes to production: secure data, real auth and a clean deploy.

See the service

Related guides

Lovable RLS policies and permission errors

Row level security decides which authenticated or anonymous requests may read and change each row. A table can exist and still return permission errors if grants and policies do not match the request.

Lovable database not saving or loading

Lovable form submits but data is missing? Test the full path: payload, database grants, row level security, response handling and follow-ups.

Lovable RLS policies and permission errors

Row level security decides which authenticated or anonymous requests may read and change each row. A table can exist and still return permission errors if grants and policies do not match the request.