PostgreSQL PaaS sur Azure ou AWS RDS face à PostgreSQL autogéré sur VM Linux

Le fournisseur automatise la mécanique de plateforme. Il ne comprend ni votre modèle métier, ni vos requêtes critiques, ni vos contraintes de clôture comptable, ni le coût d’un verrou de 40 minutes. Le DBA disparaît seulement si l’on confond administration système et ingénierie de la donnée.

R = réalise, A = accountable, C = consulté, I = informé. Le tableau doit être adapté à votre organisation, mais l’absence de propriétaire explicite est toujours un risque.

# Exemple conceptuel pgBackRest
[global]
repo1-type=s3
repo1-path=/pgbackrest/prod
repo1-retention-full=4
repo1-bundle=y
repo1-block=y
archive-async=y

[prod]
pg1-path=/var/lib/postgresql/16/main

• Extension ou build non supporté : module interne, bibliothèque C, background worker spécifique.
• Tuning système déterminant : huge pages, scheduler, filesystem, NUMA, kernel, stockage local NVMe.
• Topologie avancée : réplication physique complexe, cascades particulières, delayed replicas, multi-volume.
• Contraintes de souveraineté : environnement hors cloud public ou exigences d’accès local.
• Équipe plateforme mature : automatisation, images, HA, backup, observabilité et astreinte déjà industrialisés.
• Économie à grande échelle : sur certains parcs très importants, une plateforme interne peut amortir ses coûts fixes.

• Applications déjà hébergées dans Azure avec VNet, Entra ID, Managed Identity et Azure Monitor.
• Organisations Microsoft-centric souhaitant centraliser identités, politiques, clés et observabilité.
• Workloads PostgreSQL standards qui profitent d’un PgBouncer intégré et d’une HA zone-redundant.
• Équipes qui veulent réduire la surface Linux/DB à maintenir sans abandonner PostgreSQL.
• Plateformes où Bicep/Terraform et Azure Policy servent déjà de cadre de déploiement.

# Extrait conceptuel Terraform — Azure
resource "azurerm_postgresql_flexible_server" "db" {
  name                   = var.name
  resource_group_name    = var.resource_group
  location               = var.location
  version                = var.pg_version
  delegated_subnet_id    = var.subnet_id
  private_dns_zone_id    = var.private_dns_zone_id
  sku_name               = var.sku_name
  storage_mb             = var.storage_mb
  backup_retention_days  = var.backup_retention_days
  geo_redundant_backup_enabled = var.geo_backup

  high_availability {
    mode = var.ha_mode
  }
}

• Créer explicitement réseau, DNS privé, identité, logs diagnostics et alertes.
• Versionner les paramètres PostgreSQL séparément.
• Ajouter locks/policies/tags/budget et RBAC.
• Ne jamais considérer le module “terminé” sans test de connexion, backup et failover.

# Extrait conceptuel Terraform — AWS RDS
resource "aws_db_instance" "db" {
  identifier                 = var.name
  engine                     = "postgres"
  engine_version             = var.pg_version
  instance_class             = var.instance_class
  allocated_storage          = var.storage_gib
  max_allocated_storage      = var.max_storage_gib
  storage_type               = var.storage_type
  multi_az                   = var.multi_az
  backup_retention_period    = var.backup_retention_days
  db_subnet_group_name       = var.subnet_group
  vpc_security_group_ids     = var.security_groups
  parameter_group_name       = aws_db_parameter_group.pg.name
  storage_encrypted          = true
  deletion_protection        = true
}

• Séparer subnet group, security groups, KMS, parameter group et option de monitoring.
• Décider explicitement Multi-AZ instance vs Multi-AZ cluster.
• Activer deletion protection et snapshot final selon politique.
• Associer alarmes CloudWatch et événements RDS.

• Backups automatiques de l’instance complète et journaux permettant un point-in-time restore.
• Rétention de 0 à 35 jours pour une DB instance ; 0 désactive les backups automatiques. Pour un Multi-AZ DB cluster, la plage est de 1 à 35 jours.
• Restauration vers une nouvelle instance ou un nouveau cluster.
• Snapshots manuels conservés indépendamment de la fenêtre automatique jusqu’à suppression.
• Réplication de backups entre régions disponible dans certains modes, avec différences selon la topologie.
• Export ou sauvegarde logique nécessaire pour les scénarios de portabilité fine.

AWS détecte différents événements de panne et orchestre le failover. L’application doit cependant gérer les connexions cassées, la résolution DNS, les transactions interrompues et le retry contrôlé.

