Supabase oder Neon: welche Datenbank zu deiner Vibe-Coding-App passt

TL;DR Supabase und Neon speichern deine App-Daten beide in Postgres. Beide bieten inzwischen Login, Dateispeicher, Backend-Funktionen und Zugriffsregeln pro Datensatz. Entscheidend sind Login, Live-Updates, Leerlaufzeiten, die Zahl deiner Projekte und die Wiederherstellung nach Fehlern. Für eine einzelne kleine App können beide kostenlosen Tarife reichen.

Geprüft am 1. November 2026 anhand der offiziellen Dokumentation und Preisseiten beider Anbieter. Preise in USD.

---

Sobald dein Prototyp echte Nutzer bekommt, braucht er ein Gedächtnis. Aufgaben, Profile, Uploads müssen irgendwo liegen, und nicht jeder darf alles sehen. Dein Coding-Agent schlägt dann oft Supabase vor. Manchmal Neon.

Die Frage „Was ist besser?“ führt hier nicht weit. Beide Anbieter nutzen dieselbe Datenbank: Postgres. Normale Tabellen und SQL-Abfragen lassen sich häufig übernehmen. Der Unterschied liegt in allem, was um die Datenbank herum gebaut ist: Login, Zugriffsregeln, Live-Updates und Abrechnung.

Im Build-with-Vibe-Workshop nutzen wir Supabase als geführten Weg. Diese Entscheidungshilfe stammt aus unserer Kurs-Lernplattform, für alle, die einen anderen Weg gehen wollen.

Was beide gemeinsam haben

Beide bieten diese Grundfunktionen:

• Postgres als Datenbank, mit Tabellen, Beziehungen und SQL.
• Login für deine Nutzer: E-Mail mit Passwort, Login-Link oder Google.
• Row Level Security (RLS): Regeln pro Datensatz, etwa „jeder sieht nur seine eigenen Aufgaben“.
• Dateispeicher für Uploads wie Bilder oder PDFs.
• Backend-Funktionen für geschützten Code, zum Beispiel KI-Aufrufe mit geheimem API-Schlüssel.

Ein Punkt gilt bei beiden gleich: Login regelt noch nicht, wer welche Daten sehen darf. Die Zugriffsregeln richtest du selbst ein. Ohne RLS kann ein eingeloggter Nutzer unter Umständen die Daten aller anderen lesen.

Die Unterschiede im Überblick

Deine Frage	Supabase	Neon
Wie melden sich Nutzer an?	Supabase Auth übernimmt den Login.	Managed Better Auth: Neon betreibt den Login-Dienst. Nutzer und Sitzungen liegen in deiner Postgres-Datenbank.
Wer darf welche Daten sehen?	RLS-Regeln, die du für deine App einrichtest.	Postgres-RLS wird unterstützt. Die Data API verbindet deine App; die Regeln richtest du ebenfalls selbst ein.
Wo läuft mein Backend-Code?	Edge Functions mit Deno, global nah bei deinen Nutzern.	Neon Functions mit Node.js, in derselben Region wie deine Datenbank.
Sehe ich Änderungen sofort?	Realtime für Chat, Live-Listen und „wer ist online“. Zugriffsschutz je nach Verfahren unterschiedlich, siehe unten.	Realtime mit Live-Abfragen ist in Beta. Dieser Zugriff erzwingt keine RLS.
Was ist kostenlos?	2 aktive Free-Projekte, 500 MB Datenbank pro Projekt.	100 Free-Projekte, je 1 GB Datenbank und 100 CU-Stunden pro Monat; insgesamt höchstens 20 GB Postgres-Speicher über alle Free-Projekte.
Was kostet es danach?	Pro ab 25 USD pro Organisation und Monat, inklusive 10 USD Guthaben für Rechenleistung, ungefähr ein Micro-Projekt. Weitere Projekte kosten eigene Rechenleistung.	Launch ohne Grundgebühr: 0,106 USD pro CU-Stunde plus 0,35 USD pro GB-Monat Speicher.
Was passiert, wenn die App ruht?	Free-Projekte können nach einer Woche geringer Aktivität pausieren. Du setzt sie im Dashboard manuell fort.	Die Datenbank schläft standardmäßig nach 5 Minuten ohne Aktivität und wacht beim nächsten Zugriff automatisch auf.

