Ihre Produktionsdatenbank erreicht 100K Records und Ihre Abfragezeiten beginnen zu steigen. Sie aktualisieren das Dashboard — 2,4 Sekunden für eine gefilterte Liste, die früher in 300ms geladen wurde. Ihr Kunde fragt, warum sein Admin-Panel langsamer wirkt. Sie wissen, dass es Zeit ist zu evaluieren, ob Supabase, Firebase, PlanetScale, Neon oder Turso diese Skalierung wirklich bewältigen können. Die meisten Vergleichsartikel erstellen eine Todo-App und nennen es Recherche. Wir führen seit über einem Jahr 253.000+ Records auf fünf Live-Client-Seiten auf Supabase PostgreSQL aus. Wir haben Firebase Firestore, PlanetScale, Neon und Turso in echten Projekten mit echten Traffic-Mustern getestet. Hier ist, was bei der Skalierung wirklich bricht — und was nicht.

Wenn Sie eine Webanwendung erstellen, die 100K+ Records mit komplexen Abfragen, Echtzeit-Funktionen und Authentifizierung verarbeiten muss, definiert Ihre Datenbankwahl Ihre Architektur für Jahre. Wenn Sie die falsche wählen, schreiben Sie Ihren Data Layer in sechs Monaten neu oder zahlen das Dreifache. Ich möchte Sie vor beidem bewahren.

Inhaltsverzeichnis

Beste Datenbank für 100K+ Record-Websites: Supabase vs Firebase vs PlanetScale getestet

Warum dieser Vergleich existiert

Bei Social Animal erstellen wir Headless-Webanwendungen — hauptsächlich mit Next.js und Astro — für Clients, die dynamische, datenlastige Seiten benötigen. Denken Sie an Unternehmensverzeichnisse mit 50K+ Einträgen, Programmatic-SEO-Seiten, die Tausende von Seiten generieren, und SaaS-Dashboards, die Echtzeit-Updates benötigen.

Wenn ein Client mit einem Projekt zu uns kommt, das 100K+ Records betrifft, findet das Datenbankgespräch am ersten Tag statt. Es ist keine nachträgliche Überlegung. Ihre Datenbankwahl beeinflusst Ihre Auth-Strategie, Ihr API-Design, Ihre Hosting-Kosten und Ihre Fähigkeit, Features in sechs Monaten bereitzustellen.

Ich werde nicht so tun, als würde ich identische Produktions-Workloads auf allen fünf Datenbanken ausführen. Das wäre unehrlich. Was ich getan habe, ist ernsthafte Produktion auf Supabase ausführen (253K+ Records, fünf Seiten, 14 Monate) und gründliche technische Bewertungen der Alternativen für spezifische Client-Projekte durchführen. Ich werde klar sein, welche Daten aus der Produktion kommen und welche aus der Bewertung.

Die Kandidaten auf einen Blick

Vor wir tiefer gehen, hier das schnelle Bild:

  • Supabase — PostgreSQL mit allem (Auth, Speicher, Echtzeit, Edge Functions)
  • Firebase Firestore — Googles NoSQL-Dokumentendatenbank mit ausgezeichneten Mobile-SDKs
  • PlanetScale — Serverless MySQL mit Datenbankzweigen (betrieben von Vitess)
  • Neon — Serverless PostgreSQL mit Verzweigung und Scale-to-Zero
  • Turso — Verteiltes SQLite am Edge (betrieben von libSQL)

Jede ist wirklich gut in etwas. Die Frage ist, ob dieses Etwas dem entspricht, was Sie erstellen.

Supabase PostgreSQL: Unser Produktions-Arbeitspferd

Ich beginne mit Supabase, weil wir die tiefste Erfahrung damit haben. Auf fünf Produktionsseiten hat unsere größte Tabelle 137K Zeilen (ein nationales Adresssystem für ein Verzeichnisprojekt), und wir haben 253K+ Gesamtrecords über alle Datenbanken hinweg.

