Datenbankoptimierung: 7 Fehler, die Ihre SaaS verlangsamen

Eine häufige Diagnose bei langsamen SaaS-Applikationen: Der Frontend ist schnell, die APIs auch — aber insgesamt fühlt sich das System träge an. Die Wurzel liegt oft in der Datenbankschicht. Suboptimale Queries, fehlende Indizes und falsche Datenbankdesign-Entscheidungen können eine App um Größenordnungen verlangsamen.

Fehler 1: Fehlende oder falsche Indizes

Das Klassiker-Problem: Ein SELECT-Query ohne WHERE-Clause, der über 10 Millionen Rows läuft. Die Datenbank muss jeden einzelnen Row durchsuchen — eine Full Table Scan.

Typische Szenarien:

• Häufig gefilterte Spalten ohne Index (z. B. user_id, created_at)
• Zusammengesetzte WHERE-Clauses ohne passende zusammengesetzte Indizes
• Indizes auf Spalten mit niedriger Selektivität (viele wiederholte Werte)

Die Lösung: Nutzen Sie Query-Analyzer-Tools (EXPLAIN ANALYZE in PostgreSQL, EXPLAIN FORMAT=JSON in MySQL) um zu sehen, welche Queries Indizes brauchen. Faustregel: Jede WHERE-, JOIN- und ORDER BY-Spalte sollte überlegt sein.

Beispiel Bad Query: SELECT * FROM orders WHERE status = 'completed' AND created_at > '2024-01-01';

Beispiel Good Query: CREATE INDEX idx_orders_status_date ON orders(status, created_at DESC);

Fehler 2: N+1 Query Problem

Klassisches ORM-Anti-Pattern: Pro Hauptrecord wird ein zusätzlicher Query für Related Data ausgeführt.

BAD Pattern: 1 Query für Orders + 100 Queries für User Details = 101 Total. GOOD Pattern: 1 Query mit JOIN oder 1 Query Orders + 1 Query Users mit IN-Clause.

Bei 1000 Orders + BAD-Pattern = 1001 Queries. Mit GUT-Pattern = 2 Queries. Der Unterschied ist nicht subtil.

Lösung: Eager Loading nutzen (include/join in den meisten ORMs), oder explizite Daten-Batching mit IN-Clauses.

Fehler 3: SELECT * statt select(['column1', 'column2'])

Viele Entwickler machen es sich einfach: SELECT * — alle Spalten!

Problem: Wenn eine Tabelle 50 Spalten hat und Sie brauchen nur 3, senden Sie 47 Spalten über das Netzwerk, die niemand braucht. Bei Millionen von Rows ein messbarer Overhead.

BAD: SELECT * FROM users WHERE active = true; GOOD: SELECT id, email, name FROM users WHERE active = true;

Fehler 4: Ineffiziente JOINs und unzureichende Datenbank-Normalisierung

Manche Schemas sind so denormalisiert, dass Joins unmöglich effizient sind. Andere haben unzählige JOINS auf tangentiale Tabellen.

Faustregel: Ein Query sollte nicht mehr als 3–5 JOINs haben. Alles darüber ist ein Design-Problem. Beispiel Anti-Pattern: Zu viele JOINs auf orders, order_items, products, categories, brands, users, addresses, countries. Das wird schnell absurd.

Lösung: Denormalisierung in Grenzen einführen oder mit Caching arbeiten (siehe unten).

Fehler 5: Keine Pagination bei großen Resultsets

BAD: SELECT * FROM transactions WHERE user_id = 123; — lädt 100.000 Rows in Memory. GOOD: SELECT * FROM transactions WHERE user_id = 123 ORDER BY created_at DESC LIMIT 50 OFFSET 0;

Frontends und APIs sollten immer mit Pagination arbeiten. Wer 100.000 Rows auf einmal lädt, ist selbst schuld.

Fehler 6: Fehlender Query Caching

Viele Datenbanken führen identische Queries immer wieder aus, obwohl sich die Ergebnisse nicht ändern. Ein Query-Cache-Layer kann das massiv beschleunigen.

Moderne Infrastruktur nutzt oft:

• Redis: In-Memory Cache für häufige Queries
• Materialized Views: Vorberechnete Aggregationen in der DB
• Query Result Caching: Datenbankebene-Caching (PostgreSQL, MySQL unterstützen das)

Fehler 7: Zu häufige Aggregationen ohne Caching

Queries wie COUNT(*), SUM(), GROUP BY über Millionen von Rows sind teuer und ändern sich oft langsam.

Statt: SELECT status, COUNT(*) FROM orders GROUP BY status; (wird jedes Mal full-table-scanned)

Besser: SELECT status, count FROM order_status_summary; (mit Materialized View, einmal pro Stunde aktualisiert)

Oder nutzen Sie Event-Sourcing: Jedes Mal wenn ein Order seinen Status ändert, inkrementieren Sie einfach Counters — statt jedes Mal alles zu zählen.

Praktischer Audit-Prozess

1. Langsame Queries identifizieren

   • Aktivieren Sie Slow Query Logging (z. B. >1s)
   • Nutzen Sie APM-Tools (New Relic, DataDog)

2. Query-Plan analysieren

   • EXPLAIN ANALYZE in PostgreSQL / MySQL
   • Suchen Sie nach Sequential Scans / Full Table Scans

3. Indizes hinzufügen

   • Basierend auf WHERE- und JOIN-Klauseln

4. N+1 eliminieren

   • Suchen Sie nach Loop-Patterns in Code
   • Nutzen Sie Eager Loading

5. Caching einführen

   • Redis für häufig gelesene, selten schreibende Daten
   • Query Result Caching auf DB-Ebene

Schnelle Wins für bestehende SaaS-Apps

• Morgen: EXPLAIN ANALYZE auf den Top 10 langsamen Queries starten
• Diese Woche: Fehlende Indizes hinzufügen
• Nächste Woche: N+1 Queries im Code fixen
• Diesen Monat: Redis-Caching für häufige Abfragen einführen

Mit diesen Optimierungen sehen viele Apps 10–100x schnellere Query-Performance — ohne eine Zeile Businesslogik zu ändern.

Fazit

Datenbankoptimierung ist nicht sexy, aber die ROI ist enorm. Eine langsame SaaS-App kostet Customers, Conversions und Reputation. Eine optimierte App fühlt sich nicht nur schneller an — sie ist es. Und jede Millisekunde zählt.