„Schema-los“ klingt schnell, bis verschiedene Teams beginnen, dasselbe Geschäftskonzept in leicht unterschiedlichen Formen zu speichern. An diesem Punkt ist das Schema nicht verschwunden. Es hat sich einfach in den Anwendungscode, Migrationsskripte und Produktionsunterstützungsfälle verschoben.
Deshalb landen viele Teams schließlich bei Postgres mit JSONB als Kompromiss: relationale Garantien für zentrale Felder, flexibler Dokumentenspeicher für die Teile, die sich tatsächlich häufig ändern.
Warum JSONB als Mittelweg funktioniert
Das nützliche Muster ist nicht „alles in eine JSON-Spalte packen.“ Es besteht darin, stabile Geschäftsfelder von sich entwickelnden Metadaten zu trennen:
CREATE TABLE users (
id UUID PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
plan TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
preferences JSONB NOT NULL DEFAULT '{}'::jsonb
);
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
Das gibt Ihnen:
- normale relationale Einschränkungen für wichtige Felder
- JSON-Abfragen für variable Präferenzen oder Funktionsflags
- eine betriebliche Plattform anstelle von geteilten Speicher-Modellen
Wo Teams normalerweise die reine Dokumentenspeicherung bereuen
Dokumentendatenbanken können weiterhin gut geeignet sein, aber der Schmerz zeigt sich oft, wenn das System wächst:
- die Konsistenz über Dokumente hinweg wird schwieriger
- Berichterstattung benötigt relationale Abfragen
- doppelte Feldformate häufen sich
- Migrationen werden zu ad hoc Datenreparaturarbeiten
Wenn die Anwendung Geldflüsse, Abrechnungsstatus, Identitäten oder wertvolle Verknüpfungen hat, ältert Postgres in der Regel besser.
Der ehrliche Kompromiss
JSONB ist mächtig, aber es ist einfach, es falsch zu benutzen. Wenn jedes bedeutende Feld am Ende innerhalb von JSON begraben ist, verlieren Sie einen großen Teil dessen, warum relationale Speicherung überhaupt hilfreich ist. Verwenden Sie es für selektive Flexibilität, nicht als Entschuldigung, um das Schema-Design zu vermeiden.
MongoDB ist nicht „falsch.“ Der Fehler liegt in der Annahme, dass schemalose Speicherung für immer günstiger ist. Sie ist oft nur zu Beginn günstiger.
Weiterführende Literatur