Was wir täglich verwenden

Row Level Security (RLS) ist wahrscheinlich die Funktion, die den Ausschlag gab. Wenn Sie Multi-Tenant-Anwendungen erstellen — was die meisten Headless-CMS-Seiten schließlich werden — benötigen Sie pro-Benutzer-Datenisolation. Mit RLS lebt die Sicherheitslogik in der Datenbank selbst. Ihre API-Schicht muss nicht auf jeder einzelnen Abfrage merken, nach user_id zu filtern. Die Datenbank erzwingt es.

Hier ist, wie eine typische RLS-Richtlinie in unseren Projekten aussieht:

-- Benutzer können nur die Einträge ihrer eigenen Organisation sehen
CREATE POLICY "org_isolation" ON listings
  FOR SELECT
  USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));

-- Admins können alles sehen
CREATE POLICY "admin_access" ON listings
  FOR ALL
  USING (EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  ));

Das ist echtes SQL. Es ist keine proprietäre DSL. Wenn Sie jemals Supabase verlassen müssen, übersetzen sich diese Richtlinien zu jedem PostgreSQL-Host.

pgvector war eine Offenbarung für semantische Suche. Wir implementierten es auf einer inhaltsreichen Website, wo traditionelle Volltextsuche nicht ausreichend war. Benutzer würden nach "Orte zum Essen in der Innenstadt" suchen und erwarten Ergebnisse, die Restaurants, Cafés und Food Trucks umfassen — auch wenn diese genauen Wörter nicht im Eintrag stehen.

-- Vector-Spalte erstellen
ALTER TABLE listings ADD COLUMN embedding vector(1536);

-- Index erstellen (das ist sehr wichtig bei 100K+ Records)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- Semantische Suchabfrage
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;

Bei 137K Records mit 1536-Dimensions-Vektoren gibt diese Abfrage in ~45ms auf dem Pro-Plan von Supabase zurück. Das ist schnell genug für Echtzeit-Suche.

PostGIS Geo-Abfragen unterstützen unsere standortbasierten Funktionen. Einträge in einem Radius finden, nach Entfernung sortieren, Fahrtzeiten berechnen — alles auf Datenbankebene statt im Anwendungscode.

-- Einträge innerhalb von 10km eines Punkts finden, nach Entfernung sortiert
SELECT id, name,
  ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
  location,
  ST_MakePoint(-73.9857, 40.7484)::geography,
  10000
)
ORDER BY distance_m
LIMIT 50;

Realtime-Abos lassen uns Live-Dashboards ohne WebSocket-Infrastruktur erstellen. Ein Client-Admin-Panel zeigt neue Einreichungen sofort, weil wir INSERT-Events auf der relevanten Tabelle abonnieren. Null zusätzliche Infrastruktur.

Was nicht perfekt ist

Ich werde nicht so tun, als wäre Supabase fehlerlos. Das Dashboard kann träge sein, wenn Sie Tabellen mit 100K+ Zeilen durchsuchen. Der Tabellen-Editor ist in Ordnung für kleine Datensätze, aber schmerzhaft für Bulk-Operationen — Sie möchten direkt SQL verwenden. Ihre Edge Functions basieren auf Deno, was bedeutet, dass einige Node.js-Pakete nicht funktionieren. Und wenn Sie Connection Pooling für serverless-Umgebungen benötigen, müssen Sie die Supavisor-Verbindungszeichenfolge verwenden (sie haben PgBouncer ab Anfang 2025 abgelöst).

Auch hat ihr kostenloses Tier eine harte Grenze von 500MB Datenbankplatz. Für Produktion mit 100K+ Records benötigen Sie mindestens den Pro-Plan ($25/Monat).

Beste Datenbank für 100K+ Record-Websites: Supabase vs Firebase vs PlanetScale getestet - Architektur

Firebase Firestore: Wo es gewinnt und wo nicht

