Dimensionnement des Bases de Données & FinOps : Gérer la Croissance, les Coûts & la Capacité

Les bases de données sont souvent le poste le plus important des factures cloud — et le plus difficile à dimensionner correctement. Ce guide couvre comment estimer, surveiller et optimiser la taille des bases de données pour PostgreSQL et MongoDB, avec des stratégies FinOps pratiqués.

Pourquoi le Dimensionnement Compte

Impact	Ce qui se passé quand on se trompé
Coût	Instances surdimensionnées gaspillent de l'argent ; sous-dimensionnées causent des pannes
Performance	Quand les données dépassent la RAM, les requêtes touchent le disque — la latence explose x100
Opérations	Les grandes tables ralentissent sauvegardés, migrations et changements de schéma
Conformité	Conserver des données au-delà de la politique augmente les risqués et coûts de stockage

PostgreSQL : Dimensionnement & Surveillance

Tailles des tables et index

Requêtes essentielles que tout DBA devrait connaître :

Quoi mesurer	Pourquoi
Taille de la table (données seules)	Comprendre le volume brut par entité
Taille totale (données + index + TOAST)	Empreinte disque réelle
Taille des index	Les index peuvent dépasser la table — signé de sur-indexation
Bloat (tuples morts)	Surcoût MVCC — espace gaspillé par les updates/deletes
Nombre de lignes	Planification opérationnelle, décisions de partitionnement

Points de repère typiques

Lignes	Taille brute approx. (lignes de 100 octets)	Avec index (3 B-tree)	Notes
100 K	~10 Mo	~40 Mo	Tient entièrement en RAM, aucune inquiétude
1 M	~100 Mo	~400 Mo	Encore confortable dans la plupart des configs
10 M	~1 Go	~4 Go	Surveiller les plans de requêtes, envisager des index partiels
100 M	~10 Go	~40 Go	Partitionnement recommandé, réglage du VACUUM nécessaire
1 Md	~100 Go	~400 Go	Partitionnement requis, stratégie d'index soignée, hardware dédié

Coûts de stockage par type de colonne

Type	Taille par valeur	Notes
`BOOLEAN`	1 octet
`SMALLINT`	2 octets	Utiliser au lieu de INT quand les valeurs < 32K
`INTEGER`	4 octets
`BIGINT`	8 octets	Ne pas mettre BIGINT par défaut si INT suffit
`REAL`	4 octets
`DOUBLE PRECISION`	8 octets
`NUMERIC(p,s)`	Variable (5–20+ octets)	Coûteux — utiliser uniquement quand la précision exacte est requise
`TEXT` / `VARCHAR`	1 octet + longueur de chaîne	+ 4 octets de surcoût pour les chaînes > 126 octets
`UUID`	16 octets	Plus grand qu'un INT (4o) — réserver aux systèmes distribués
`TIMESTAMPTZ`	8 octets
`JSONB`	Variable	Pratique mais coûteux — dénormaliser les chemins chauds en colonnes
`ARRAY`	Variable	Souvent mieux dans une table séparée pour les grands tableaux interrogés

Bloat PostgreSQL et surcoût MVCC

Le MVCC de PostgreSQL crée des tuples morts à chaque UPDATE et DELETE. Sans VACUUM correct, les tables peuvent gonfler à 2–5x leur taille logique.

Exemple réel : Une table de 10 Go avec des mises à jour fréquentes peut croître à 30–50 Go si l'autovacuum est mal configuré. Cela impacté directement :

Les coûts de stockage (3–5x)
La taille et durée des sauvegardés
La performance des requêtes (scan des tuples morts)
Le retard de réplication (plus de WAL à transmettre)

Leviers FinOps PostgreSQL

Levier	Impact	Effort
Redimensionner l'instance	20–40 % de réduction typique	Faible — surveiller l'usage CPU/RAM, réduire
Régler l'autovacuum	Réduire le bloat 2–5x	Moyen — ajuster les paramètres par table
Types de colonnes appropriés	10–30 % de réduction du stockage	Moyen — auditer les types du schéma
Index partiels	Index 50–90 % plus petits	Moyen — identifier les patterns de requêtes
Partitionner et supprimer les anciennes données	Jusqu'à 80 % d'économie de stockage	Élevé — nécessite des changements de schéma
Compression TOAST	50–75 % pour le texte/JSON volumineux	Faible — activé par défaut, ajuster le seuil
Passer aux instances ARM (Graviton)	20 % d'économie sur AWS	Faible — même PostgreSQL, compute moins cher
Instances réservées / engagement	30–60 % vs à la demande	Faible — engagement financier
Réplicas de lecture	Décharger les lectures, primaire plus petit	Moyen — routage applicatif nécessaire
Pooling de connexions (PgBouncer)	Instance plus petite suffisante	Moyen — déployer et configurer le pooler

