Next.js Datenbank-Auswahl: PostgreSQL, MySQL, MongoDB und Cloud-Dienste im Vergleich

Das Projekt soll in 48 Stunden live gehen. Ich starre auf „Add Database“ in der Vercel-Konsole, der Cursor wandert zwischen Postgres, MySQL und MongoDB. Zehn Browser-Tabs mit Tech-Artikeln: Supabase mit großzügigem Free-Tier, PlanetScale mit Rekord-Performance, MongoDB als perfekte Wahl für Next.js.

Zu viele Optionen. Jede klingt gut, jede hat Grenzen. Und ein falscher Schritt kann später teurer sein als Code neu zu schreiben.

Wenn Sie gerade in derselben Situation stecken, ist dieser Artikel für Sie. Wir sortieren PostgreSQL, MySQL und MongoDB sowie Vercel Postgres, Supabase, PlanetScale und MongoDB Atlas – ohne Marketing-Floskeln.

Am Ende reichen drei Fragen für eine klare Entscheidung.

Grundlagen – die drei Datenbanktypen im Kern

PostgreSQL vs. MySQL vs. MongoDB: mehr als relational vs. NoSQL

Oft heißt es: PostgreSQL und MySQL sind relational, MongoDB ist NoSQL. Stimmt – hilft bei der Auswahl aber wenig.

Besser: an Charakter denken.

PostgreSQL ist das Schweizer Taschenmesser. Relationen, JSON, Volltextsuche, Geodaten, komplexe Stored Procedures – fast alles ist drin. Mehr Funktionen bedeuten aber auch eine steilere Lernkurve.

Bei komplexen Queries mit vielen JOINs liegt PostgreSQL oft ~30 % vor vergleichbaren Systemen – bei falscher Konfiguration kann der Ressourcenverbrauch höher sein als bei MySQL.

MySQL ist der zuverlässige Standard: leicht, ausgereift, riesige Community. Viele Legacy-Projekte laufen darauf, weil es einfach „funktioniert“.

Schwäche: vor allem vertikale Skalierung – irgendwann brauchen Sie stärkere Hardware statt wie bei MongoDB horizontal zu skalieren. Für moderate Last kein Problem; bei sehr hoher Concurrency kann es eng werden.

MongoDB speichert JSON-Dokumente, keine klassischen Tabellen. Felder lassen sich ohne ALTER TABLE ergänzen – ideal bei sich schnell ändernden Anforderungen.

Beispiel CMS: heute „Lesezeit“, morgen „Empfehlungen“. Mit MySQL jedes Mal Schema-Migration; mit MongoDB Felder im Code ergänzen.

Kein Allheilmittel: komplexe Multi-Table-JOINs sind mühsam; Transaktionen gibt es, aber weniger natürlich als bei SQL.

Die Wahl ist nicht „gut vs. schlecht“, sondern passend vs. unpassend.

Wann welche? Drei Praxis-Dimensionen

Dimension 1: Wie komplex sind die Beziehungen?

Kernfrage für die meisten Projekte.

Viele „A gehört zu B gehört zu C“-Logiken (E-Commerce: User → Bestellungen → Produkte → Kategorien → Tags)? PostgreSQL oder MySQL mit JOINs, Foreign Keys und Transaktionen.

Flache oder weitgehend unabhängige Daten? MongoDB oft angenehmer – z. B. Blog: Artikel als Dokument, Kommentare eingebettet oder lose verknüpft.

Dimension 2: Wie oft ändern sich Anforderungen?

Häufige Produkt-Pivots? MongoDB spart Schema-Migrations-Schmerz.

Klassisches Muster: relationales Schema perfekt geplant – zwei Wochen später „User-Tags“, dann Mehrfachauswahl, dann Hierarchie. Jedes Mal Migrationsskripte.

Mit MongoDB Felder im Code; Validierung liegt stärker in der Anwendung. Bei stabilen, regelbasierten Domänen (Finanzen, ERP) sind DB-Constraints dagegen ein Vorteil.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Dimension 3: Was kann das Team?

Kein abstraktes „besser/schlechter“ – Vertrautheit zählt.

SQL-erfahrenes Team + erzwungenes MongoDB: hohe Lern- und Fehlerkosten. JavaScript-lastiges Team + Mongoose kann die Produktivität verdoppeln, weil die API wie Objektmanipulation wirkt.

Braucht das Projekt wirklich SQL, dann lernen. Wenn beide Wege funktionieren: die vertraute Variante wählen.

Cloud-Dienste – Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas

Vergleich: mehr als der Monatspreis

Datenbanktyp steht – als Nächstes der Cloud-Anbieter.

Vercel Postgres: Ein-Klick-Komfort

