Conventions

Chaque projet reçoit quatre sous-schémas préfixés project_{uuid}. Vos tables métier vont dans le schéma principal ; ne créez jamais d'objets dans les schémas système.

• Tables au pluriel : posts, comments, invoices
• Colonnes en snake_case : created_at, user_id, last_seen_at
• Clés primaires id uuid primary key default gen_random_uuid() — pas de uuid_generate_v4()
• Timestamps timestamptz, jamais timestamp nu
• FKs suffixées _id : author_id, tenant_id
• Booléens préfixés is_ ou has_
• Pas de colonne project_id — le schéma est déjà l'isolant

create table posts (
  id            uuid primary key default gen_random_uuid(),
  author_id     uuid not null references users(id) on delete cascade,
  title         text not null,
  is_published  boolean not null default false,
  created_at    timestamptz not null default now()
);

Le gateway ouvre les connexions Postgres avec request.jwt.claims renseigné. Les trois helpers ci-dessous lisent ces claims et sont utilisables partout dans vos policies.

Convention : <table>_<scope>_<operation>. Exemple : posts_own_read, orders_admin_delete. Toujours préciser to authenticated ou to anon.

-- ✓ Bon : table_scope_op
create policy "posts_own_read"   on posts for select …
create policy "orders_admin_all" on orders for all …
-- ✗ À éviter
create policy "allow_stuff"    -- trop vague
create policy "new_policy_42" -- pas descriptif

• Nom : idx_<table>_<colonnes> ou uq_<table>_<colonnes> (unique)
• Toujours indexer : les FKs, les colonnes de filter/order_by fréquents, les where des policies RLS
• Ne pas indexer : colonnes booléennes à forte cardinalité low (utiliser partial index), tables < 1000 lignes
• pgvector : using hnsw pour > 100k vecteurs, ivfflat sinon