A profile row belongs to its account: say it with a foreign key

public.users.id IS the auth.users id, so the row is a child of the account.
A foreign key with ON DELETE CASCADE replaces the on_auth_user_deleted
trigger that deleted it by hand: it cannot be forgotten, it also rules out a
profile for an account that does not exist, and it is one mechanism instead
of two. Deleting an account still cascades on to devices.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: johnckealy

README.md

@@ -61,9 +61,10 @@ await supabase.rpc('delete_own_account')
 
 `delete_own_account()` is `SECURITY DEFINER`, takes no arguments, deletes only
 `auth.uid()` (the caller's own id from their session token), and may only be
-executed by signed-in users. The `on_auth_user_deleted` trigger removes the
-`public.users` row, which cascades to `devices`. See the migration
-`20260905120000_delete_own_account.sql` for the full reasoning.
+executed by signed-in users. Deleting the `auth.users` row cascades to the
+`public.users` row (the foreign key added in
+`20260917200000_users_follow_auth_users.sql`), and on to `devices`. See the
+migration `20260905120000_delete_own_account.sql` for the full reasoning.
 
 The same deletion also exists as an API endpoint, `DELETE /auth/users/me`
 (`app/routes/auth_router.py`): the server deletes the caller with the

supabase/migrations/20260917200000_users_follow_auth_users.sql

@@ -0,0 +1,33 @@
+-- ============================================================================
+-- A PROFILE ROW BELONGS TO ITS ACCOUNT — SAID WITH A FOREIGN KEY
+-- ============================================================================
+-- `public.users.id` IS the `auth.users` id, so the row is a child of the
+-- account and should go when the account goes. Until now a trigger
+-- (`on_auth_user_deleted`) deleted it by hand. A foreign key says the same
+-- thing to the database itself, which is better in three ways:
+--
+--   * It cannot be forgotten. The trigger only ran for DELETE statements
+--     against auth.users; the key is enforced by the database.
+--   * It rules out the other orphan too: a profile row can no longer be
+--     inserted for an account that does not exist.
+--   * It is one mechanism instead of two, so nothing can half-happen.
+--
+-- Deleting an account still cascades on to `devices` (and any other table
+-- whose foreign key points at public.users), exactly as before.
+
+-- Any profile row whose account is already gone would refuse the key. There
+-- should be none — the trigger removed them — but a database that was
+-- restored, or written to by hand, may have one. They belong to no account
+-- and nothing can reach them, so they go.
+DELETE FROM public.users u
+WHERE NOT EXISTS (SELECT 1 FROM auth.users a WHERE a.id = u.id);
+
+ALTER TABLE public.users
+    ADD CONSTRAINT users_auth_user_fkey
+    FOREIGN KEY (id)
+    REFERENCES auth.users(id)
+    ON DELETE CASCADE;
+
+-- The trigger and its function have nothing left to do.
+DROP TRIGGER IF EXISTS on_auth_user_deleted ON auth.users;
+DROP FUNCTION IF EXISTS public.handle_deleted_user();