Claude Code Datenbank: SQL-Abfragen und Migrationen mit KI automatisieren

Datenbankarbeit gehört zu den Aufgaben, bei denen Entwickler am meisten Zeit verlieren — nicht wegen fehlender Kenntnisse, sondern wegen fehlender Übersicht. Ein Schema mit 40 Tabellen, verstreute Migrationen aus drei Jahren, Performance-Probleme die sich nur unter Last zeigen. Man kennt die Grundlagen. Aber der Kontext fehlt.

Claude Code SQL-Unterstützung setzt genau hier an: nicht als SQL-Generator der Textbausteine zusammenkopiert, sondern als Werkzeug das das bestehende Schema liest, die Datenstruktur versteht, und Abfragen im Kontext des echten Projekts schreibt. Dieser Artikel zeigt vier konkrete Anwendungsfälle aus dem Produktivbetrieb — mit echten Beispielen, ohne synthetische Demos.

Warum Datenbankarbeit mit Claude Code anders ist

Das Problem bei Datenbankfragen an ChatGPT oder andere generische KI-Tools: Sie kennen dein Schema nicht. Du musst erst die relevanten Tabellen beschreiben, die Spalten nennen, die Beziehungen erklären — und selbst dann antwortet das Tool mit einer Abfrage die vielleicht syntaktisch korrekt ist, aber nicht zu deinen tatsächlichen Datenstrukturen passt.

Claude Code liest dein Schema direkt. Nicht weil es ein Datenbankwerkzeug ist, sondern weil es dein Filesystem liest — und in jedem Projekt liegen die Schema-Definitionen irgendwo: als Migrations-Dateien, als ORM-Modelle, als schema.sql, als Prisma-Schema. Claude Code findet diese Dateien, liest sie, und versteht die Beziehungen zwischen deinen Tabellen bevor es die erste SQL-Abfrage schreibt.

Das Ergebnis: SQL das zu deinem echten Schema passt — mit den richtigen Spaltennamen, den richtigen JOIN-Bedingungen, den richtigen Indizes. Nicht generisches SQL das du erst anpassen musst.

Beispiel 1: Komplexe JOIN-Abfrage generieren

Ein typischer Fall: Du brauchst eine Auswertung, die Daten aus vier Tabellen zusammenführt — Bestellungen, Kunden, Produkte, und Rabattregeln. Die einzelnen Tabellen kennst du. Aber wie du die JOINs richtig verschachtelst, welche Aggregation du verwendest, und wie du dabei keine Performance-Falle baust — das kostet Zeit.

claude "Schreib mir eine SQL-Abfrage die folgendes berechnet:
Umsatz pro Kunde im letzten Quartal, aufgeteilt nach Produktkategorie,
mit dem angewendeten Rabatt pro Bestellung. Nur Kunden mit mehr als
3 Bestellungen. Sortiert nach Gesamtumsatz absteigend."

Claude Code liest zunächst die relevanten Dateien: Migrations-Dateien, Prisma-Schema oder ORM-Modelle, je nachdem was im Projekt vorhanden ist. Dann schreibt es die Abfrage mit den tatsächlichen Tabellen- und Spaltennamen deines Projekts — nicht mit Platzhaltern wie orders_table, die du erst ersetzen musst.

Das Ergebnis für ein typisches E-Commerce-Schema sieht etwa so aus:

SELECT
  c.id AS customer_id,
  c.email,
  p.category,
  COUNT(o.id) AS order_count,
  SUM(oi.quantity * oi.unit_price) AS gross_revenue,
  SUM(oi.quantity * oi.unit_price * COALESCE(d.discount_rate, 0)) AS total_discount,
  SUM(oi.quantity * oi.unit_price * (1 - COALESCE(d.discount_rate, 0))) AS net_revenue
FROM customers c
JOIN orders o ON o.customer_id = c.id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
LEFT JOIN discounts d ON d.id = o.discount_id
WHERE o.created_at >= DATE_TRUNC('quarter', NOW() - INTERVAL '3 months')
  AND o.created_at < DATE_TRUNC('quarter', NOW())
GROUP BY c.id, c.email, p.category
HAVING COUNT(DISTINCT o.id) > 3
ORDER BY net_revenue DESC;