Wir evaluierten Firebase ernsthaft für zwei Client-Projekte 2024. Einer war eine mobile-first Anwendung mit Offline-Sync-Anforderungen. Der andere war eine Verzeichnisseite mit komplexem Filtern.

Wo Firebase wirklich gewinnt

Firebases Echtzeit-Sync für mobile Anwendungen ist immer noch best-in-class. Die Offline-Persistierung, automatische Konfliktauflösung und enge Integration mit iOS/Android-SDKs machen es zur offensichtlichen Wahl, wenn Ihre Hauptplattform mobil ist. Google Auth-Integration ist einfach — ein paar Codezeilen und Sie haben Sign-in with Google, Apple, Telefonnummer und E-Mail/Passwort.

Firebase Crashlytics, Remote Config und Analytics bilden ein Mobile-Development-Ökosystem, das nichts anderes erreicht. Wenn Sie eine Mobile App an erster Stelle und eine Web-App an zweiter Stelle erstellen, verdient Firebase ernsthafte Überlegung.

Warum wir stattdessen Supabase wählten

Firestore ist eine Dokumentendatenbank. Keine Joins. Lassen Sie das für einen Moment sinken.

Wenn Sie ein Verzeichnis mit Einträgen erstellen, die Kategorien, Tags, Orte, Bewertungen und Benutzerprofile haben, benötigen Sie relationale Daten. In Firestore denormalisieren Sie entweder alles (duplizieren Daten über Dokumente und hoffen, es in Sync zu halten) oder machen mehrere Round-Trip-Abfragen und joinen die Daten im Anwendungscode.

Hier ist, wie eine "Einträge nach Kategorie mit durchschnittlicher Bewertung finden"-Abfrage in jedem aussieht:

-- Supabase: eine Abfrage, fertig
SELECT l.*, c.name AS category_name,
  AVG(r.rating) AS avg_rating,
  COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;

// Firestore: drei Abfragen + Client-seitiger Join
const categorySnap = await db.collection('categories')
  .where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;

const listingsSnap = await db.collection('listings')
  .where('categoryId', '==', categoryId).get();

// Jetzt Bewertungen für jeden Eintrag abrufen...
// Dann Durchschnitte im Anwendungscode berechnen...
// Dann sortieren... Sie kennen das.

Und hier ist der echte Knaller: Firestore berechnet pro Dokumentenlesen. Dieses Triple-Query-Muster oben? Jedes Dokument in jeder Abfrage zählt. Bei 100K+ Records mit moderatem Traffic wird Ihre Rechnung wirklich unvorhersehbar. Wir haben Horror-Geschichten von Entwicklern gehört, die $400+ Überraschungsrechnungen hatten, weil sie nicht realisierten, dass ihre Abfragen mehr Dokumente scannen als erwartet.

Firestore hat auch kein Äquivalent zu pgvector oder PostGIS. Sie können grundlegende Geohash-Abfragen durchführen, aber diese sind ungefähr und begrenzt im Vergleich zu echter räumlicher Indizierung.

PlanetScale: Großartige Datenbank, unvollständige Plattform

PlanetScale führt Vitess aus — die gleiche Technologie, die YouTubes Datenbank antreibt. Für reine MySQL-Performance ist es ausgezeichnet. Ihr Database-Branching-Feature (erstellen Sie einen Branch, machen Sie Schema-Änderungen, mergen Sie zurück) ist wirklich innovativ und etwas, das ich mir nativ bei Supabase wünschen würde.

Was PlanetScale gut macht

Ihr Serverless-Treiber ist schnell. Connection-Management wird für Sie gehandhabt, was in Serverless-Umgebungen enorm wichtig ist, wo jeder Function-Aufruf sonst möglicherweise eine neue Datenbankverbindung öffnen könnte. Schema-Verzweigung macht Datenbankmigrationen wie Git Pull Requests anfühlen — sicher, überprüfbar, reversibel.

