Pourquoi utiliser plusieurs schémas PostgreSQL avec Supabase ?

Un schéma par domaine fonctionnel (documents, contrats, budget, IA, etc.) permet une isolation logique propre, une gestion des permissions précise, et une conformité RGPD structurelle. Chaque schéma peut avoir ses propres politiques RLS et son propre cycle de vie de migration.

Supabase ou PostgreSQL managé — quelle différence pour un freelance ?

Supabase offre PostgreSQL + Auth + Realtime + Storage + Edge Functions dans une même plateforme, avec une interface claire et un SDK TypeScript de qualité. Je travaille principalement avec Supabase pour les projets greenfield TypeScript, mais je m'adapte à tout PostgreSQL managé (RDS, Neon, PlanetScale).

Développeur Freelance Supabase · PostgreSQL — TypeScript

Pourquoi votre base Supabase mérite une attention particulière

Ces situations arrivent quand la base de données n'a pas été pensée pour durer dès le départ.

Schéma monolithique ingérable

Tout dans le schéma public, 80 tables sans organisation logique, des jointures partout. Impossible de comprendre quelles données appartiennent à quel domaine, et encore moins d'appliquer des permissions fines. Un schéma par domaine fonctionnel règle ça structurellement.

RLS absent ou mal configuré

Vous avez activé Supabase Auth mais les politiques RLS sont permissives ou inexistantes — n'importe quel utilisateur peut potentiellement accéder aux données d'un autre. C'est un risque RGPD réel. Le RLS bien pensé dès le départ évite ces fuites par design.

Migrations sans filet

Les modifications de schéma se font directement dans la console Supabase, sans historique. Une mauvaise manipulation et vous avez perdu des données. Les migrations versionnées avec Supabase CLI donnent un historique complet, rejouable et déployable en CI/CD.

Discutons de votre architecture Supabase — Gratuit · 30 min

Expertise Supabase · PostgreSQL en production

Mon expérience Supabase est ancrée dans beforbuild.com — un SaaS B2B construit entièrement seul, où la base de données n'était pas un détail mais le cœur de l'architecture.

J'ai conçu 9 schémas PostgreSQL distincts (public, documents, vector, contracts, budget, land, planning, commercial, agent) avec RLS activé sur chaque table. L'isolation multi-tenant est structurelle — aucun utilisateur ne peut accéder aux données d'un autre par construction, pas par convention.

Le schéma vector contient les embeddings pgvector 1024-dim générés par Mistral, avec recherche par similarité cosinus pour le pipeline RAG. Le schéma agent gère les sessions KV et les messages de l'agent conversationnel. Chaque schéma a son propre cycle de migration — baseline + incrémentaux versionnés avec Supabase CLI.

J'utilise pg_net pour les triggers asynchrones (webhooks sortants depuis la DB vers les Workers) et Supabase Realtime pour le streaming SSE vers React via TanStack Query.

Architecture multi-schema
9 schémas PostgreSQL isolés par domaine fonctionnel. Permissions par schéma, migrations indépendantes, conformité RGPD structurelle.

Sécurité · RLS · Multi-tenant
Row Level Security sur toutes les tables. JWT + claims custom pour l'isolation tenant. HMAC-SHA256 pour les webhooks entrants. Zéro fuite de données par design.

pgvector · Recherche sémantique
Embeddings 1024-dim Mistral stockés dans pgvector. Recherche par similarité cosinus pour le pipeline RAG. Index IVFFlat optimisé pour les requêtes sub-100ms.

Migrations · CI/CD
Migrations versionnées avec Supabase CLI — baseline 960KB + incrémentaux. Déployables en GitHub Actions. Historique complet et rejouable sur n'importe quel environnement.

La preuve : 9 schémas PostgreSQL en production

beforbuild.com — SaaS B2B construit seul, de l'architecture initiale jusqu'aux migrations de production.

Architecture multi-schema : 9 domaines fonctionnels isolés

La base de beforbuild.com est organisée en 9 schémas PostgreSQL distincts, chacun correspondant à un domaine métier : public (utilisateurs, organisations), documents (fichiers uploadés, métadonnées), vector (embeddings pgvector), contracts (contrats e-signés Yousign), budget (simulation financière), land (données foncières), planning (Gantt, jalons), commercial (prospects, CRM), agent (sessions IA, messages).

RLS activé sur toutes les tables — isolation multi-tenant par construction
Permissions granulaires par schéma — chaque Worker n'accède qu'à ce dont il a besoin
Migrations indépendantes par schéma — pas de migration monolithique ingérable
pg_net dans le schéma public pour les triggers asynchrones vers les Workers

Conformité RGPD structurelle Isolation multi-tenant par design Maintenabilité à long terme

pgvector · Embeddings Mistral · Recherche sémantique

Le schéma vector stocke les embeddings générés par l'API Mistral (1024 dimensions) pour chaque chunk de document indexé. La recherche par similarité cosinus alimente le pipeline RAG — les 6 chunks les plus proches de la question de l'utilisateur sont injectés dans le contexte de l'agent IA.

