- MySQL utilise également MVCC, il suffit de checkinnoDB. Mais, dans PostgreSQL, vous pouvez changer le FILLFACTOR pour faire de la place pour les futures mises à jour. Avec cela, vous pouvez créer une base de données qui a de l'espace pour les données actuelles mais aussi pour certaines mises à jour et suppressions futures. Lorsque autovacuum et HOT fonctionnent correctement, la taille de votre base de données peut être stable.
- Le blog concerne les anciennes versions, beaucoup de choses ont changé et PostgreSQL fait un bien meilleur travail de compression qu'auparavant.
- La compression dépend également du type de données, de la configuration et de la vitesse. Vous devez tester pour voir comment cela fonctionne dans votre situation.
J'ai effectué quelques conversions de MySQL vers PostgreSQL et dans tous ces cas, PostgreSQL était environ 10 % plus petit (MySQL 5.0 => PostgreSQL 8.3 et 8.4). Ces 10 % ont été utilisés pour modifier le facteur de remplissage sur les tables les plus mises à jour, celles-ci ont été définies sur un facteur de remplissage de 60 à 70. La vitesse était bien meilleure (plus de problèmes avec plus de 20 utilisateurs simultanés) et la taille des données était également stable, pas de MVCC en cours hors de contrôle ou vide trop loin derrière.
MySQL et PostgreSQL sont deux bêtes différentes, PostgreSQL est une question de fiabilité là où MySQL est populaire.