Für Teams mit starker MySQL-Expertise, die traditionelle Webanwendungen bauen, ist PlanetScale solide.

Was fehlt

PlanetScale ist nur eine Datenbank. Das war's. Vergleichen Sie, was Sie benötigen, um einen vollständigen Application-Stack zu bauen:

Feature Supabase PlanetScale + Extras
Datenbank ✅ Inklusive ✅ Inklusive
Auth ✅ Inklusive ❌ Benötigt Clerk ($25+/Mo) oder Auth0
Dateispeicher ✅ Inklusive ❌ Benötigt S3 oder Cloudflare R2
Echtzeit ✅ Inklusive ❌ Benötigt Pusher oder Ably
Vektorsuche ✅ pgvector ❌ Nicht verfügbar
Geo-Abfragen ✅ PostGIS ❌ Grundlegendes MySQL-Spatial
Edge Functions ✅ Inklusive ❌ Benötigt separate Bereitstellung

Bis Sie Clerk für Auth, S3 für Speicher, Pusher für Echtzeit und eine separate Vektordatenbank für Suche hinzugefügt haben, verwalten Sie fünf Services statt einer. Ihre Rechnung ist höher, Ihre Komplexität ist höher, und Ihre Debug-Oberfläche ist enorm.

PlanetScale hat auch ihren kostenlosen Tier (Hobby-Plan) im April 2024 eingestellt, sodass der Einstiegspunkt jetzt $39/Monat für ihren Scaler-Plan ist. Das ist teurer als Supabase Pro und gibt Ihnen weniger Funktionalität.

Neon: Die Wahl des Puristen

Neon ist die Datenbank, die ich wählen würde, wenn ich nur PostgreSQL und nichts anderes bräuchte. Ihre Serverless-Architektur ist wirklich beeindruckend — Scale-to-Zero bedeutet, Sie zahlen nichts, wenn Ihre Datenbank nicht abgefragt wird. Ihr Branching-Feature ist ausgezeichnet für Preview-Bereitstellungen (spinnen Sie einen Datenbank-Branch für jeden PR).

Neon unterstützt pgvector und PostGIS, weil es Standard-PostgreSQL ist. Sie erhalten also Vektorsuche und Geo-Abfragen. Die rohen Datenbankfähigkeiten sind fast identisch mit Supabase.

Warum wir Supabase immer noch wählten

Neon ist eine Datenbank. Supabase ist eine Plattform. Mit Neon müssen Sie hinzufügen:

  1. Auth — Clerk, Auth0 oder bauen Sie selbst
  2. Speicher — S3, Cloudflare R2 oder ähnlich
  3. Echtzeit — Pusher, Ably oder ein benutzerdefinierter WebSocket-Server
  4. Edge Functions — Stellen Sie separat auf Cloudflare Workers oder Vercel bereit

Für einige Teams ist dieser modulare Ansatz tatsächlich vorzuziehen. Wenn Sie bereits Meinungen zu Auth haben (und das Budget für Clerk), S3 für alles nutzen und keine Echtzeit benötigen, bedeutet Neons fokussierter Ansatz weniger Vendor Lock-in.

Aber für unsere Headless-Entwicklungsprojekte ist es viel wert, Auth, Speicher und Echtzeit in einem Dashboard mit einer Rechnung und einem Set API-Schlüssel zu haben. Developer-Geschwindigkeit ist wichtig, wenn Sie Client-Projekte unter straffen Zeitplänen ausliefern.

Neons Preisgestaltung ist auch wettbewerbsfähig: ihr kostenloses Tier includes 0,5GB Speicher und 190 Compute-Stunden/Monat. Der Launch-Plan bei $19/Monat gibt Ihnen 10GB. Für reine Datenbankarbeit ist es das beste Preis-Leistungs-Verhältnis in Serverless PostgreSQL.

Turso: Edge-First SQLite