Embeddings 1024-dim Mistral — un vecteur par chunk de document avec métadonnées enrichies
Recherche cosinus vector <=> query_embedding — sub-100ms sur les volumes testés
Métadonnées de chunking : h1, h2, phase, document_name — pour le filtrage et le contexte
Triggered automatiquement à l'upload via Cloudflare Workflows (OCR → chunking → embedding → insertion)

Pipeline RAG opérationnel Recherche sémantique dans les documents utilisateur Extensible à d'autres modèles d'embedding

Supabase Realtime · pg_net · Webhooks asynchrones

Pour le streaming SSE de l'agent IA, j'utilise Supabase Realtime comme bus de messages : le Worker IA streame les tokens vers une table Realtime, React les écoute via TanStack Query et les affiche en temps réel. pg_net gère les webhooks sortants depuis la DB directement vers les Workers Cloudflare — sans avoir besoin d'un serveur intermédiaire.

Supabase Realtime pour le streaming de l'agent IA vers React — expérience conversationnelle fluide
pg_net pour les triggers asynchrones : statut de contrat Yousign → Worker → mise à jour DB
Webhooks entrants vérifiés HMAC-SHA256 côté Worker avant écriture en base
Sessions agent stockées en KV Cloudflare (15 min TTL) — pas de pollution en base

Streaming temps réel sans WebSocket custom Webhooks robustes avec vérification cryptographique Architecture event-driven propre

Comment je travaille sur un projet Supabase

01

Audit de l'existant

Je commence par auditer votre schéma actuel : organisation des tables, politiques RLS en place (ou absentes), migrations existantes, performances des requêtes clés. Je produis un rapport d'architecture avec les risques identifiés et les améliorations prioritaires.

02

Refonte ou évolution incrémentale

Selon l'état de la base, je propose une refonte (passage multi-schema, activation RLS) ou une évolution incrémentale (ajout de schémas, migrations progressives). Tout est versionné dès le premier jour — chaque changement est un fichier SQL rejouable.

03

CI/CD et documentation

Mise en place du pipeline GitHub Actions pour les migrations automatiques (staging → production). Documentation du schéma (ER diagram, description des tables clés, conventions de nommage). Votre équipe reprend avec une base saine et un historique clair.

Discuter de votre projet Supabase — Gratuit · 30 min

Tarifs — Freelance Supabase PostgreSQL

Appel découverte

Gratuit · 30 minutes

Un appel pour comprendre votre architecture Supabase actuelle, identifier les risques et vous proposer une approche. Aucun engagement.

Réserver l'appel — Gratuit · 30 min

Mission freelance Supabase · PostgreSQL

380€ HT / jour

ou forfait projet sur devis

Fourchette basse du marché pour un expert Supabase / PostgreSQL senior en France. Disponible immédiatement, pas d'intermédiaire.

Architecture multi-schema PostgreSQL — isolation domaines fonctionnels

Row Level Security — multi-tenant sécurisé par construction

pgvector — embeddings, recherche sémantique, pipeline RAG

Migrations versionnées Supabase CLI — CI/CD GitHub Actions

Supabase Realtime · pg_net · webhooks asynchrones

Intégration TypeScript full-stack — Cloudflare Workers + React

Remote France — disponible immédiatement — facturation mensuelle

Discuter de votre projet Supabase — 30 min

Questions fréquentes — Développeur freelance Supabase

Quelle est votre expérience Supabase en production ?

J'ai construit beforbuild.com seul en 8 mois — un SaaS B2B complet avec Supabase en production : 9 schémas PostgreSQL isolés, RLS sur toutes les tables, pgvector pour les embeddings Mistral, pg_net pour les webhooks asynchrones, Supabase Realtime pour le streaming SSE, et Supabase Auth pour l'authentification multi-tenant. C'est une référence vérifiable, pas un projet de démonstration.

Pouvez-vous intervenir sur une base Supabase existante ?

Oui. Je commence par un audit rapide de l'existant (schéma, politiques RLS, migrations, performances) puis je propose une feuille de route progressive. Pour les bases déjà en production avec des données, l'approche est conservative — on migre sans rupture, en versionnant chaque changement.

Supabase ou autre PostgreSQL managé — vous vous adaptez ?

Oui. Mon expertise principale est Supabase, mais les compétences PostgreSQL (multi-schema, RLS, pgvector, migrations) s'appliquent à tout hébergeur — Neon, RDS, Render. Si vous avez déjà un PostgreSQL ailleurs et souhaitez uniquement bénéficier de pgvector ou de RLS, c'est tout à fait possible sans migrer vers Supabase.

Qu'est-ce que pgvector apporte concrètement ?

pgvector est une extension PostgreSQL qui stocke des vecteurs numériques (embeddings) et permet d'effectuer des recherches par similarité cosinus directement en SQL. Concrètement : vous uploadez des documents, on génère des embeddings via Mistral ou OpenAI, et la recherche "trouvez les passages les plus proches de cette question" s'exécute directement dans PostgreSQL — sans base vectorielle externe comme Pinecone ou Weaviate.

Poser vos questions — Appel découverte gratuit · 30 min

Développeur freelance Supabase
PostgreSQL · pgvector · RLS · TypeScript