Bei beiden kommen Mehrverbrauch und Zusatzdienste obendrauf. Bei Neon werden Datenbank-Rechenzeit und Postgres-Speicher im Launch-Tarif ab der ersten Nutzung berechnet. Für andere Dienste können weiterhin enthaltene Kontingente gelten. Die detaillierte Planübersicht nennt auch das zusätzliche Gesamtlimit im Free-Tarif.

Login: Supabase Auth oder Better Auth

Bei Supabase greifen Login, Nutzerverwaltung und RLS direkt ineinander. Ein praktischer Haken: Der eingebaute E-Mail-Versand von Supabase erreicht nur vorab autorisierte Adressen deines Teams und ist stark begrenzt. Für Bestätigungs-, Login- und Passwort-E-Mails an echte Nutzer brauchst du einen eigenen Mailversand per SMTP.

Neon setzt auf Better Auth, eine Open-Source-Login-Bibliothek. Neon betreibt sie als verwalteten Dienst. Nutzer und Sitzungen liegen dabei in deiner Postgres-Datenbank. Das tun sie bei Supabase auch; unterschiedlich sind der Login-Dienst und wie er eingebunden wird. Die Einschränkung: Managed Better Auth unterstützt nur einen Teil der Better-Auth-Plugins.

Auch Neon empfiehlt vor dem Produktivstart einen eigenen E-Mail-Anbieter für zuverlässigen Versand. Für Bestätigungslinks statt Bestätigungscodes ist er erforderlich. Das steht in der Produktionscheckliste für Neon Auth.

Willst du alle Plugins und volle Kontrolle, kannst du Better Auth mit beiden Anbietern selbst betreiben. Dann gehören Einrichtung, Updates und Betrieb dir. Für einen ersten Prototyp ist das meistens mehr Arbeit, als es bringt.

Live-Updates: der Zugriffsschutz entscheidet

Baust du einen Team-Chat, ein gemeinsames Board oder eine Liste, die sich bei allen gleichzeitig aktualisiert, ist Realtime der Knackpunkt. Supabase bietet dafür drei Verfahren: Live-Datenbankänderungen (Postgres Changes), Nachrichtenkanäle (Broadcast) und Online-Status (Presence). Bei Postgres Changes greifen deine RLS-Regeln, mit einer Ausnahme: Für Löschereignisse gelten sie nicht. Broadcast und Presence brauchen private Kanäle mit eigenen Zugriffsregeln. Diese Zugriffskontrolle führt Supabase noch als Public Beta.

Neon Realtime ist in Beta. Der wichtigere Haken: Dieser Zugriff erzwingt keine RLS. Dein Backend muss die Anmeldung prüfen und jede Live-Abfrage auf die erlaubten Daten begrenzen, bevor es sie für den Browser freigibt. Ein Filter im Browser reicht nicht.

Bei beiden gilt: Teste Live-Funktionen mit zwei Nutzerkonten. Sieht Konto B etwas von Konto A, ist der Zugriffsschutz nicht fertig.

Kosten: Leerlauf ist der Hebel

Hier unterscheiden sich die Modelle am stärksten.

Supabase rechnet mit festem Grundpreis. Pro kostet ab 25 USD pro Organisation und Monat. Enthalten sind 10 USD Guthaben für Rechenleistung, ungefähr genug für ein Micro-Projekt. Jedes weitere Projekt kostet eigene Rechenleistung, auch ohne Zugriffe. Dafür pausieren Pro-Projekte nicht wegen geringer Aktivität.

Neon rechnet nach Rechenzeit. Die Einheit heißt CU-Stunde: Rechenkapazität mal Laufzeit. Mit aktivem Scale to Zero schläft die Datenbank standardmäßig nach 5 Minuten ohne Zugriff. Erst dann entfällt die Rechenzeit; Speicher und weitere Dienste kosten weiter.