Turso ist faszinierende Technologie. Sie haben SQLite — die am meisten bereitgestellte Datenbank der Welt — genommen und verteilt gemacht. Ihre Daten leben am Edge, nah bei Ihren Benutzern, was bedeutet, dass Read-Latenz unglaublich niedrig sein kann (unter 10ms global).

Wo Turso glänzt

Read-lastige Workloads mit globalem Publikum. Wenn Sie Inhalte, die sich nicht häufig ändern, an Benutzer weltweit bereitstellen, gibt Tursos Edge-Replikation Ihnen Datenbank-Reads, die sich sofort anfühlen. Ihr Embedded-Replicas-Feature lässt Sie einen SQLite-Replica direkt in Ihre Anwendung bündeln.

Für statische Seiten mit Astro, die eine leichte Data Layer benötigen, ist Turso überzeugend.

Warum es unsere Anforderungen nicht erfüllte

Unsere 100K+ Record-Workloads beinhalten signifikante Schreibvorgänge — Benutzer-Einreichungen, Admin-Updates, Review-Erstellung, Echtzeit-Datenänderungen. SQLites Write-Modell (Single-Writer) wird zum Engpass bei Skalierung. Turso handhabt das besser als rohes SQLite durch ihren libSQL-Fork, aber es ist immer noch nicht für Write-intensive 100K+ Record-Anwendungen konzipiert.

Keine Vektorsuche. Kein PostGIS-Äquivalent. Limitiertes Ökosystem im Vergleich zu PostgreSQL oder MySQL. Für unsere Verzeichnis- und SaaS-Projekte waren dies Dealbreaker.

Direkter Funktionsvergleich

Hier ist der vollständige Vergleichstisch basierend auf unserer Produktionserfahrung und Bewertungen ab Mitte 2026:

Feature Supabase Firebase PlanetScale Neon Turso
Datenbanktyp PostgreSQL NoSQL (Firestore) MySQL (Vitess) PostgreSQL SQLite (libSQL)
Eingebaute Auth ✅ Ja ✅ Ja ❌ Nein ❌ Nein ❌ Nein
Vektorsuche ✅ pgvector ❌ Nein ❌ Nein ✅ pgvector ❌ Nein
Geo-Abfragen ✅ PostGIS ⚠️ Begrenzt (Geohash) ⚠️ Grundlegendes MySQL-Spatial ✅ PostGIS ❌ Nein
Echtzeit ✅ Ja ✅ Ja ❌ Nein ❌ Nein ❌ Nein
Dateispeicher ✅ Ja ✅ Ja ❌ Nein ❌ Nein ❌ Nein
Edge Functions ✅ Deno-basiert ✅ Cloud Functions ❌ Nein ❌ Nein ❌ Nein
Joins / Beziehungen ✅ Volles SQL ❌ Keine Joins ✅ Volles SQL ✅ Volles SQL ✅ SQL (begrenzt)
Verzweigung ⚠️ Via Migrationen ❌ Nein ✅ Nativ ✅ Nativ ❌ Nein
Scale-to-Zero ❌ Nein ✅ Ja ✅ Ja ✅ Ja ✅ Ja
Preis-Vorhersehbarkeit 🟢 Hoch (flache Tiers) 🔴 Niedrig (pro Lesen) 🟡 Mittel 🟢 Hoch 🟢 Hoch
Open Source ✅ Ja ❌ Nein ❌ Nein (Vitess ist) ✅ Ja ✅ Ja
Selbst-Hostbar ✅ Ja ❌ Nein ❌ Nein ❌ Nein ✅ Ja

Performance-Benchmarks bei 100K+ Records

Diese Zahlen stammen von unserer Produktions-Supabase-Instanz (Pro-Plan, us-east-1-Region) mit 137K Zeilen in der Primärtabelle. Für die anderen Datenbanken verwende ich veröffentlichte Benchmarks und unsere Evaluierungstests mit 100K synthetischen Records.

