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é |
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
:::