Eine Beispielrechnung mit den Launch-Preisen, angenommen 1 CU Rechenkapazität:

• Selten genutzte App, rund 2 Stunden aktiv pro Tag: etwa 60 CU-Stunden im Monat, also rund 6 USD Rechenzeit. Im Free-Tarif läge das innerhalb der 100 kostenlosen CU-Stunden; im Launch-Tarif wird es voll berechnet.
• Dauerhaft genutzte App, rund um die Uhr aktiv: etwa 730 CU-Stunden im Monat, also rund 77 USD Rechenzeit, plus Speicher.

Die Stunden umfassen die gesamte Laufzeit, einschließlich der Wartezeit vor dem Einschlafen. 1 CU ist eine Annahme zum Rechnen, kein Mindestbedarf und kein Leistungsvergleich mit Supabase Micro.

Die Rechnung zeigt den Mechanismus: Viele kleine Projekte mit langen Pausen sprechen für Neon. Dauerhafte Last macht Neon nicht automatisch günstiger. Die tatsächliche Rechenzeit hängt außerdem davon ab, wie oft deine App aufwacht, denn jede Anfrage startet die 5-Minuten-Uhr neu.

Der erste Zugriff nach dem Schlafen kann etwas länger dauern. Ob das stört, hängt vom Ablauf ab. Teste den ersten Zugriff nach einer Pause, bevor echte Nutzer kommen.

Vergleiche auch die Wiederherstellung nach einem Fehler. Plane bei Supabase Free eigene Datenexporte ein; Pro bietet tägliche Datenbank-Sicherungen für sieben Tage. Neon Free hält bis zu sechs Stunden Änderungshistorie vor, begrenzt auf 1 GB. Prüfe, wie viel Datenverlust für deine App tragbar ist und wie du Dateien separat sicherst. Längere oder häufigere Sicherungen können zusätzliche Kosten auslösen.

Welche Wahl passt zu dir

Nimm Supabase, wenn …

• du einem Kurs, Tutorial oder Template folgst, das Supabase voraussetzt,
• du bereits eine Supabase-App hast,
• deine App Live-Updates für Chat oder Zusammenarbeit braucht.

Nimm Neon, wenn …

• du viele kleine Projekte ausprobieren willst,
• deine Apps selten genutzt werden und automatisch aufwachen sollen,
• du Better Auth als von Neon betriebenen Dienst nutzen willst und dir die unterstützten Plugins reichen.

Dein Coding-Tool entscheidet mit. Prüfe zuerst, welchen Anbieter deine Plattform oder Vorlage direkt unterstützt; die Vibe Coding Tool Map hilft beim Einordnen. Teste dann einen vollständigen Ablauf: anmelden, einen Datensatz speichern und mit einem zweiten Nutzer die Zugriffsregeln prüfen. Fehlt die passende Verbindung, gehört ihre Einrichtung in deinen Vergleich.

Läuft deine App schon auf einem der beiden? Dann lohnt ein Wechsel allein für eine kleinere Rechnung nicht automatisch. Daten, Login und Zugriffsregeln müssen gemeinsam umziehen und neu getestet werden. Und nicht jede Funktion ist in jeder Region verfügbar. Prüfe Datenbank, Login, Dateien und Functions für deine Region gemeinsam.

Lass deinen Coding-Agent die Entscheidung vorbereiten

Die Tabelle oben ist eine Momentaufnahme. Preise und Funktionen ändern sich. Deshalb geben wir unseren Teilnehmern einen Prompt mit, der die Entscheidung für ihre konkrete App vorbereitet. Kopiere ihn in deinen Coding-Agent, zum Beispiel Claude Code oder Codex, mit geöffnetem Projekt. Du hast erst eine Idee? Beschreibe sie in der letzten Zeile.

Hilf mir, zwischen Supabase und Neon für meine App zu wählen.