Abfragetyp Supabase Firebase PlanetScale Neon Turso
Einfaches SELECT nach ID 3ms 8ms 4ms 5ms 1ms
Gefilterte Abfrage (indiziert) 12ms 15ms 10ms 14ms 3ms
Komplexer JOIN (3 Tabellen) 35ms N/V (keine Joins) 28ms 38ms 25ms
Vektorähnlichkeit (Top 20) 45ms N/V N/V 42ms N/V
Geo-Radius (10km) 22ms ~50ms (Geohash) N/V 24ms N/V
Volltextsuche 18ms N/V (Algolia nutzen) 15ms 20ms 12ms
Bulk INSERT (1000 Zeilen) 180ms 250ms 150ms 195ms 320ms
Kalter Start (Serverless) N/V (immer an) ~100ms ~50ms ~300ms ~20ms

Ein paar Dinge stechen hervor. Tursos Read-Performance ist außergewöhnlich — das ist der SQLite-am-Edge-Vorteil. PlanetScales MySQL-Engine verarbeitet Joins etwas schneller als PostgreSQL in unseren Tests. Neons Kalter Start ist merklich (300ms), weil es die Compute aufwecken muss, obwohl nachfolgende Abfragen schnell sind. Firebases Mangel an Joins bedeutet, dass Sie buchstäblich einige dieser Abfragen nicht ausführen können.

Supabases always-on Compute (kein Scale-to-Zero auf Pro) bedeutet null Kaltstarts, was für benutzer-seitige Anwendungen wichtig ist, wo diese erste Anfrage nicht langsam sein kann.

Preisaufschlüsselung für 100K-Record-Workloads

Lassen Sie uns ein realistisches 100K-Record-Anwendungsmodell erstellen: eine Verzeichnisseite mit 100K Einträgen, 50K monatlich aktiven Benutzern, ~2M Datenbank-Reads/Monat, ~50K Writes/Monat, 5GB Datenbankgröße, 10GB Dateispeicher.

Supabase Pro Firebase (Blaze) PlanetScale Scaler Neon Launch Turso Scaler
Grundkosten $25/Mo $0 (Pay-as-you-go) $39/Mo $19/Mo $29/Mo
Datenbank Inklusive (8GB) ~$18 (Reads + Writes) Inklusive (10GB) Inklusive (10GB) Inklusive (9GB)
Auth Inklusive (50K MAU) Inklusive +$25/Mo (Clerk) +$25/Mo (Clerk) +$25/Mo (Clerk)
Speicher (10GB) Inklusive ~$3/Mo +$2/Mo (R2) +$2/Mo (R2) +$2/Mo (R2)
Echtzeit Inklusive Inklusive +$25/Mo (Pusher) +$25/Mo (Pusher) +$25/Mo (Pusher)
Geschätzter Gesamtbetrag $25/Mo ~$21/Mo ~$91/Mo ~$71/Mo ~$81/Mo

Firebase sieht billig aus, bis Sie zwei Dinge realisieren. Erstens nimmt diese $21-Schätzung vorhersehbare Read-Muster an. Ein viraler Moment oder ein Bot, der Ihre Seite crawlt, kann Reads dramatisch erhöhen — und Ihre Rechnung mit ihnen. Zweitens benötigen Sie, sobald Sie Features wie Vektorsuche benötigen, Pinecone oder Weaviate zu addieren, was bei $70/Monat beginnt.

Supabases flache $25/Monat für alles — Datenbank, Auth, Speicher, Echtzeit, Edge Functions — ist bemerkenswert guter Wert für diese Workload-Größe. Der Pro-Plan includes 8GB Datenbank, 250GB Bandbreite, 100GB Speicher und 50K monatlich aktive Benutzer für Auth.

Welche Datenbank sollten Sie wählen?

Hier ist meine ehrliche Empfehlung basierend auf der Arbeit mit diesen Tools:

Wählen Sie Supabase, wenn Sie eine Webanwendung mit relationalen Daten erstellen, Auth + Speicher + Echtzeit in einer Plattform benötigen, PostgreSQLs Ökosystem mögen (pgvector, PostGIS, Volltextsuche) oder Sie mit Next.js bauen. Dies deckt wahrscheinlich 80% der Projekte ab, die wir sehen.

Wählen Sie Firebase, wenn Sie eine mobile-first Anwendung erstellen, wo Offline-Sync wichtig ist, Ihr Team das Firebase-Ökosystem bereits kennt oder Ihre Daten wirklich dokumentgeformt sind (Chat-Nachrichten, Activity Feeds, einfache Benutzerprofile).

Wählen Sie PlanetScale, wenn Sie ein starkes MySQL-Team haben, Datenbankzweigungen für komplexes Schema-Management benötigen und Sie bereits separate Services für Auth und Speicher nutzen. Es ist eine großartige Datenbank — nur nicht eine komplette Plattform.

Wählen Sie Neon, wenn Sie PostgreSQL ohne Platform-Overhead mögen, lieber Ihren eigenen Stack aus best-of-breed Services zusammenstellen oder Scale-to-Zero für Kostenoptimierung bei Low-Traffic-Projekten benötigen.

Wählen Sie Turso, wenn Sie eine Read-lastige, global verteilte Anwendung erstellen, wo Edge-Latenz mehr wichtig ist als Write-Durchsatz, oder Sie mit Astro an inhaltsorientierten Seiten arbeiten.

Für unsere Arbeit bei Social Animal, Headless-Webanwendungen erstellend, ist Supabase das Richtige gewesen. Die All-in-One-Plattform bedeutet schnellere Entwicklung, einfachere Architektur und vorhersehbare Kosten. Wir haben es auf 253K+ Records skaliert, ohne zu straucheln. Wenn Sie ein Projekt in dieser Skalierung planen und über Architektur sprechen möchten, erreichen Sie uns — wir haben das ein paar mal getan.

FAQ

Ist Supabase gut für großskalige Anwendungen?

Ja, und wir haben Produktionsevidenz, um das zu sichern. Wir führen 253K+ Records auf fünf Produktionsseiten auf Supabase Pro aus. Die Abfrage-Performance bleibt konsistent — unsere komplexesten Joins mit Vektorähnlichkeitssuche geben in unter 50ms bei 137K Zeilen zurück. Supabase läuft auf Standard-PostgreSQL, das Anwendungen um Größenordnungen größer antreibt als alles, das die meisten von uns bauen werden. Die Platform-Schicht (Auth, Speicher, Echtzeit) ist das neuere Teil, aber sie ist für uns seit Anfang 2024 stabil.

Wie vergleicht sich Supabase-Preisgestaltung mit Firebase bei Skalierung?

Supabase ist dramatisch vorhersehbarer. Ihr Pro-Plan kostet flat $25/Monat, das Auth für 50K MAUs, 8GB Datenbankspeicher, 250GB Bandbreite und 100GB Dateispeicher includes. Firebase berechnet pro Dokumentenlesen, Schreiben und Löschen — was Kosten sehr variabel macht. Eine 100K-Record-Anwendung mit 2M monatlichen Reads könnte zwischen $15 und $200+ auf Firebase kosten, abhängig von Abfragemustern. Wir haben Firebase-Rechnungen gesehen, die sich über Nacht verdreifachten, wenn eine Seite in sozialen Medien geteilt wird.

Kann PlanetScale 100K+ Records verarbeiten?

Absolut. PlanetScale läuft Vitess, das YouTube-skalige Workloads antreibt. Für reine Datenbankperformance mit 100K Records ist PlanetScale ausgezeichnet. Die Limitation ist nicht Skalierung — es ist Vollständigkeit. Sie müssen separate Services für Auth, Dateispeicher, Echtzeit-Updates und Vektorsuche hinzufügen. Das addiert sowohl Kosten ($90+/Monat insgesamt) als auch architektonische Komplexität im Vergleich zu Supabase's All-in-One-Ansatz.