• Définir synchronous_mode, maximum_lag_on_failover et stratégie de quorum.
• Garantir qu’un ancien primaire ne puisse pas continuer à écrire.
• Tester partition réseau, perte DCS, perte stockage, perte zone et failback.
• Automatiser rebuild et rejoin des anciens primaires.

• Reconnecter proprement après rupture de socket.
• Utiliser des timeouts de connexion et de requête.
• Limiter les retries et appliquer du jitter/backoff.
• Rendre idempotentes les opérations rejouables.
• Identifier les transactions dont le résultat est inconnu après coupure.
• Verrouiller les migrations et jobs sensibles pendant les bascules planifiées.
• Tester les pools : PgBouncer, RDS Proxy, HikariCP, Npgsql, psycopg, etc.

• Read replicas RDS for PostgreSQL utilisant la réplication streaming PostgreSQL.
• Replicas intra-région et inter-région possibles.
• Promotion d’une replica vers une instance autonome possible.
• Multi-AZ DB cluster fournit également deux readers intégrés.
• RDS Proxy peut réduire le coût de connexion et améliorer le comportement lors de failovers dans certains scénarios.

# Pseudo-routing
if request.requires_strong_consistency:
    use(writer)
elif session.has_recent_write:
    use(writer)
else:
    use(read_replica_pool)

• Geo-replication via read replicas vers d’autres régions supportées.
• Geo-redundant backup à choisir à la création, avec copie asynchrone et restauration dans la région jumelée.
• La documentation indique qu’un geo-restore peut avoir jusqu’à environ une heure de RPO selon la réplication de sauvegarde.
• Pour des workloads critiques, les geo-replicas et endpoints stables doivent être étudiés plutôt qu’un simple backup distant.
• La bascule régionale reste une décision client : Azure fournit les briques, pas votre validation métier.

• Cross-Region read replicas pour PostgreSQL.
• Réplication de backups automatiques inter-région disponible dans certains modes ; vérifier la topologie choisie.
• Snapshots manuels copiables entre régions et comptes selon politique.
• Route 53, RDS Proxy, secrets et KMS doivent être prévus pour la région de secours.
• La promotion d’une replica est une action distincte du failover Multi-AZ.

1. Déclarer la région primaire indisponible selon des critères objectifs.
2. Geler les écritures si un risque de double writer existe.
3. Promouvoir/restaurer la cible DR.
4. Appliquer paramètres, extensions, rôles, secrets et intégrations.
5. Basculer DNS/endpoints et valider propagation.
6. Exécuter contrôles fonctionnels et réconciliation.
7. Communiquer RPO réel et données potentiellement absentes.
8. Préparer la stratégie de retour vers la région d’origine.

• RDS déployé dans un VPC avec DB subnet group et security groups.
• Public accessibility à désactiver par défaut pour la production.
• IAM Database Authentication avec tokens temporaires ; le rôle rds_iam modifie le mode d’authentification du rôle PostgreSQL.
• AWS Secrets Manager pour stocker et faire tourner les credentials.
• KMS pour le chiffrement du stockage, snapshots et replicas d’une instance chiffrée.
• CloudWatch Logs, events et CloudTrail pour la traçabilité du plan de contrôle.

-- Exemple de séparation
CREATE ROLE app_owner NOLOGIN;
CREATE ROLE app_runtime LOGIN;
CREATE SCHEMA app AUTHORIZATION app_owner;
GRANT USAGE ON SCHEMA app TO app_runtime;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_runtime;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_runtime;

RDS crée un rôle administratif disposant de rds_superuser, mais le rôle postgres n’a pas l’attribut PostgreSQL SUPERUSER. AWS remplace certaines opérations par des rôles ou fonctions RDS spécifiques.

• Pas de host access.
• Pas de vrai superuser.
• Restrictions sur certaines vues, fonctions et procédures système.
• Tâches adaptées via rds_superuser, rds_replication, rdsadmin ou procédures documentées.
• Certaines commandes de dump/import global nécessitant superuser doivent être adaptées.

• Le workload utilise des extensions courantes déjà supportées.
• Le diagnostic s’effectue correctement via pg_stat_statements, vues système, logs et métriques.
• Le tuning repose surtout sur SQL, index, mémoire, connexions et capacité.
• Les exigences de sécurité préfèrent justement l’absence d’accès OS.
• L’organisation ne souhaite pas supporter une plateforme Linux/PostgreSQL complète.

