Supabase Speed-Check: Datenbank-Performance optimieren

Supabase ist großartig, weil es uns die volle Power von PostgreSQL gibt, ohne dass wir uns um die Server-Administration kümmern müssen. Aber: Auch die beste Datenbank wird langsam, wenn wir sie falsch füttern.

Wenn deine Listenansichten sekundenlang laden oder die Suche träge reagiert, liegt das meist nicht an Supabase selbst, sondern an unoptimierten Abfragen. In diesem Guide schauen wir uns an, wie du mit echtem Datenbank-Know-how das Maximum aus deiner Supabase-Instanz herausholst.

1. Die Macht der Indizes (Indexes)

Stell dir ein Buch ohne Inhaltsverzeichnis vor. Wenn du ein bestimmtes Kapitel suchst, musst du jede Seite einzeln umblättern. Genau das macht PostgreSQL (Sequential Scan), wenn du keinen Index hast.

Wenn du oft nach der E-Mail-Adresse suchst, erstelle einen Index:

CREATE INDEX idx_users_email ON users (email);

Der versteckte Performance-Killer: Viele Entwickler setzen Indizes auf alles, was sie finden. Das ist ein Fehler. Jeder Index muss bei jedem INSERT oder UPDATE mitgeschrieben werden. Das macht Schreibvorgänge langsamer. Setze Indizes also gezielt dort ein, wo du oft filter(), order() oder match() im Supabase-Client nutzt.

Pro-Tipp: Nutze das Supabase Dashboard oder den Befehl EXPLAIN ANALYZE vor deiner SQL-Abfrage. PostgreSQL verrät dir dann exakt, wie lange die Suche gedauert hat und ob ein Index genutzt wurde (Index Scan) oder ob die Datenbank mühsam die ganze Tabelle durchsucht hat (Seq Scan).

2. Weniger ist mehr: Nur benötigte Spalten laden

In vielen Tutorials sieht man den "Select All" Ansatz. Das ist bequem, aber ineffizient – besonders bei wachsenden Datenmengen.

Schlecht (lädt alles, inklusive schwerer JSON-Felder oder langer Texte):

const { data } = await supabase.from('posts').select('*')

Besser (lädt nur was wirklich angezeigt wird):

const { data } = await supabase.from('posts').select('title, slug, created_at')

Das reduziert nicht nur die Last auf der Datenbank, sondern auch die Datenmenge, die über das Internet zum Nutzer geschickt werden muss. Besonders bei mobilen Nutzern mit schlechtem Empfang macht das einen spürbaren Unterschied in der gefühlten Geschwindigkeit der App.

3. RLS (Row Level Security) Performance

Row Level Security ist eines der coolsten Features von Supabase, kann aber zum Flaschenhals werden. Jedes Mal, wenn du Daten abfragst, muss Postgres prüfen: "Darf dieser Nutzer das sehen?".

Wenn deine RLS-Policies komplexe SELECT-Abfragen auf andere Tabellen enthalten, wird jede einzelne Zeile deiner Hauptabfrage gegen diese Policies geprüft.

Optimierung: Nutze security definer Funktionen für komplexe Prüfungen oder stelle sicher, dass die in der Policy genutzten Spalten (meist user_id) einen Index haben.

4. Komplexe Logik in RPC verlagern

Wenn du für eine Aktion fünf verschiedene Tabellen abfragen und die Ergebnisse im Frontend zusammenführen musst, hast du fünf Netzwerk-Anfragen. Jede Anfrage hat eine Latenz (Round-trip time).

Nutze stattdessen eine Database Function (RPC). Du schreibst die Logik einmal in SQL (direkt im SQL-Editor von Supabase) und rufst sie mit einer einzigen Zeile Code auf:

const { data } = await supabase.rpc('get_complex_dashboard_data', { user_id: '123' })

Das ist nicht nur schneller, sondern auch sicherer, da die Logik direkt in der Datenbank gekapselt ist und weniger Daten über die Leitung gehen.

5. Connection Pooling

Wenn du Supabase in einer Serverless-Umgebung (wie Vercel oder AWS Lambda) nutzt, werden bei jedem Request neue Datenbank-Verbindungen aufgebaut. Das kann Postgres schnell in die Knie zwingen.

Lösung: Nutze den Connection Pooler (Transaction Mode), den Supabase standardmäßig anbietet. Achte darauf, in deiner Konfiguration (z.B. bei Prisma oder direkt via Postgres-URL) den richtigen Port (meist 6543) zu nutzen.

Fazit: Postgres-Wissen ist der Schlüssel

Supabase "versteckt" PostgreSQL hinter einer schicken Oberfläche und einer intuitiven JavaScript-Bibliothek, aber am Ende des Tages gelten die Regeln einer klassischen relationalen Datenbank.

Meiner Meinung nach ist der größte Fehler, Postgres wie eine NoSQL-Datenbank (wie MongoDB) zu behandeln. Investiere ein wenig Zeit in das Verständnis von Indizes, Abfrageplänen und relationalem Design. Deine Nutzer werden es dir mit blitzschnellen Ladezeiten und einer stabilen App danken.

Mehr zum Thema Backend & Supabase:

• Supabase vs. Firebase: Der Vergleich 2026
• Einstieg in Supabase Auth mit Next.js
• TypeScript für React-Entwickler