1. Verstehe zuerst das Projekt.
Lies den verfügbaren Prototyp, Code, README, Produktdokumente und das Datenmodell. Wenn ich erst eine Idee habe, nutze meine Beschreibung unten. Sage, was du geprüft hast und worauf du keinen Zugriff hattest. Trenne bereits funktionierende Funktionen von simulierten Oberflächen und geplanten Erweiterungen.

2. Ermittle, was meine App braucht.
Berücksichtige Nutzer und Rollen; Login-Funktionen, einschließlich Better Auth, falls relevant; wer welche Daten sehen darf (RLS); Uploads; Backend-Funktionen und KI-Aufrufe; Live-Updates; bestehende Tools und Hosting sowie die benötigte Hosting-Region. Berücksichtige außerdem die Anzahl der Projekte, erwartete Nutzung und Leerlaufzeiten, Datenmenge und monatliches Budget. Kläre den E-Mail-Versand, benötigte Sicherungen und wie viel Datenverlust bei einer Wiederherstellung tragbar wäre. Trenne Fakten von Annahmen.

3. Kläre nur entscheidende Lücken.
Wenn im Prototyp oder in den Dokumenten etwas unklar bleibt, das deine Empfehlung ändern könnte, stelle mir eine gezielte Frage in einfacher Sprache, eine nach der anderen. Frage nicht erneut nach bereits verfügbaren Informationen. Warte auf meine Antworten, bevor du die endgültige Empfehlung gibst; halte Unbekanntes sichtbar.

4. Vergleiche die Optionen für diese App.
Erkläre gemeinsame Fähigkeiten und die Unterschiede, die für meinen Bedarf tatsächlich wichtig sind. Prüfe aktuelle Funktionen, regionale Verfügbarkeit, kostenlose Limits einschließlich Gesamtlimits sowie bezahlte Tarife anhand offizieller Anbieter-Dokumentation. Berücksichtige E-Mail-Versand, Sicherung und Wiederherstellung in den Gesamtkosten. Verlinke deine Quellen und nenne das Prüfdatum. Wenn du etwas nicht prüfen kannst, sage es. Schätze die Gesamtkosten mit offengelegten Nutzungsannahmen; nutze Szenarien bei unbekannter Nutzung und erfinde keine genaue Rechnung.

5. Empfiehl einen Anbieter.
Nenne eine klare Wahl, die wichtigsten Gründe und den Nachteil, die voraussichtlichen Kosten unter deinen Annahmen und was deine Empfehlung ändern würde. Wäge bei einer bestehenden App Aufwand und Risiken für den Umzug von Daten, Login und Zugriffsregeln gegen den Nutzen eines Wechsels ab. Ende mit einem konkreten nächsten Schritt. Erkläre dies für jemanden ohne Entwicklerkenntnisse.

Analysiere und empfehle nur; ändere keinen Code, keine Konfiguration und keine Daten.

Meine Idee oder zusätzlicher Kontext: [Hier beschreiben, falls noch nicht im Projekt oder in den Dokumenten enthalten.]

Die vorletzte Zeile ist bewusst gesetzt: Dein Agent soll vergleichen und empfehlen, aber noch nichts an Code, Konfiguration oder Daten ändern.

Quellen

Alle Angaben stammen aus der offiziellen Dokumentation, Stand 1. November 2026. Es handelt sich nicht um gemessene Rechnungen oder Leistungsvergleiche.

• Supabase: Preise · Auth · Row Level Security · Edge Functions · Realtime · Pausieren von Free-Projekten · Abrechnung · Realtime Authorization · Postgres Changes · Eigener SMTP-Versand
• Neon: Preise · Managed Better Auth · Unterstützte Plugins · Data API · Functions · Storage · Realtime · Realtime-Zugriffsprüfung · Scale to Zero
• Better Auth: Postgres-Adapter

---

Welche Plattform zu welchem Teil deines Stacks passt, zeigt die Vibe Coding Tool Map. Wenn du deine eigene App mit Datenbank, Login und Deploy an zwei Tagen bauen willst, findest du Ablauf und Termine im Build-with-Vibe-Workshop.

Die Datenbank ist bei beiden dieselbe. Entscheide nach dem, was drumherum gebaut ist.