- Die MySQL-kompatible serverlose Plattform PlanetScale hat eine Private Preview einer dedizierten Hosting-Plattform für Postgres angekündigt
- Der Fokus liegt auf maximaler Service-Verfügbarkeit und Stabilität sowie auf erstklassigem Engineering wie automatischem Failover
- Ziel sind die typischen Beschwerden bestehender Postgres-Hosting-Nutzer: Kosten, wiederkehrende Ausfälle und geringe Performance
- Performance- und Plattformmerkmale
- Benchmark-Ergebnisse zufolge liegt das Angebot konstant vor allen konkurrierenden Postgres-Produkten (auch gegenüber Wettbewerbern mit doppelt so vielen Ressourcen)
- PlanetScale for Postgres betreibt echtes Postgres mit einem proprietären Operator
- Die Proxy-Schicht PSBouncer bietet hohe Verfügbarkeit mit automatischem Failover, Query Buffering und Connection Pooling
- Verwendet wird Postgres v17; unterstützt werden Online-Migrationen ab Postgres v13 sowie automatische Versions-Updates ohne Downtime
- Der lokale NVMe-SSD-Storage von PlanetScale Metal verbessert das Kosten-/Leistungsverhältnis deutlich
- Skalierungsstrategie und weitere Pläne
- Vitess ist eine auf MySQL ausgerichtete Skalierungslösung und eine Stärke von PlanetScale
- Mit Vitess wird natives Sharding im großen Maßstab bereitgestellt
- In diesem Fall wird Vitess jedoch nicht direkt für die Postgres-Skalierung eingesetzt
- Stattdessen wird von Grund auf ein neues Skalierungssystem speziell für Postgres entwickelt
- Im Verlauf der Entwicklung sollen fortlaufend weitere Informationen und Early Access veröffentlicht werden
2 Kommentare
Ich bin neugierig, wie sie automatische Versions-Updates für PostgreSQL umgesetzt haben. Beim Wechsel der Major-Version müsste es doch das Problem geben, dass das System neu aufgebaut werden muss – wie haben sie das wohl gelöst?
Hacker-News-Kommentare
Jemand teilt die Erfahrung, PlanetScale 1–2 Jahre lang genutzt und dann zu Neon gewechselt zu haben. Für jeden Tenant wurde eine separate Datenbank benötigt, aber PlanetScale verursachte mit einem Preis von 30 $ pro Datenbank und Monat (jetzt 39 $) eine erhebliche Belastung. Der eigene Anwendungsfall sei ungewöhnlich, und es bestehe auch kein Bedarf an leistungsstarken Servern. Es reiche aus, mehrere Datenbanken auf einem Server zu betreiben; bei PlanetScale sei das nicht möglich gewesen, Neon unterstütze es jedoch. Es wird ein kleines Unternehmen betrieben, bei vorhersehbaren Schwankungen im Traffic. Mit dem Produkt und dem Support von PlanetScale sei man sehr zufrieden gewesen und hoffe, es eines Tages wieder zu nutzen. Man entwickle Software für Food-&-Beverage-Festivals; neun Monate im Jahr gebe es fast keinen Traffic, zwei Monate lang etwas, etwa drei Wochen lang etwas mehr, und nur während der 1–5 Festivaltage komme die Lastspitze. Man sei sich bewusst, eine sehr kleine Kundengruppe zu sein, und akzeptiere die Realität, dass die meisten Anbieter nicht direkt auf diese Anforderungen eingehen
Es wird gefragt, ob es regulatorische Vorgaben oder andere Gründe gibt, weshalb pro Tenant unbedingt eine physische Datenbank nötig ist, oder warum innerhalb einer einzigen PlanetScale-DB nicht einfach mehrere logische Datenbanken/Schemas verwendet werden können
Je nach Anzahl der Tenants könnte Turso zu den Anforderungen passen; eine Einführung zu Turso
PlanetScale begann als auf MySQL spezialisierte Lösung, die von Vitess abgeleitet wurde. Es wird gefragt, ob auch das neue PostgreSQL-Produkt mit Vitess zusammenhängt oder ein komplett neu aufgebautes System ist. Nach eigener Recherche wurde im Entwicklungsblog zu PlanetScale for Postgres bestätigt, dass im Unterschied zum auf MySQL basierenden Vitess die Architektur für Postgres von Grund auf neu entworfen wird
Als PlanetScale-MySQL-Nutzer der letzten zwei Jahre freue man sich sehr über den Start von PlanetScale PostgreSQL. In einem früheren Unternehmen habe man beide DBs betrieben, sei aber von den Unterschieden beim Tooling enttäuscht gewesen. PlanetScale vermittle bei der DB-Verwaltung insgesamt ein revolutionär befriedigendes Gefühl, als würde man von einem Treo auf ein iPhone wechseln. Glückwünsche an das PlanetScale-Team
In letzter Zeit seien mehrere interessante Projekte zur Skalierung von PostgreSQL erschienen. Es wird Neugier ausgedrückt, welches Produkt PlanetScale diesmal liefern wird. Persönlich wolle man viel mehr Informationen, werde das aber weiter aufmerksam verfolgen. Als interessante Referenzen werden Supabase Multigres und pgdog geteilt
Es habe Spaß gemacht, mit Postgres zusammenzuarbeiten und dieses neue Produkt auf den Markt zu bringen. Fragen seien willkommen
Das Auftauchen einer neuen hosted-Postgres-Option wird positiv gesehen. Man ist gespannt, welche Unterschiede sich im Wettbewerb zwischen Multigres (Supabase) und PlanetScale zeigen werden
Es wird nach dem Umfang der Erweiterungsunterstützung und etwaigen Einschränkungen bei PlanetScale PostgreSQL gefragt
Etwas am Thema vorbei, aber der MySQL-Kurs für Entwickler auf der PlanetScale-Website wird ebenfalls empfohlen
Der aktuelle Schritt von PlanetScale wird als interessant bewertet. Sobald Daten über eine einzelne Maschine hinausgehen, nehme die Komplexität sprunghaft zu, und bei verteilten Systemen müssten oft Funktionen wie komplexe Joins, Skalierbarkeit und starke Konsistenz gegeneinander abgewogen werden. Es wird gefragt, ob es ähnliche Trade-offs wie bei Vitess (MySQL) gibt oder ob zusätzlich eine Postgres-spezifische Komplexität entsteht. Es wird vorgeschlagen, eine Verifikation durch Jepsen, das Projekt zur Prüfung verteilter Systeme, anzufragen. Außerdem wird darauf hingewiesen, dass es Unterschiede und mögliche Verluste bei Funktionen gegenüber einer Standard-Postgres-Umgebung geben dürfte
Jemand habe die Nachricht spät gesehen, betont aber, dass es großartige Neuigkeiten seien. Es wird gefragt, ob ein Teil der Technologie als Open Source veröffentlicht werden könnte