JSONB : le schéma flexible sans quitter le relationnel

Le besoin : des attributs qu'on ne connaît pas à l'avance

Un catalogue produit multi-tenant : chaque client a SES attributs (matière, voltage, DLC…). Une colonne par attribut est impossible. La réponse Postgres : une colonne JSONB — du JSON binaire, indexable et interrogeable. C'est exactement le pattern extensions du projet étudié (le nom du variant, les specs libres y vivent), et celui de cette plateforme (gardens.state).

-- interroger
SELECT * FROM variant WHERE extensions->>'marque' = 'Nike';          -- ->> = texte
SELECT * FROM variant WHERE (extensions->>'voltage')::int > 220;     -- cast si besoin
SELECT * FROM variant WHERE extensions @> '{"actif": true}';         -- @> = contient
SELECT * FROM variant WHERE extensions ? 'garantie';                 -- ? = clé existe

Indexer le JSONB (sinon Seq Scan garanti)

Un filtre sur JSONB sans index scanne toute la table. Deux stratégies :

• index GIN sur la colonne : CREATE INDEX … USING gin (extensions) — accélère @>, ?, ?& (les opérateurs de contenance/existence). Le couteau suisse ;
• index B-tree sur une expression : CREATE INDEX … ON variant ((extensions->>'marque')) — pour un attribut précis fréquemment filtré par égalité/ordre. Plus petit, plus rapide sur CE champ.

Choix : requêtes variées sur le contenu → GIN ; un champ chaud identifié → index d'expression B-tree.

Quand JSONB, quand colonne (la vraie décision)

JSONB est un outil, pas un défaut. La ligne de partage :

• colonne SQL pour ce qui est : su à l'avance, filtré/joint souvent, contraint (types, FK, NOT NULL), partagé par tous les tenants. Le prix, le stock, le tenant_id — jamais en JSONB ;
• JSONB pour ce qui est : variable par tenant, rarement filtré (souvent juste lu/affiché), sans contrainte forte. Les attributs libres, les métadonnées, un état de jeu.

Le piège classique : tout mettre en JSONB « pour la flexibilité » → on perd les contraintes, les FK, la lisibilité des requêtes, et on réinvente un schéma sans filet. Le projet étudié tranche par ADR : variant.name en JSONB (varie par tenant), price.level dénormalisé en colonne (filtré en permanence). Chaque champ, une décision.