Aller au contenu principal

ADR-001 — PostgreSQL vs MongoDB

Date : 2026-04-16 · Statut : Accepté · Décideurs : Clement Molotkoff

Contexte​

Patrimo stocke des entités fortement relationnelles et financières :

  • Transactions (montants, dates, catégories, métadonnées d'import)
  • Comptes et leur hiérarchie (Institution → Account → sous-compte)
  • Plans budgétaires et leurs allocations
  • Snapshots de soldes horodatés par compte

Le CLAUDE.md initial mentionnait MongoDB / MariaDB. Cette décision finale porte sur PostgreSQL + Prisma et invalide ces mentions antérieures.

Options considérées​

Option A — PostgreSQL + Prisma​

Pour

  • Données fortement relationnelles → JOINs natifs efficaces
  • Calculs financiers typiques (SUM par mois, GROUP BY catégorie, prévu/réel) nativement optimaux en SQL
  • Prisma fournit un schéma TypeScript typé cohérent avec le reste de la stack
  • Transactions ACID indispensables pour l'intégrité financière
  • Type Decimal natif PostgreSQL → pas de floating-point errors sur les montants
  • Unique constraints composites (ex. importHash pour dédoublonnage)

Contre

  • Nécessite un serveur dédié (Docker)
  • Migrations à gérer explicitement (Prisma Migrate)

Option B — MongoDB + Mongoose​

Contre (rédhibitoire pour ce cas d'usage)

  • Agrégations financières complexes via pipelines MongoDB (verbeux, error-prone)
  • Transactions multi-documents limitées, peu utilisées en pratique
  • Pas de Decimal natif → risque de floating-point sur les montants financiers
  • Relationnalité (Transaction → Account → Institution) mal prise en charge sans $lookup
  • Aucun bénéfice concret pour ce cas d'usage

Option C — SQLite en dev, PostgreSQL en prod​

Contre

  • Divergences de comportement (types Decimal, colonnes JSON, concurrence, locks)
  • Bugs prod non reproductibles en dev → risque élevé sur données financières

Décision​

PostgreSQL 16 + Prisma 7 dès le développement local, via Docker Compose.

SQLite est exclu même en dev pour garantir la parité dev/prod.

Conséquences​

Positives

  • Docker obligatoire pour le dev → environnement reproductible
  • Migrations versionnées dans prisma/migrations/ → diff auditable
  • Type Decimal systématique dans Prisma pour les montants (@db.Decimal(12, 2) et @db.Decimal(18, 8) pour les taux FX)
  • Pas de modification manuelle du schéma en base

Risques acceptés

  • Courbe d'apprentissage Prisma Migrate + adaptateur @prisma/adapter-pg (Prisma 7)
  • Poids du container PostgreSQL en dev (~200 MB)

Révision​

Cette décision serait à remettre en question si :

  • Les volumes dépassent plusieurs dizaines de millions de transactions avec patterns très sparse (improbable pour un usage perso)
  • Un besoin full-text search complexe émerge et justifie ElasticSearch / Meilisearch couplé
  • L'hébergement on-premise devient incompatible avec PostgreSQL (Coolify supporte nativement)