1. Inventorier extname/extversion.
2. Vérifier version cible exacte.
3. Tester CREATE/ALTER EXTENSION.
4. Identifier shared_preload_libraries.
5. Vérifier droits superuser et dépendances OS.
6. Tester restore et upgrade majeur.

Sur VM, les tablespaces permettent un placement physique, mais ajoutent une forte complexité aux backups, restores, migrations, permissions et remplacements de volumes. Beaucoup de conceptions historiques les utilisent alors qu’un stockage moderne uniforme suffit.

-- Extensions
SELECT extname, extversion FROM pg_extension ORDER BY 1;

-- Paramètres non par défaut
SELECT name, setting, unit, source, context, pending_restart
FROM pg_settings
WHERE source <> 'default'
ORDER BY 1;

-- Tablespaces
SELECT oid, spcname, pg_tablespace_location(oid)
FROM pg_tablespace
ORDER BY 2;

-- Shared preload
SHOW shared_preload_libraries;

-- Réplication logique et physique
SELECT * FROM pg_replication_slots;
SELECT * FROM pg_publication;
SELECT * FROM pg_subscription;
SELECT * FROM pg_stat_replication;

• Définir un maximum de stockage pour éviter une croissance financière sans limite.
• Alerter sur free space, WAL growth, bloat, temp files et slots de réplication.
• Prévoir que l’augmentation ne corrige pas une fuite de WAL ou un index inutile.
• Tester l’impact d’un scale sur connexions, réplication logique et maintenance.
• Conserver un capacity model : croissance mensuelle, saisonnalité, marge et délai d’action.

Capacité utile = max(
  working_set_memory,
  peak_concurrency_memory,
  maintenance_memory,
  OS/service overhead
)

Stockage cible = data + indexes + bloat + temp + WAL reserve + growth_margin

IOPS cible = foreground reads/writes + WAL + checkpoints + vacuum + backup/replication

1. Qualifier le symptôme : latence, throughput, timeout, CPU, I/O, lock ou connexion.
2. Comparer période saine et période lente.
3. Identifier les waits dominants et les top SQL.
4. Vérifier saturation CPU/mémoire/IOPS/connexions.
5. Analyser plans et volumes réellement lus.
6. Contrôler autovacuum, bloat, checkpoints et WAL.
7. Valider une hypothèse avec test reproductible.
8. Mesurer après correction et conserver le rollback.

SELECT pid, usename, state, wait_event_type, wait_event,
       now() - query_start AS age, left(query, 200)
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

SELECT queryid, calls, total_exec_time, mean_exec_time, rows,
       shared_blks_hit, shared_blks_read
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

Azure Flexible Server propose PgBouncer intégré sur certains tiers. Le mode transaction est généralement le point de départ pour absorber de nombreuses connexions applicatives, mais il modifie la sémantique des sessions.

RDS Proxy mutualise les connexions et peut améliorer la résilience des applications lors de failovers en reconnectant vers un standby. Il est utile pour les architectures à forte création de connexions, notamment serverless, mais il ajoute un composant, un coût et des contraintes de compatibilité.

• Évaluer le pinning de session.
• Mesurer le nombre de connexions DB réellement ouvertes.
• Tester authentification Secrets Manager/IAM.
• Valider le comportement pendant failover.
• Ne pas cumuler plusieurs pools sans modèle clair.

# Modèle simplifié
DB active connections = min(
  pool_size_per_instance * application_instances,
  database_safe_concurrency
)

# Exemple
20 connexions par pod * 50 pods = 1000 connexions potentielles
Si la DB ne doit accepter que 150 transactions concurrentes :
- pool externe / proxy
- pool local réduit
- backpressure applicative

• Métriques Azure Monitor émises à intervalle régulier, avec alertes et rétention selon la plateforme.
• Diagnostic settings pour exporter logs et métriques vers Log Analytics, Event Hub ou stockage.
• Métriques de connexions, stockage, CPU, réplication, HA et disponibilité.
• Alertes sur is-db-alive, storage, CPU, connections waiting, replica lag et HA health.
• Workbooks/dashboards pour une vue plateforme.

• CloudWatch metrics et alarms.
• Enhanced Monitoring pour des métriques OS et processus exposées par RDS.
• Performance Insights / CloudWatch Database Insights pour DB load, waits, SQL, hosts et users.
• Export des logs PostgreSQL vers CloudWatch Logs.
• RDS Events et EventBridge/SNS pour maintenance, failover et incidents.

