Postgres vs MySQL: Lequel est le plus difficile à mettre à l'échelle?

D'après votre expérience, quelle base de données est plus difficile à mettre à l'échelle? MySQL ou Postgres? Je sais que MySQL a plusieurs fonctionnalités de mise à l'échelle / clustering prêtes à l'emploi, mais avec Postgres, il n'y en a aucune qui soit prête à l'emploi. CMIIW.

MODIFIER :

Désolé pour la confusion ici, ma question fait référence à la mise à l'échelle (mise à l'échelle horizontale), c'est-à-dire la mise en cluster, le partitionnement, etc. Je sais que les deux peuvent évoluer horizontalement, mais lequel est plus facile à mettre en œuvre?

Merci pour le partage.

MySQL est BEAUCOUP plus facile à évoluer, le clustering et la réplication sont à la fois natifs et très faciles à gérer et à implémenter (même pour quelqu'un qui n'a pas vraiment de connaissances en bases de données).

PostgreSQL ne prend en charge que la réplication de base pour l'instant, et rien de officiel sur le clustering (techniquement, vous pouvez le faire via des outils tiers, mais cela devient un enfer à gérer).

Je ne choisirais jamais Postgresql si je compte évoluer.

Edit: réponse très ancienne avec un grain de sel car postgres et mysql ont beaucoup changé depuis que cela a été répondu.

Bien que cette question semble aller à l'encontre du principe «Évitez de poser des questions subjectives ou argumentatives» du site, je ne résiste pas à essayer de répondre.

Ça dépend.

Parlez-vous d'une configuration de serveur unique qui évolue vers de très grands ensembles de données?
Les deux peuvent fonctionner dans cette situation en fonction de l'ensemble de données, mais aucun ne fonctionnera probablement très bien sans configuration personnalisée et planification appropriée. D'après mon expérience lorsque je travaille sur de grands ensembles de données avec beaucoup d'écritures, j'ai trouvé que Postgres a moins de conditions qui provoquent le blocage et les performances globales étaient meilleures.

Parlez-vous de configurations multi-serveurs qui s'adaptent à de nombreux esclaves pour de nombreux lecteurs?
MySQL a toujours été considéré comme le leader dans cet espace depuis qu'il est livré avec une réplication asynchrone intégrée. Ce n'est plus le cas si vous n'êtes pas opposé à l'utilisation du logiciel DB le plus récent; Postgres intègre désormais cette fonctionnalité avec la version 9.0. Mes expériences avec la réplication de MySQL ont été plus que suffisantes jusqu'à présent.

Parlez-vous de configurations multi-serveurs qui s'adaptent à de nombreux maîtres pour de nombreux écrivains?
C'est de loin le moyen le plus difficile de faire évoluer l'un ou l'autre produit et peut être évité de nombreuses fois grâce à l'utilisation de serveurs de basculement. Si vous avez vraiment besoin d'évoluer pour une haute disponibilité des serveurs maîtres, les extensions / installations alternatives ne peuvent pas être évitées. Pour MySQL, il y a MySQL Cluster NDB qui a une option open source ou une version commerciale . Pour Postgres, il existe de nombreux addons qui peuvent vous offrir différents niveaux de HA et de mise en commun

À long terme, la mise à l'échelle de votre base de données se résume généralement à la planification de la conception. Si votre application est conçue en tenant compte de l'échelle, le système db qui correspond le mieux à vos développeurs est souvent le meilleur choix.

PostGre a plus de fonctionnalités et d'options de configuration.

Il est donc probablement plus difficile à mettre à l'échelle, mais il est également probable qu'il évolue mieux, c'est-à-dire s'il est correctement configuré.

En général, MySQL sera probablement encore plus rapide, d'un autre côté, la vraie question est de savoir combien appréciez-vous l'intégrité des données, et de quelles fonctionnalités avez-vous besoin, et voulez-vous dépendre d'Oracle (qui possède désormais MySQL)?

De plus, il y a des questions de licence, comme voulez-vous vraiment acheter une licence MySQL juste parce que vous ne voulez pas publier votre application sous la GPL?
Avec PostGreSQL, ce n'est pas un problème, ce qui est un très gros avantage.