MongoDB : Dimensionnement & Surveillance

Tailles des documents et collections

Quoi mesurer	Pourquoi
Taille des données de la collection	Octets bruts des documents
Taille de stockage de la collection	Sur disque avec compression WiredTiger (~60–70 % de la taille des données)
Taille des index	Chaque index coûte de la RAM — doit tenir en mémoire pour la performance
Taille moyenne des documents	Détecter la croissance des documents dans le temps
Nombre de documents	Planification opérationnelle, décisions de sharding

Points de repère typiques

Documents	Taille doc moy. 1 Ko	Avec 3 index	Notes
100 K	~100 Mo (brut) / ~35 Mo (compressé)	~50 Mo d'index	Tient en RAM
1 M	~1 Go / ~350 Mo	~500 Mo	Confortable
10 M	~10 Go / ~3,5 Go	~5 Go	Surveiller la mémoire des index, working set
100 M	~100 Go / ~35 Go	~50 Go	Envisager le sharding
1 Md	~1 To / ~350 Go	~500 Go	Sharding requis, cluster multi-nœuds

Spécificités du stockage MongoDB

Compression WiredTiger : Le moteur de stockage par défaut de MongoDB compresse les données (snappy) et les index (compression par préfixe). Ratios de compression typiques :

Type de données	Ratio de compression
Documents riches en JSON	3:1 à 5:1
Données binaires (images, fichiers)	1,1:1 à 1,5:1
Données très répétitives	5:1 à 10:1
Charges mixtes	2:1 à 4:1

Limite de taille de document : 16 Mo par document. Si vous approchez cette limite, votre schéma a besoin d'être repensé — utilisez des références plutôt que l'embedding.

Patterns de schéma MongoDB et leur impact sur la taille

Pattern	Impact sur la taille	Quand l'utiliser
Embedding (documents imbriqués)	Documents plus grands, moins de collections	Données toujours accédées ensemble, croissance bornée
Référencement (clés étrangères)	Documents plus petits, plus de lookups	Croissance non bornée (commentaires, logs), many-to-many
Pattern bucket	Moins de documents, taillé prévisible	Time-séries, IoT — grouper N événements par document
Pattern subset	Garder les données chaudes petites	Gros documents dont seule une partie est fréquemment lue
Pattern outlier	Gérer les exceptions séparément	La plupart des docs petits, quelques-uns énormes (followers de célébrités)

Leviers FinOps MongoDB

Levier	Impact	Effort
Redimensionner le tier du cluster	20–40 % d'économie	Faible — l'auto-scaling Atlas aide
Choisir la bonne shard key	Distribution uniforme → moins de nœuds	Élevé — doit être choisi à la création
Index TTL	Expiration automatique des anciennes données	Faible — ajouter un index TTL sur le champ date
Compacter les collections	Récupérer l'espace après des suppressions massives	Faible — lancer compact ou initial sync
Optimisation du schéma	30–60 % de réduction de taille	Moyen — noms de champs courts, types corrects
Auto-scaling du cluster Atlas	Ne payer que ce qu'on utilisé	Faible — activer dans Atlas
Archiver les données froides vers Atlas Online Archive	50–80 % d'économie sur les anciennes données	Moyen — configurer les règles d'archivage
Clusters réservés (Atlas)	30–50 % vs pay-as-you-go	Faible — engagement financier
Passer du stockage NVMe au standard	20–40 % d'économie sur le stockage	Faible — si les besoins en IOPS sont faibles

Comparatif FinOps : PostgreSQL vs MongoDB