• Fenêtre de maintenance configurable.
• Auto minor version upgrade activable ou non selon l’instance et la politique.
• RDS applique une version mineure après test et approbation AWS, durant la fenêtre.
• Mises à jour OS et maintenance pending visibles via console/API.
• Une action déjà démarrée ne se diffère plus ; certaines actions peuvent être appliquées manuellement.

• Veille CVE Linux, OpenSSL, glibc, PostgreSQL et extensions.
• Construction d’image ou patch in-place.
• Répétition sur standby, switchover, patch ancien primaire, rejoin.
• Validation des dépôts et signatures.
• Rollback package/image et compatibilité data directory.
• Astreinte en cas de kernel panic, package cassé ou extension incompatible.

1. Inventorier version moteur, extensions, drivers et paramètres.
2. Lire release notes fournisseur et PostgreSQL.
3. Exécuter tests de régression et charge.
4. Vérifier backups/PITR avant fenêtre.
5. Communiquer impact et freeze applicatif éventuel.
6. Surveiller failover/restart et temps de reconnexion.
7. Contrôler version, logs, réplication, jobs et performance après maintenance.
8. Documenter anomalies et décider du rollback si possible.

• Upgrade majeur in-place proposé sur chemins supportés.
• Validation/prechecks disponibles et à exécuter avant planification.
• Le processus déploie la dernière version mineure supportée de la cible.
• La durée dépend du volume et surtout du nombre/complexité des objets et extensions.
• Logical replication slots et extensions peuvent bloquer ou nécessiter un traitement spécifique.
• Toujours prévoir une restauration ou migration alternative si l’upgrade ne peut pas être annulé simplement.

• Les upgrades majeurs sont déclenchés manuellement.
• Prechecks vérifient différents blocages : prepared transactions, extensions, types, etc.
• Read replicas et Multi-AZ ont des comportements spécifiques selon topologie.
• Blue/Green Deployments peuvent réduire le risque pour certains scénarios mais ont des limitations, notamment avec logical replication et objets non répliqués.
• Une fois l’upgrade réalisé, le retour nécessite généralement restauration d’un snapshot vers une nouvelle instance.

1. Créer un clone ou restaurer un environnement représentatif.
2. Exécuter les prechecks officiels.
3. Mettre à niveau les extensions et corriger les objets bloquants.
4. Rejouer tests fonctionnels et charge.
5. Comparer top SQL et plans avant/après.
6. Mesurer la durée réelle.
7. Choisir in-place, logical migration ou blue/green.
8. Définir point de non-retour et procédure de rollback.
9. Préparer DNS, secrets, monitoring et jobs sur la cible.

• Activation via paramètres exposés et restart selon besoin.
• Le rôle admin peut recevoir le droit REPLICATION dans le cadre documenté.
• Les slots inutilisés peuvent conduire à une accumulation WAL ; le service peut appliquer des protections spécifiques.
• Avec HA et scaling near-zero-downtime, utiliser les mécanismes documentés pour préserver/synchroniser les slots, par exemple pg_failover_slots lorsque pertinent.
• Tester le comportement exact de la version et de la région cible.

• Activation via rds.logical_replication et paramètres associés.
• Logical slots disponibles pour DMS, pg_recvlogical, Debezium ou réplication native.
• Un slot n’a aucune connaissance du consumer : un consumer arrêté peut remplir le stockage.
• Multi-AZ DB clusters supportent logical replication sur versions minimales précises ; vérifier le moteur exact.
• Blue/Green et logical replication ont plusieurs limitations documentées.

• Réplication physique entrante/sortante non standard.
• Cascades complexes et contrôle complet des slots physiques.
• Plugins de décodage custom.
• Accès direct aux WAL et outils bas niveau.
• Topologies multi-datacenter hybrides très spécifiques.
• Besoin de patcher le code de réplication ou d’utiliser une build custom.

1. Geler les DDL et déploiements.
2. Verrouiller ou arrêter les écritures.
3. Attendre le rattrapage CDC/replication.
4. Valider row counts, checksums logiques et séquences.
5. Créer/valider rôles, grants, extensions et paramètres.
6. Basculer secrets, endpoint ou DNS.
7. Purger/recréer les pools de connexions.
8. Exécuter smoke tests et contrôles métier.
9. Surveiller erreurs, waits, lag, CPU, connexions et jobs.
10. Déclarer le point de non-retour.

