Zum Hauptinhalt springenZur Navigation springenZur Fußzeile springen
    Daten & Analytics

    Neon (Serverless Postgres)

    Auch bekannt als:
    Neon Postgres
    Serverless Postgres
    Datenbank-Branching
    Aktualisiert: 20.9.2026

    Neon ist eine 2021 gestartete Postgres-Plattform, bei der Rechenknoten und Speicher entkoppelt sind. Dadurch lassen sich Datenbank-Branches in Sekunden erzeugen, Rechenleistung automatisch skalieren und ungenutzte Instanzen auf null herunterfahren.

    Kurz erklärt

    Neon ist eine serverlose PostgreSQL-Plattform, die Rechenleistung und Speicher trennt und Datenbanken wie Code verzweigen lässt. Für Agenten ist das interessant, weil jeder Versuch eine eigene, wegwerfbare Datenbank-Kopie erhalten kann.

    Erklärung

    Der entscheidende Unterschied zu klassischem Postgres-Hosting ist das Branching: Ein Branch ist eine vollständige, sofort nutzbare Kopie des Datenstands, ohne dass Daten physisch dupliziert werden. In agentischer Entwicklung löst das ein konkretes Problem – Agenten probieren Migrationen und Datenänderungen aus, und niemand will das auf der Produktionsdatenbank sehen. Jeder Versuch bekommt seinen Branch, wird geprüft und verworfen oder übernommen. Ergänzend erlaubt die Schnittstelle, Datenbanken programmatisch anzulegen, was Architekturen mit einer Datenbank je Mandant oder je Agentensitzung trägt. Zu beachten ist die Kaltstartzeit: Wer auf null skaliert, zahlt beim ersten Zugriff mit Wartezeit.

    Relevanz für Marketing

    Für Teams, die viel mit Agenten bauen, senkt Branching das Risiko messbar: Änderungen an Datenstrukturen werden auf einer Kopie erprobt, nicht am Kundenbestand. Für Verantwortliche zählt außerdem, dass Kosten mit Nutzung atmen – ungenutzte Testumgebungen verursachen kaum Rechenkosten.

    Beispiel

    Ein Agent soll ein Datenmodell erweitern. Er erhält einen Branch der Produktionsdaten, führt die Migration aus, lässt Tests laufen und legt das Ergebnis samt Branch-Adresse zur Prüfung vor. Erst nach Freigabe läuft die Migration produktiv.

    Häufige Fallstricke

    Branches von Produktionsdaten enthalten echte personenbezogene Daten – ohne Anonymisierung entstehen unkontrollierte Kopien. Und Scale-to-Zero ist kein reiner Vorteil: Bei sporadischem Zugriff macht sich der Kaltstart in der Antwortzeit bemerkbar.

    Entstehung & Geschichte

    Neon startete 2021 mit der Trennung von Rechenleistung und Speicher und machte Branching zum Kernversprechen. Später kamen programmatische Provisionierung und Architekturen mit einer Datenbank je Mandant hinzu; das Unternehmen gehört inzwischen zu Databricks. Der Dienst ist nach SOC 2 und ISO 27001 auditiert und stellt eine Auftragsverarbeitungsvereinbarung bereit.

    Anwendungsfälle im Marketing

    1

    Datenbank-Branch je Agentenversuch für Migrationen und Datenänderungen.

    2

    Vorschau-Umgebungen, die zum Code-Branch passen.

    3

    Eine Datenbank je Mandant, programmatisch angelegt.

    4

    Kurzlebige Auswertungsumgebungen ohne dauerhafte Rechenkosten.

    Häufige Fragen

    Wofür brauche ich Datenbank-Branching konkret?

    Für alles, was am Datenmodell arbeitet, ohne die Produktion zu gefährden: Migrationen, Umbauten, Auswertungen. Besonders bei Agenten ist das wertvoll, weil Fehlversuche normal sind und ein Branch einfach verworfen wird.

    Neon oder Supabase?

    Neon ist auf die Datenbank selbst fokussiert, Supabase liefert zusätzlich Auth, Storage und Funktionen. Wer ein vollständiges Backend braucht, ist mit Supabase schneller; wer nur Postgres mit Branching will, bei Neon.

    Darf ich echte Kundendaten in einen Branch kopieren?

    Nur mit derselben Sorgfalt wie in der Produktion. Sinnvoll ist es, Branches vor der Nutzung zu anonymisieren, Zugriff zu befristen und Branches nach Abschluss automatisch zu löschen.

    Verwandte Services

    Tiefer einsteigen: Measurement & Attribution · Modellvergleich 2026