Was ist pgvector und warum ist es wichtig?

pgvector ist eine PostgreSQL-Erweiterung, die Vektor-Embeddings direkt in Ihrer Datenbank speichert und abfragt. Das ermöglicht semantische Suche — Benutzer können nach Bedeutung statt nach genauen Stichwörtern suchen. Für ein Verzeichnis mit 100K+ Einträgen bedeutet das, eine Suche nach "kinderfreundliche Brunch-Spots" kann Ergebnisse zurückgeben, die als "Family Restaurant" oder "Weekend Breakfast" getaggt sind, auch wenn diese Wörter nicht übereinstimmen. Ohne pgvector benötigen Sie eine separate Vektordatenbank wie Pinecone ($70+/Monat) und müssen zwei Datenbanken in Sync halten.

Ist Firebase Firestore gut für Verzeichniswebseiten?

Ehrlich gesagt, nein. Verzeichniswebseiten sind von Natur aus relational. Einträge gehören zu Kategorien, haben Tags, empfangen Bewertungen von Benutzern und benötigen komplexes Filtern ("zeige mir Restaurants innerhalb von 5 Meilen mit 4+ Sternen, die jetzt offen sind"). Firestore kann keine Joins durchführen, hat begrenzte Abfrage-Operatoren und berechnet pro Dokumentenlesen — was komplexe gefilterte Abfragen teuer macht. Wir evaluierten Firestore für ein Verzeichnisprojekt und schätzten 4x die Entwicklungszeit im Vergleich zu Supabase aufgrund von Datendähenormalisierung und Client-seitigen Query-Workarounds.

Sollte ich Neon oder Supabase für meine Next.js-App verwenden?

Wenn Sie nur eine Datenbank benötigen, bietet Neon besseren Wert (kostenloses Tier ist großzügig, und der $19/Monat Launch-Plan ist solide). Wenn Sie Auth, Speicher, Echtzeit oder Edge Functions benötigen — was die meisten Produktions-Next.js-Apps tun — spart Supabase Sie vor der Integration und Bezahlung für mehrere separate Services. Wir verwenden Supabase für unsere Next.js-Entwicklungsprojekte, weil die integrierte Auth und der Speicher Wochen von typischen Projekt-Timelines sparen.

Was ist die beste Datenbank für Programmatic-SEO-Seiten?

Supabase PostgreSQL. Programmatic-SEO-Seiten generieren Tausende von Seiten aus strukturierten Daten, was bedeutet, dass Sie schnelle Abfragen, gutes Indexing und die Fähigkeit, komplexe Datenbeziehungen zu handhaben, benötigen. Wir haben Programmatic-SEO-Seiten auf Supabase gebaut, die 10K+ Seiten aus einer einzelnen Datenbank generieren — PostGIS für Ortsseiten, pgvector für verwandte Inhalte und Volltextsuche für dynamische Filterung. Die flache Preisgestaltung bedeutet, dass Traffic-Spitzen von Google-Indexierung Ihre Rechnung nicht explodieren lässt.

Ist Turso (libSQL) bereit für Produktions-Web-Apps?

Für Read-lastige Anwendungen, ja. Tursos Edge-repliziertes SQLite gibt Ihnen sub-5ms Reads global, das ist unglaublich für inhaltsgerichtete Seiten. Aber für Write-intensive Anwendungen mit 100K+ Records — wie Verzeichnisse, wo Benutzer Daten einreichen, Admin-Panels Updates verarbeiten und Bewertungen konstant kommen — wird SQLites Single-Writer-Modell zum Engpass. Wir würden Turso für Inhaltsseiten mit Astro und Supabase oder Neon für dynamische Anwendungen mit signifikanten Write-Workloads empfehlen.