• Rollback avant ouverture des écritures : simple retour endpoint.
• Rollback après écritures : réplication inverse, double-write maîtrisé ou acceptation d’une perte/reconciliation.
• Conserver la source read-only pendant la période de validation.
• Définir seuils objectifs : erreurs, latence, intégrité, jobs, réplication.
• Chronométrer la décision : plus on attend, plus le retour devient complexe.

L’alternative est souvent suffisante pour les incidents standards, mais moins puissante pour les anomalies bas niveau. Le contrat de support fournisseur devient alors une partie de l’architecture.

• Définir le niveau de support adapté à la criticité.
• Documenter les IDs de souscription/compte, régions et ressources.
• Conserver un template de ticket P1.
• Savoir quelles métriques/logs joindre.
• Connaître les limites de responsabilité : requête SQL lente vs panne de plateforme.
• Tester l’escalade avant une crise majeure.

Incident P1 template
- Resource / Region / AZ:
- Start time UTC:
- Business impact:
- Endpoint and engine version:
- HA mode:
- Recent changes:
- Metrics screenshots/exports:
- PostgreSQL errors:
- Reproduction:
- Mitigation attempted:
- Requested provider action:

# Exemple pédagogique annuel en euros — valeurs fictives
PaaS:
  compute + HA          42 000 €
  storage/backups       12 000 €
  monitoring/network     6 000 €
  support                8 000 €
  effort humain         35 000 €
  TOTAL                103 000 €

VM auto-gérée:
  VMs + storage         34 000 €
  backup/monitoring      9 000 €
  effort humain         75 000 €
  astreinte/incidents   20 000 €
  TOTAL                138 000 €

# Le résultat peut s’inverser à très grande échelle ou avec une plateforme interne mature.

• Right-size par métriques p95/p99, pas par intuition.
• Réduire le nombre de replicas inutilisées.
• Réserver/engager la capacité stable selon offres cloud.
• Piloter logs et rétention.
• Éviter le surdimensionnement de stockage irréversible.
• Traiter bloat, indexes inutiles et WAL excessif.
• Séparer workloads critiques et non critiques.
• Arrêter ou réduire dev/test lorsque possible.
• Attribuer coût par application/tenant.

• Rôles et grants versionnés.
• Séparation owner/runtime/read-only.
• Audit des connexions et DDL selon mécanismes supportés.
• Rétention des logs conforme et maîtrisée.
• Revue périodique des comptes inactifs.
• Rotation des secrets et certificats.
• Masquage/anonymisation des clones non production.
• Classification des données et règles d’export.

La conformité est une chaîne. Le PaaS réduit la quantité de contrôles d’infrastructure à produire, mais les contrôles de données, d’identité, de réseau, de journalisation et de reprise restent à votre charge.

• Architecture des rôles et privilèges.
• Tuning SQL et plans d’exécution.
• Capacity planning et FinOps.
• Qualification des limites par version/SKU/région.
• Tests de restauration, failover et DR.
• Automatisation IaC et policy as code.
• Conseil aux développeurs et gouvernance des migrations.
• Observabilité orientée métier.

Le rôle évolue vers Database Reliability Engineering : fiabilité, automatisation, performance, coûts et design des données. Le DBA n’est plus propriétaire du Linux, mais reste responsable du comportement de la base pour l’entreprise.

• Extension native non supportée et non remplaçable.
• Accès obligatoire au filesystem ou à l’OS.
• Version PostgreSQL non disponible dans la fenêtre projet.
• Topologie de réplication incompatible.
• Exigence de stockage/tablespace physique.
• RPO/RTO non satisfaisable par les options disponibles.
• Région ou certification indisponible.
• Limite de taille, connexions ou IOPS incompatible.

• Choisir explicitement Multi-AZ DB instance ou Multi-AZ DB cluster.
• RDS Proxy pour workloads à forte création de connexions.
• Cross-region replica ou backup copy selon RPO/RTO.
• Parameter groups versionnés.
• Deletion protection, snapshot final et Config/CloudTrail.

• Au moins trois nœuds DCS ou service de quorum fiable.
• Fencing explicite.
• Backups indépendants de la réplication.
• Runbooks de switchover, failover, rejoin et rebuild.
• Patch management Linux/PostgreSQL automatisé.

Un choix peut être hybride : PaaS pour la majorité des bases standards et plateforme VM pour les quelques workloads incompatibles. Cette stratégie évite de construire une plateforme complexe pour 100 % des bases à cause de 5 % de cas particuliers.