Was Claude Code dabei leistet, ist nicht nur die SQL-Syntax — es ist das Verständnis von COALESCE für optionale Rabatte, DATE_TRUNC für die Quartalsberechnung, und HAVING statt WHERE für die Aggregatsbedingung. Details, die man bei der manuellen Abfrageerstellung leicht vergisst.

Beispiel 2: Datenbankmigration schreiben

Migrationen sind heikel. Eine falsche Migration in Production kann Stunden Rollback bedeuten. Die typischen Risiken: fehlende NOT NULL-Defaults bei bestehenden Zeilen, fehlende Indizes auf neuen Foreign Keys, oder die falsche Reihenfolge bei abhängigen Tabellen.

claude "Ich muss unsere users-Tabelle um ein subscription_tier-Feld erweitern.
Schreib die Migration: ENUM mit den Werten 'free', 'pro', 'enterprise',
Default 'free', bestehende Nutzer bekommen 'free' zugewiesen.
Außerdem brauchen wir einen Index für Abfragen nach subscription_tier.
Wir nutzen PostgreSQL mit Flyway."

Claude Code liest die vorhandenen Migrations-Dateien, erkennt die Namenskonvention (Flyway: V{version}__{description}.sql), und schreibt eine Migration die zu den bestehenden passt — mit der richtigen Versionsnummer, der richtigen Syntax für PostgreSQL ENUMs, und dem richtigen Vorgehen für einen NOT NULL-Default bei bestehenden Zeilen:

-- V23__add_subscription_tier_to_users.sql

-- 1. ENUM-Typ anlegen
CREATE TYPE subscription_tier_enum AS ENUM ('free', 'pro', 'enterprise');

-- 2. Spalte mit Default anlegen (für bestehende Zeilen)
ALTER TABLE users
  ADD COLUMN subscription_tier subscription_tier_enum NOT NULL DEFAULT 'free';

-- 3. Index für Abfragen nach Tier
CREATE INDEX idx_users_subscription_tier ON users(subscription_tier);

-- Rollback-Kommentar
-- ALTER TABLE users DROP COLUMN subscription_tier;
-- DROP TYPE subscription_tier_enum;

Entscheidend: Claude Code weiß, dass bei PostgreSQL ein NOT NULL-Feld ohne Default bei einer nichtleeren Tabelle fehlschlägt. Es löst das durch DEFAULT 'free' direkt in der ALTER TABLE-Anweisung — ein Detail, das bei manuell geschriebenen Migrationen oft vergessen wird und in Production zu Ausfällen führt.

Beispiel 3: Fehlenden Index identifizieren

Performance-Probleme in Datenbanken haben meistens eine einfache Ursache: fehlende Indizes. Das Problem ist die Diagnose — welche Abfragen laufen, welche Tabellen sie treffen, und welche Indizes fehlen. Ohne Monitoring-Daten ist das mühsam.

Claude Code kann die vorhandenen Schema-Definitionen und typische Abfragemuster analysieren, um fehlende Indizes zu identifizieren — auch ohne explizite Query-Logs:

claude "Analysiere unser Datenbankschema und die Repository-Dateien.
Welche Indizes fehlen wahrscheinlich? Besonders interessieren mich
Abfragen die wir häufig ausführen: Bestellungen nach Kunde, Produkte
nach Kategorie und Status, und User-Sessions nach user_id und expires_at."

Claude Code liest das Schema und die Repository-Dateien (wo typischerweise die häufigsten Datenbankabfragen stehen), und gibt eine priorisierte Liste fehlender Indizes zurück:

-- Fehlende Indizes nach Priorität:

-- 1. KRITISCH: orders.customer_id (häufigste JOIN-Bedingung)
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

-- 2. HOCH: products nach Kategorie + Status (häufige Filterkombination)
CREATE INDEX idx_products_category_status ON products(category, status)
WHERE status = 'active';  -- Partial Index, spart Platz

-- 3. HOCH: sessions.user_id + expires_at (Composite für Auth-Check)
CREATE INDEX idx_sessions_user_expires ON sessions(user_id, expires_at);

-- 4. MITTEL: order_items.order_id (für ORDER JOIN)
CREATE INDEX idx_order_items_order_id ON order_items(order_id);