Läuft die App ohnehin auf Vercel, ist Vercel Postgres oft am schnellsten eingerichtet: wenige Klicks, Env-Vars automatisch, Latenz in Benchmarks oft < 10 ms.

Einschränkung: schlankes Angebot – kein eingebautes Auth, kein Storage, kein Realtime. Nur PostgreSQL? Passt. „Full Backend“? Weitere Dienste dazu.

Free: 256 MB. Paid ab ~20 $/Monat – für tiefe Vercel-Integration oft gerechtfertigt.

Supabase: Open-Source-„Full Stack“

Nicht nur PostgreSQL: Auth, Storage, Realtime, Supabase Studio. Free: 500 MB DB + 1 GB Storage – für MVP und Solo-Projekte oft ausreichend.

Performance: QPS ~5.000 in Benchmarks vs. ~17.000 bei PlanetScale – für viele Apps kaum spürbar. Standard-PostgreSQL erleichtert Migration.

Achtung bei Traffic-Spitzen: Connection Limits. Pooler für Serverless nutzen.

PlanetScale: Performance mit Preis

QPS ~17.000 (mixed) / ~35.000 (read-heavy) – deutlich über Supabase. Database Branching wie Git für Schema-Tests – stark für Teams.

Harte Punkte: keine Foreign Keys (Konsistenz in der App). Seit 2024 kein Free-Tier, ab ~34 $/Monat.

Lohnt sich bei echter High-Concurrency oder Branching-Bedarf; sonst gibt es günstigere Alternativen.

MongoDB Atlas: Flexibilität vs. Lernkurve

Offizieller MongoDB-Cloud-Dienst, Free 512 MB, globale Regionen. Wer MongoDB wählt, landet meist hier.

Von SQL kommend: Aggregation Pipeline braucht Einarbeitung. Transaktionen existieren, fühlen sich aber anders an als in SQL.

Versteckte Kosten: Bandbreite – bei vielen großen Responses kann sie den DB-Preis übersteigen (in der Praxis bis ~60 % der Rechnung). Abhilfe: Region nah an der App, schlanke Queries, Cache.

Kurzüberblick:

Versteckte Kosten jenseits der Monatsgebühr

Die DB-Zeile auf der Rechnung ist nur die Spitze des Eisbergs.

Connection Limits: Serverless-Albtraum

Auf Vercel startet jede Anfrage oft eine neue Funktion – jede mit eigener DB-Verbindung. Hunderte parallele Requests können den Pool sprengen.

Fehler wie „Too many connections“ um 3 Uhr nachts kennt man schnell.

Supabase Pooler, PlanetScale eingebaut, Vercel Postgres optimiert. Bei MongoDB Atlas eigenes Pooling oder Alerts einplanen.

Bandbreite: der stille Kostenfaktor

DB und App in verschiedenen Regionen? Jede Query zahlt Transfer – besonders bei Atlas (nach Volumen).

Maßnahmen:

1. DB und App in derselben Region
2. Nur benötigte Felder laden, kein blindes SELECT *
3. Cache für wiederholte Reads

Skalierung: langfristige Sprünge

Supabase und PlanetScale staffeln nach Speicher und Verbindungen. Supabase Free 500 MB → Pro ~25 $/Monat mit 8 GB; bei 10 GB Nachzahlung. PlanetScale rechnet auch nach Zeilen – bei vielen Writes steigen Kosten schnell.

Migration: die unterschätzte Rechnung

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Migration ≠ Daten kopieren: Schema, Code, Tests. Klein: Tage; groß: Monate.

Beispiel: MongoDB → PostgreSQL wegen komplexer Queries – neues relationales Schema, Wochen an Skripten, getrennte Staging/Prod-Rollouts, ~2 Monate Aufwand.

Deshalb: im Zweifel mainstream + ORM (Prisma, Drizzle) für einen austauschbaren Datenzugriff.

Entscheidungsrahmen – drei Fragen

Frage 1: Welcher Projekttyp?

Persönliches Projekt / MVP

Budget knapp, viele Features? → Supabase

500 MB + 1 GB + Auth + Realtime – viele Solo-SaaS laufen lange im Free-Tier.

NoSQL-Vertrautheit oder sehr flexibles Schema? → MongoDB Atlas (512 MB Free) – CMS, Blogs, Logs.

Startup / kleines Team

Bereits auf Vercel, Zeit ist knapp? → Vercel Postgres

256 MB Free, aber Env-Injection und Edge-Integration sparen Setup-Zeit.

Auth + Storage out of the box? → Supabase als Backend-Bündel.

Unternehmen / hohe Last

Strenge Performance? → PlanetScale (~17k QPS, Branching). Ohne Foreign Keys in der DB prüfen, ob die App Konsistenz trägt.

Content / Blog / Medien

Flexible Inhalte, einfache Queries? → MongoDB Atlas

