“Sans schéma” semble rapide jusqu'à ce que différentes équipes commencent à stocker le même concept commercial sous des formes légèrement différentes. À ce moment-là, le schéma n'a pas disparu. Il a simplement été déplacé dans le code de l'application, les scripts de migration et les incidents de support en production.
C'est pourquoi de nombreuses équipes finissent par opter pour Postgres avec `JSONB` comme compromis : des garanties relationnelles pour les champs essentiels, un stockage de documents flexible pour les parties qui changent effectivement souvent.
## Pourquoi JSONB fonctionne comme un terrain d'entente
Le modèle utile n'est pas "mettre tout dans une colonne JSON." Il s'agit de séparer les champs commerciaux stables des métadonnées évolutives :
```sql
CREATE TABLE users (
id UUID PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
plan TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
preferences JSONB NOT NULL DEFAULT '{}'::jsonb
);
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
Cela vous donne :
- des contraintes relationnelles normales pour les champs importants
- des requêtes JSON pour des préférences variables ou des indicateurs de fonctionnalité
- une plateforme opérationnelle au lieu de modèles de stockage fractionnés
Où les équipes regrettent généralement le stockage pur de documents
Les bases de données documentaires peuvent encore être un bon choix, mais la douleur se manifeste souvent lorsque le système croît :
- la cohérence entre documents devient plus difficile
- les rapports nécessitent des requêtes relationnelles
- les formes de champs en double s'accumulent
- les migrations deviennent un travail de réparation de données ad hoc
Si l'application a des flux financiers, un état de facturation, des identités ou des jointures de haute valeur, Postgres vieillit généralement mieux.
Le compromis honnête
JSONB est puissant, mais il est facile à mal utiliser. Si chaque champ significatif finit par être enfoui à l'intérieur de JSON, vous perdez une grande partie de la raison pour laquelle le stockage relationnel est utile en premier lieu. Utilisez-le pour une flexibilité sélective, pas comme une excuse pour éviter la conception de schéma.
MongoDB n'est pas "erroné". L'erreur consiste à supposer que le stockage sans schéma est moins cher pour toujours. Il est souvent moins cher seulement au tout début.
Lectures complémentaires