• Équipe et astreinte disponibles.
• Fréquence incidents et changements.
• Processus backup/restore actuel.
• Maintenance windows acceptables.
• Niveau de support cloud.
• Observabilité et SLO.
• Procédures de failover/DR.
• Compétences IaC et réseau.
• Politique de patching et upgrades.

• Région et résidence des données.
• Exigence de clé gérée client.
• Réseau public interdit ?
• Identité fédérée requise ?
• Audit DDL/connexion.
• Immutabilité backup.
• PIM/MFA/break-glass.
• Masquage non-prod.
• Rétention légale.
• Exigence d’accès OS ou agent.

Le PaaS ne supprime pas PostgreSQL : il supprime surtout une partie de la plateforme autour. Azure et AWS prennent en charge l’hôte, l’installation, les backups physiques, le PITR, le remplacement de nœud, les options HA, les patchs de plateforme et les métriques. Cela réduit fortement le travail répétitif et le risque de construire soi-même une orchestration fragile.

En échange, le fournisseur garde le contrôle ultime. On ne se connecte pas en root, on ne voit pas PGDATA, on ne dispose pas du vrai superuser, et l’on dépend d’un catalogue de versions, paramètres, extensions et tailles. Certaines réplications avancées, tablespaces, modules natifs ou diagnostics bas niveau deviennent impossibles.

Le bon choix dépend donc du workload. Pour une application métier standard, le PaaS est souvent le meilleur défaut. Pour un PostgreSQL custom, une extension interne, un besoin de kernel/filesystem ou une topologie très particulière, la VM reste justifiée. Dans les deux cas, le DBA garde la responsabilité des requêtes, index, transactions, rôles, capacité, coûts, migrations et tests de reprise.

-- Sessions actives
SELECT pid, usename, state, wait_event_type, wait_event,
       now() - query_start AS age, left(query, 150)
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

-- Verrous bloquants
SELECT blocked.pid AS blocked_pid,
       blocker.pid AS blocker_pid,
       blocked.query AS blocked_query,
       blocker.query AS blocker_query
FROM pg_stat_activity blocked
JOIN pg_locks bl ON bl.pid = blocked.pid AND NOT bl.granted
JOIN pg_locks kl ON kl.locktype = bl.locktype
                AND kl.database IS NOT DISTINCT FROM bl.database
                AND kl.relation IS NOT DISTINCT FROM bl.relation
                AND kl.page IS NOT DISTINCT FROM bl.page
                AND kl.tuple IS NOT DISTINCT FROM bl.tuple
                AND kl.transactionid IS NOT DISTINCT FROM bl.transactionid
                AND kl.classid IS NOT DISTINCT FROM bl.classid
                AND kl.objid IS NOT DISTINCT FROM bl.objid
                AND kl.objsubid IS NOT DISTINCT FROM bl.objsubid
                AND kl.granted
JOIN pg_stat_activity blocker ON blocker.pid = kl.pid;

-- Taille et bloat indicatif
SELECT schemaname, relname, n_live_tup, n_dead_tup,
       last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

• Aucun test PITR.
• Compte admin dans l’application.
• Base publique sur Internet sans justification.
• Extension non vérifiée avant migration.
• max_connections augmenté sans modèle mémoire.
• Replica utilisée comme backup.
• Logical slot sans monitoring.
• HA activée mais failover jamais testé.
• Autoscaling stockage sans plafond ni alerte.
• Upgrade majeur sans rollback.
• Pas de propriétaire DBA/DBRE.
• Comparaison de coût basée sur une seule VM.

PaaS par défaut si:
- PostgreSQL standard
- extensions supportées
- pas de root/filesystem requis
- besoin de réduire l’exploitation
- réseau/identité cloud utiles

VM si:
- extension/build custom
- accès OS/PGDATA obligatoire
- tuning kernel/storage déterminant
- topologie de réplication spécifique
- plateforme DBA/SRE déjà mature

• Amazon RDS for PostgreSQL
• Déploiements Multi-AZ
• Read replicas RDS PostgreSQL
• Backups automatiques RDS
• Rôle rds_superuser
• Extensions RDS PostgreSQL
• Parameter groups PostgreSQL
• IAM Database Authentication
• Performance Insights / Database Insights
• Upgrades PostgreSQL RDS

• High Availability, Load Balancing and Replication
• Continuous Archiving and PITR
• Logical Replication
• Server Configuration
• Monitoring Database Activity
• Routine Vacuuming
• Privileges