Back to Lovable + Supabase

Model data that stays connected.

Define the parent record, ownership, delete behaviour and access policy for Supabase relationships before you build the screen that uses the data.

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

Start with ownership

For each child row, identify the parent it belongs to and the user or organisation allowed to access it. Use a foreign key for the database relationship and row level security for the access rule. One does not replace the other.

  1. Name the parent and child tables.
  2. Add a non-null foreign key where every child must have a parent.
  3. Choose safe delete and update behavior.
  4. Add indexes for common filters and joins.
  5. Write and test policies for owner, member and signed-out cases.
  6. Load the relationship in the UI with explicit empty and error states.
A foreign key protects data integrity. It does not automatically make a record safe for every authenticated user.

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 foreign key has an explicit ON DELETE behaviour, not the default.
  • Indexes exist on columns used in joins and RLS policy checks.
  • Nullable foreign keys are genuinely optional, not an oversight.
  • Cascading deletes are tested against real data before going live.
  • Junction tables used for many-to-many relationships have composite keys.

Warning signs of a relationship problem

A few moving parts are involved here. The points below cover each of them, so you can see the full scope before deciding where to start.

  • Orphaned rows appearing after a parent record is deleted.
  • Queries slowing down as a joined table grows without an index.
  • Policies that pass in testing but expose data through an unexpected join.

Questions

Use CASCADE when child records genuinely have no meaning without the parent, such as order line items. Use RESTRICT or SET NULL when a child record should survive or block deletion, such as an invoice tied to a customer.

No. A foreign key only enforces that a reference points to a real row. Access control must be handled separately with row level security policies.

This is usually a missing index on the foreign key column or the column used in a row level security policy check. Add an index and re-test the query plan.

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 Supabase setup and database schema

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 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.