Von Neon wechseln

Beide Produkte geben dir PostgreSQL. Der Unterschied liegt darunter: Neon trennt Speicher von Rechenleistung und verzweigt auf der Speicherebene; CapyDB betreibt einen gewöhnlichen PostgreSQL-Prozess auf einem eigenen Speicherbereich und klont diesen zum Verzweigen. Spürbar ist die Folge, dass sich eine CapyDB-Zelle wie das Postgres auf deinem Laptop verhält – weil sie eines ist.

Schema, Abfragen, Extensions und Migrationen ziehen unverändert um. Aufmerksamkeit braucht die Verbindungsschicht und alles, was gegen einen anbieterspezifischen Treiber geschrieben ist.

• -Verzweigen: Preview-Datenbanken sind Klone mit Ablaufzeit, eine pro Pull Request
• -Ruhezustand: eine untätige Zelle schläft ein und wacht bei der nächsten Verbindung auf, typischerweise in weniger als einer Viertelsekunde
• -Ein gepoolter Endpunkt für Serverless- und Edge-Laufzeiten und ein direkter für alles andere
• -Point-in-Time-Recovery aus laufender Archivierung statt aus nächtlichen Snapshots
• -Eine Plattformintegration für das Deployment-Ziel, auf dem du ohnehin bist

• -Kein HTTP- oder WebSocket-Treiber: Du verbindest dich über das PostgreSQL-Wire-Protokoll, das jeder Treiber ohnehin spricht
• -Isolation bedeutet einen ganzen Prozess und einen Speicherbereich pro Projekt, nicht einen Mandanten in einer geteilten Rechenschicht
• -Rechenleistung ist eine feste CPU- und Speicherobergrenze je Tarif statt automatisch skalierender Einheiten
• -Standardzellen haben keinen ausgehenden Netzwerkzugang, deshalb sind Extensions mit externen Aufrufen bauartbedingt nicht verfügbar

Wenn dein Projekt einen Neon-spezifischen Serverless-Treiber importiert, schreibt die CLI ihn für dich um: Der Codemod tauscht den Client gegen einen normalen PostgreSQL-Treiber, korrigiert den Verbindungsaufbau und meldet die Aufrufstellen, über die er nicht entscheiden konnte, statt zu raten.

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

Starte einen Import gegen deinen bestehenden Connection String. Der Follow-Modus hält die neue Zelle mit der Quelle synchron, während du testest – die Umstellung ist dann eine Änderung von DNS und Umgebungsvariablen statt ein Wartungsfenster.

capydb import \
  --project my-app \
  --source-url "$OLD_DATABASE_URL" \
  --follow

• -Mit Follow importieren und laufen lassen, während du deine Testsuite gegen die Zelle fährst
• -capydb doctor ausführen, um Umgebungsvariablen zu finden, die noch auf die alte Datenbank zeigen
• -Den Connection String in deiner Deployment-Plattform tauschen – die Integration kann das je Umgebung
• -Logs und Verbindungszahl im Dashboard die ersten Minuten beobachten
• -Follow stoppen und die Quelle abschalten, wenn du zufrieden bist

Sag uns vor einer Produktionsumstellung Bescheid. Wir sehen den Plan durch, sind im Fenster erreichbar und halten einen Wiederherstellungsweg bereit. Es kostet dich nichts und ist der Unterschied zwischen einem langweiligen und einem interessanten Abend.