Realtime-Kommentare? → Supabase Realtime (CDC auf PostgreSQL, ohne eigenes WebSocket-Boilerplate).

Frage 2: Budget und Größe?

Zero Budget

Supabase (500 MB + 1 GB) oder MongoDB Atlas (512 MB). Vercel Postgres nur 256 MB Free; PlanetScale ohne Free.

Mit Auth/Upload: Supabase. Reine Datenspeicherung: Atlas oft flexibler.

Klein (< 50 $/Monat)

Supabase Pro (~25 $/Monat, 8 GB DB, 100 GB Storage, Auth für viele MAU) oder Vercel Postgres (~20 $+). Auf Vercel kann die Integration die Mehrkosten wert sein.

Atlas pay-as-you-go oft wenige Dollar – Bandbreite im Blick behalten.

Mittel (50–200 $/Monat)

PlanetScale (~34 $+) oder Supabase Team (~50 $/Monat effektiv). Bei moderater QPS oft Supabase; bei echter High-Concurrency PlanetScale.

Groß / Enterprise

Viele wechseln zu AWS RDS, Cloud Cloud SQL oder eigenem PostgreSQL-Cluster. Ohne DBA bleiben Managed-Anbieter sinnvoll – Ops auslagern, Produkt bauen.

Frage 3: Technische Schulden?

Migration später OK

Free-Tier, schnell validieren, später upgraden oder wechseln – gängiger Weg (Atlas → PostgreSQL → Self-Hosted).

Vorbereitung:

1. ORM (Prisma, Drizzle)
2. Datenzugriff zentral, nicht verstreut
3. Regelmäßige Backups

Einmal sauber, wenig Umweg

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

PostgreSQL + Supabase oder PostgreSQL self-hosted. Ökosystem und klare Exit-Pfade (z. B. AWS RDS, gleiche SQL).

MongoDB → relational ist meist ein Refactoring.

Persönliche Default-Stack

Next.js + Prisma + Supabase:

• Free-Tier reicht lange
• Prisma-Typen und Migrationen
• PostgreSQL-Ökosystem = Anbieterwechsel möglich
• Auth/Storage inklusive

Bei sehr hoher Last oder starkem DB-Ops-Team: PlanetScale oder Self-Hosted.

Praxis: Setup-Checklisten

Schnellstart

Kurz die wichtigsten Stolpersteine – ohne lange Code-Dumps.

Option 1: Vercel Postgres + Prisma

~5 Minuten:

1. Vercel → Storage → Create Database → Postgres
2. Env in .env, z. B. process.env.POSTGRES_PRISMA_URL
3. npx prisma generate
4. Prisma Connection Pooling für Serverless

Hinweise:

• Dev und Prod trennen
• Migrations in Git committen

Option 2: Supabase + Prisma

Voller Stack inkl. Auth:

1. Projekt anlegen, Connection String holen
2. DATABASE_URL + DIRECT_URL (für Migrations)
3. Pooler aktivieren
4. Auth: @supabase/auth-helpers-nextjs

Hinweise:

• Row Level Security (RLS) konfigurieren
• Realtime pro Tabelle aktivieren

Option 3: MongoDB Atlas + Mongoose

Für JS-lastige Teams:

1. Cluster, Connection String (<password> ersetzen)
2. Mongoose-Schemas trotz schemaless DB
3. serverSelectionTimeoutMS gegen Cold-Start-Timeouts
4. .lean() für schnellere Reads

Hinweise:

• Credentials nie ins Git – .env.local + .gitignore
• Indizes manuell anlegen
• Aggregation Pipeline vorab in der Doku sichten

Allgemein

1. .env.local vs. Produktions-Env trennen
2. Connection Pooling in Serverless
3. DB-Fehler mit try/catch, nicht roh an Nutzer
4. Backups
5. Monitoring: Verbindungen, Query-Dauer

Fazit

Es gibt keine Universal-Datenbank – aber einen klaren Rahmen.

Drei Fragen:

1. Projekttyp – privat, Startup, Enterprise?
2. Budget – 0, < 50 $, mittel/groß?
3. Schulden – Migration später OK oder lieber mainstream von Anfang an?

Im Zweifel: Supabase + Prisma + PostgreSQL – großzügiges Free-Tier, DB + Auth + Storage, reifes Ökosystem, Prisma-Typsicherheit.

Spezialfälle: Peak-Performance → PlanetScale; flexibles Schema → MongoDB Atlas; maximale Vercel-Integration → Vercel Postgres.

Datenbankwahl ist ein Prozess, kein einmaliger Klick. Erst shippen, dann optimieren. Nicht Wochen mit der Auswahl verlieren.

Jetzt die drei Fragen beantworten, in 10 Minuten entscheiden – und coden.

Fragen? In die Kommentare.