Dimension	PostgreSQL	MongoDB
Efficacité stockage	Stockage en lignes + compression TOAST	Compression WiredTiger (typiquement meilleur par défaut)
Risque de bloat	Élevé (tuples morts MVCC)	Plus faible (WiredTiger gère en interne)
Surcoût des index	Modéré (B-tree)	Plus élevé (chaque collection nécessite un index _id minimum)
Modèle de coût de scaling	Vertical d'abord → coûteux à grande échelle	Horizontal (sharding) → coût croît linéairement
Coût managé (AWS)	RDS/Aurora : instance + stockage + IOPS	DocumentDB/Atlas : instance + stockage + transfert de données
Coût de sauvegardé	Snapshots RDS (gratuit jusqu'à la taille de la DB)	Backup continu Atlas inclus, ou snapshots S3
Licence	Gratuit (open source)	Gratuit (Community) ou payant (Enterprise/Atlas)

Cadre FinOps Général pour les Bases de Données

1. Visibilité — Savoir ce qu'on dépense

Métrique	Objectif
Coût par requête	Suivre avec APM (Datadog, New Relic)
Coût par Go stocké	Comparer entre tiers et fournisseurs
Coût par environnement	Dev/staging souvent 30–50 % du total — utiliser des instances plus petites
Coût des ressources inutilisées	Réplicas non utilisés, bases dev surdimensionnées

2. Optimisation — Réduire le gaspillage

Gains rapides (semaine 1) :

Réduire les instances dev/staging au minimum viable
Activer l'auto-pause pour les bases non-production
Supprimer les snapshots et sauvegardés inutilisés au-delà de la politique de rétention
Éteindre les bases dev en dehors des heures de bureau

Moyen terme (mois 1–3) :

Redimensionner la production selon l'utilisation réelle CPU/mémoire (cible 60–70 %)
Implémenter des politiques de rétention — archiver ou supprimer les anciennes données
Passer aux tarifs réservés/engagement pour les charges stables
Consolider plusieurs petites bases en moins d'instances managées

Stratégique (trimestre 1–2) :

Évaluer le coût total de possession managé vs auto-hébergé
Envisager le stockage multi-tiers (chaud/tiède/froid)
Implémenter le chargeback — les équipes voient leurs coûts de base de données
Automatiser les politiques de scaling basées sur les patterns de charge

3. Gouvernance — Prévenir le gaspillage futur

Pratique	Ce qu'elle prévient
Politique de tagging	Coûts non attribués (imposer les tags équipe/projet/env)
Garde-fous de provisionnement	Développeurs créant des instances surdimensionnées
Alertes de budget	Pics de coûts inattendus
Revues trimestrielles	Dérive des coûts, ressources oubliées
Revues d'architecture pour les nouveaux projets	Mauvais choix de base coûtant 10x à long terme

Exemples de Dimensionnement Réels

Exemple 1 : SaaS B2B — CRM Client

Paramètre	Valeur
Clients	50 000
Enregistrements moyens par client	500 (contacts, deals, activités)
Total lignes	25 M
Taille moyenne d'une ligne	200 octets
Données brutes	~5 Go
Avec index (5 B-tree)	~20 Go
Instance recommandée	db.r6g.large (2 vCPU, 16 Go RAM)
Coût mensuel (RDS PostgreSQL)	~200 €/mois

Exemple 2 : Plateforme IoT — Données Capteurs

Paramètre	Valeur
Capteurs	10 000
Événements par capteur par jour	1 440 (un par minute)
Événements quotidiens	14,4 M
Événements mensuels	~430 M
Taille moyenne d'un événement	150 octets
Données brutes mensuelles	~65 Go
Rétention	12 mois → ~780 Go
Configuration recommandée	Cluster MongoDB shardé (3 shards) ou TimescaleDB avec partitionnement
Coût mensuel	~800–1 500 €/mois (Atlas M40 ou équivalent)

Exemple 3 : E-commerce — Catalogue Produits + Commandes

Paramètre	Valeur
Produits	500 000 (attributs variables → MongoDB)
Commandes	10 M/an (relationnel → PostgreSQL)
Taille du catalogue produits	~2 Go (MongoDB, compressé)
Commandes + lignes de commande	~15 Go/an (PostgreSQL)
Configuration recommandée	Polyglot : PostgreSQL pour les commandes + MongoDB pour le catalogue
Coût mensuel	~350 €/mois combiné

tadata

Table d'événements bronze d'une application grand public : volume brut par an et volume conservé (taille JSON non compressée)

Extrait de la fiche « Lakehouse Design for AI » · Demander la fiche complète

Planification de la Croissance

Taux de croissance	Action
< 10 Go/mois	Surveiller trimestriellement, pas d'urgence
10–100 Go/mois	Planifier une stratégie de partitionnement, mettre en placé l'archivage
100 Go–1 To/mois	Planification de capacité active, envisager sharding/scaling horizontal
> 1 To/mois	Équipe de capacité dédiée, stratégie multi-régions, stockage par tiers

Règle pratiqué : Planifier pour 2x votre projection de données à 12 mois. Le stockage est bon marché ; les migrations d'urgence ne le sont pas.

Ressources

FinOps Foundation — Framework, principes et communauté
AWS Database Cost Optimization — Pilier coût du Well-Architected
PostgreSQL Wiki — Disk Usage — Requêtes officielles de surveillance de taille
MongoDB Sizing Guide — Docs de planification de capacité
pganalyze — Monitoring de performance PostgreSQL avec suivi de taille
Percona Monitoring and Management — Monitoring de DB open-source