Besonders wertvoll ist hier der Partial Index auf products — Claude Code erkennt, dass wenn 90% der Abfragen nur aktive Produkte abfragen, ein Partial Index erheblich kleiner und schneller ist als ein vollständiger Index. Das ist keine generische Empfehlung, sondern eine kontextbasierte Analyse des tatsächlichen Nutzungsmusters im Code.

EXPLAIN ANALYZE verstehen lassen

Wenn du bereits Query-Plans hast, kann Claude Code diese direkt lesen und erklären:

claude "Was bedeutet dieser Query-Plan, und wie kann ich die Abfrage schneller machen?

Seq Scan on orders  (cost=0.00..892.43 rows=8234 width=156)
  Filter: ((customer_id = 12345) AND (status = 'completed'))
Planning Time: 0.8 ms
Execution Time: 234.5 ms"

Claude Code erkennt: Sequential Scan auf einer großen Tabelle, kombiniert mit einem Filter auf customer_id — das ist ein klassisches Missing-Index-Muster. Es erklärt was der Plan bedeutet, warum es langsam ist, und schreibt den passenden Index.

Beispiel 4: Schema-Dokumentation erstellen

Neue Teammitglieder brauchen oft Tage, um ein gewachsenes Datenbankschema zu verstehen. Welche Tabellen gehören zusammen? Was bedeuten die Felder? Wo liegen die kritischen Business-Regeln, die sich in der Datenstruktur widerspiegeln?

claude "Erstelle eine Dokumentation unseres Datenbankschemas.
Für jede Tabelle: Zweck, wichtige Felder, Beziehungen zu anderen Tabellen,
und typische Abfragemuster die im Code vorkommen."

Claude Code liest alle Migrations-Dateien und Schema-Definitionen, analysiert die Repository-Dateien auf typische Abfragemuster, und erstellt eine strukturierte Dokumentation — nicht als generische Liste von Spalten, sondern als verständliche Erklärung der Datenarchitektur mit Business-Kontext.

Ein typischer Abschnitt aus einer solchen Dokumentation:

"Die order_items-Tabelle ist die zentrale Verbindungstabelle zwischen Bestellungen und Produkten. Sie enthält neben der Menge und dem Einzelpreis zum Bestellzeitpunkt auch den unit_price separat vom aktuellen Produktpreis — das ist bewusst, damit historische Bestellauswertungen korrekt bleiben auch wenn sich Preise ändern. Typischer Abfragepfad: immer als JOIN auf orders, selten direkt abgefragt."

Diese Art Dokumentation kann ein Entwickler nicht aus dem Schema allein ableiten — sie braucht den Kontext aus den Abfragemuster im Code. Claude Code kombiniert beides.

Claude Code SQL in der Praxis: Was funktioniert, was nicht

Nach mehreren Monaten Claude Code Datenbank-Nutzung im Produktivbetrieb eine ehrliche Einschätzung:

Funktioniert sehr gut:

• Abfragen für gut dokumentierte Schemas (Prisma, TypeORM, SQLAlchemy-Modelle)
• Standard-Migrationen: neue Spalten, neue Tabellen, neue Indizes
• Index-Analyse auf Basis von Abfragemustern im Code
• Schema-Dokumentation und Onboarding-Materialien
• EXPLAIN ANALYZE interpretieren und Optimierungen vorschlagen

Braucht mehr Kontext:

• Sehr komplexe Migrationen mit Datentransformationen (hier lohnt ein explizites Briefing)
• Performance-Optimierungen die von spezifischen Datenbankversionen abhängen
• Schema-Entscheidungen bei unklaren Business-Anforderungen

Der entscheidende Faktor ist immer: wie gut liegt das Schema in lesbarer Form vor? Ein Prisma-Schema oder gut dokumentierte Migrations-Dateien geben Claude Code mehr Kontext als eine implizite Datenbank die nur aus dem ORM-Code erschlossen werden muss.

Wer Claude Code für komplexere Entwicklungsaufgaben einsetzen will, findet hier weiterführende Artikel:

• Claude Code API-Integration — externe APIs anbinden, Authentifizierung, Fehlerbehandlung
• Claude Code Python-Projekte — Claude Code in Python-Workflows und Datenverarbeitung einsetzen