$ which-

Quelle base pour quel problème ?

Une antisèche pour décider vite. Le critère n'est pas la « meilleure » base, mais la nature du problème : les liens, la forme, le temps, le débit — ou rien de spécial.

5 moteurs·1 réflexe·PostgreSQL par défaut
Réflexe

Pars de PostgreSQL. Ajoute une base spécialisée seulement quand un besoin précis le justifie. On combine souvent : Postgres + Redis (cache), Postgres + InfluxDB (métriques).

PostgreSQL / relationnel

Le défaut. À battre, pas à éviter.

Choisir si : données structurées, relations claires, besoin de transactions fiables.

ACIDJSONB si besoinpolyvalent

Éviter si : relations en arborescence profonde, écritures massives de séries temporelles.

MongoDB / documents

La forme des choses varie.

Choisir si : schéma flexible/évolutif, données hétérogènes, prototype rapide, stack JS.

CMScataloguelogs/events

Éviter si : données très relationnelles et transactionnelles → tu réinventes les jointures.

Neo4j / graphe

Les liens sont le sujet.

Choisir si : tu écrirais 5+ jointures auto-référentielles, parcours de relations à profondeur variable.

réseau socialrecodétection fraude

Éviter si : données plates et tabulaires, agrégats analytiques lourds.

InfluxDB / séries temporelles

L'évolution dans le temps.

Choisir si : données horodatées en flux continu, requêtes par fenêtres, rétention auto.

monitoringIoTmétriques

Éviter si : données métier relationnelles, mises à jour fréquentes d'anciens enregistrements.

Redis / clé-valeur en mémoire

La vitesse, l'éphémère.

Choisir si : besoin de latence très basse, accès par clé, données souvent temporaires.

cachesessionsfiles / queues

Éviter si : source de vérité durable, requêtes complexes → c'est un complément, pas une base primaire.