- PlanetScale, la plateforme serverless compatible MySQL, a annoncé une préversion privée de sa plateforme d’hébergement dédiée à Postgres
- L’accent est mis sur une haute disponibilité du service et la stabilité, avec une volonté de proposer une ingénierie de premier plan incluant le basculement automatique
- La cible est claire : répondre aux frustrations des utilisateurs actuels de Postgres en matière de coût, pannes récurrentes et performances insuffisantes
- Performances et caractéristiques de la plateforme
- Selon les benchmarks, elle surpasse systématiquement toutes les offres Postgres concurrentes (y compris face à un concurrent fournissant 2x plus de ressources)
- PlanetScale for Postgres exécute le véritable Postgres avec un Operator propriétaire
- La couche proxy PSBouncer apporte une haute disponibilité avec basculement automatique, mise en tampon des requêtes et pool de connexions
- Utilise Postgres v17, avec prise en charge des migrations en ligne depuis Postgres v13 et des mises à jour automatiques de version sans temps d’arrêt
- Le stockage NVMe SSD local de PlanetScale Metal améliore fortement le ratio coût/performance
- Stratégie de montée en charge et feuille de route
- Vitess est la solution de scalabilité centrée sur MySQL et l’un des points forts de PlanetScale
- Vitess permet un sharding natif à grande échelle
- Mais cette fois, Vitess n’est pas utilisé directement pour la scalabilité de Postgres
- Un nouveau système de scalabilité dédié à Postgres est en cours de conception depuis zéro
- Davantage d’informations et d’accès anticipé seront publiés au fil de l’avancement du développement
2 commentaires
Je suis curieux de savoir comment ils ont mis en place les mises à jour automatiques de version de PostgreSQL. Lors d’un changement de version majeure, il doit y avoir un problème qui nécessite de reconstruire le système ; comment l’ont-ils résolu ?
Commentaires Hacker News
Partage d’une expérience après avoir utilisé PlanetScale pendant 1 à 2 ans avant de passer à Neon. Il fallait une base de données distincte par tenant, mais PlanetScale facturait 30 $ par mois par base de données (désormais 39 $), ce qui est devenu coûteux. Mon cas d’usage est atypique et je n’ai pas besoin de serveurs puissants. Il me suffit de faire tourner plusieurs bases sur un même serveur, ce qui n’était pas possible avec PlanetScale mais est pris en charge par Neon. Je gère une petite entreprise avec des variations de trafic prévisibles. J’étais très satisfait du produit PlanetScale et de son support, et j’aimerais y revenir un jour. Je développe des logiciels pour des festivals de gastronomie et de boissons : pendant 9 mois par an, il n’y a presque pas de trafic, pendant 2 mois il y en a un peu, pendant environ 3 semaines il est un peu plus élevé, et la charge ne se concentre vraiment que sur 1 à 5 jours durant le festival. Je suis conscient d’être un client minuscule et j’accepte que la plupart des entreprises ne répondent pas directement à ce type de besoin
Je me demande s’il y a une contrainte réglementaire ou une autre raison qui impose une base de données physique par tenant, ou si c’est simplement qu’on ne peut pas utiliser plusieurs bases/logiques ou schémas au sein d’une seule base PlanetScale
Selon le nombre de tenants, Turso pourrait peut-être correspondre à mes besoins ; présentation de Turso
PlanetScale est à l’origine une solution spécialisée MySQL dérivée de Vitess. Je me demande si ce produit PostgreSQL a lui aussi un lien avec Vitess, ou s’il s’agit d’un système entièrement nouveau. Après vérification, d’après le blog de développement de PlanetScale for Postgres, contrairement à Vitess basé sur MySQL, l’architecture est repensée depuis zéro pour Postgres
En tant qu’utilisateur de PlanetScale MySQL depuis 2 ans, je suis ravi de cette annonce de PlanetScale PostgreSQL. Dans mon ancienne entreprise, nous faisions tourner les deux bases, mais c’était frustrant d’avoir des différences d’outillage. PlanetScale offre une expérience de gestion des bases qui donne globalement la même impression que de passer d’un Treo à un iPhone. Message de félicitations à l’équipe PlanetScale
Ces derniers temps, plusieurs projets intéressants autour de la scalabilité de PostgreSQL apparaissent les uns après les autres. J’attends avec intérêt de voir ce que PlanetScale va proposer cette fois. Personnellement, j’aimerais avoir bien plus d’informations, mais je vais continuer à suivre cela. Partage de liens vers des projets à surveiller : Supabase Multigres, pgdog
Ce fut un plaisir de collaborer avec Postgres pour lancer ce nouveau produit sur le marché. N’hésitez pas si vous avez des questions
Je trouve très positif l’arrivée d’une nouvelle option de Postgres hébergé. J’ai hâte de voir quelle différenciation émergera entre Multigres (Supabase) et PlanetScale
Question sur l’étendue de la prise en charge des extensions dans PlanetScale PostgreSQL, ainsi que sur les limitations éventuelles
Un peu hors sujet, mais recommandation du cours MySQL pour développeurs sur le site de PlanetScale
Juge cette initiative de PlanetScale intéressante. Dès que les données dépassent les limites d’une seule machine, la complexité augmente brutalement et, dans les systèmes distribués, il faut souvent sacrifier certaines fonctionnalités comme les complex join, la scalabilité ou une forte cohérence. Je me demande s’il y a des compromis similaires à ceux de Vitess (MySQL), ou si des complexités propres à Postgres s’ajoutent. Proposition de faire vérifier le système par Jepsen (projet de validation des systèmes distribués). Souligne qu’il faudra clarifier quelles différences fonctionnelles et quelles pertes existent par rapport à un environnement PlanetScale et à un Postgres standard
J’ai vu la nouvelle tardivement, mais c’est une excellente annonce. Question sur la possibilité qu’une partie de cette technologie soit publiée en open source