CockroachDB: verteiltes Postgres-kompatibles SQL für Multi-Region-Setups

Was ist CockroachDB?

CockroachDB ist eine verteilte relationale Datenbank, entwickelt seit 2015 von Cockroach Labs (mit Sitz in New York). Ehemalige Google-Ingenieure bauten das System inspiriert von Google Spanner, dem internen Datenbank-System für globale Konsistenz. CockroachDB nutzt das PostgreSQL-Wire-Protokoll, sodass bestehende Postgres-Clients und ORMs (Prisma, TypeORM, SQLAlchemy, Django ORM) ohne Änderungen funktionieren. Im Mai 2026 ist Version 24 stabil.

Der entscheidende Unterschied zu klassischem Postgres: CockroachDB ist von Grund auf als verteilte Datenbank konzipiert. Daten werden in Ranges aufgeteilt, jede Range ist auf 3-5 Knoten repliziert (default 3), Konsensus läuft über Raft. Schreib- und Leseoperationen sind ACID-konform über mehrere Knoten hinweg. Automatischer Failover bei Knotenausfall, automatisches Rebalancing bei Hinzufügen/Entfernen von Knoten.

Lizenz-Geschichte: CockroachDB war historisch unter Apache 2.0 (Community Edition) und Enterprise (proprietär). Im August 2024 wechselte Cockroach Labs auf eine neue Lizenz-Strategie: Self-Host für Unternehmen mit > USD 10 Mio. Umsatz erfordert Lizenz, kleinere Unternehmen und Hobby-Nutzer bleiben kostenfrei. Ab 2026 wird angekündigt, dass Self-Host nach 3 Jahren auf Apache 2.0 konvertiert -- d.h. Version 24 wird im August 2027 vollständig OSS. Das schafft Vertrauen für KMU, die Bedenken zu Lizenz-Lock-in haben.

Cockroach Cloud (cockroachlabs.cloud) bietet drei Tarif-Stufen: Serverless (ab USD 0, scale-to-zero), Dedicated (USD 400+ pro Monat für dedizierte Cluster), Advanced (Enterprise). EU-Regionen (Frankfurt, Dublin) verfügbar. Self-Host läuft als Container oder Kubernetes-Operator -- benötigt mindestens 3 Knoten für den Default-Replikations-Faktor.

Warum es wichtig ist

CockroachDB ist im KMU-Markt 2026 selten die richtige Wahl -- aber wenn die richtige, dann sehr richtig. Drei Indikatoren.

Erstens: echte Multi-Region-Anforderung. Ein Schweizer Konzern mit Standorten in CH, DE und USA, der konsistente Datenbank-Zugriffe an allen Standorten unter 100 ms Latenz braucht. Postgres-Streaming-Replication ist asynchron (Daten-Lag von Sekunden bis Minuten), CockroachDB synchron mit Raft-Konsensus. Wer wirklich Daten-Konsistenz über Kontinente braucht, hat zwei realistische Optionen: CockroachDB oder Google Spanner.

Zweitens: Hochverfügbarkeit als Architektur-Pflicht. Eine Anwendung mit SLA "kein Datenverlust auch bei Datacenter-Ausfall" gehört nicht auf ein Single-Postgres-Setup. CockroachDB mit 3 Knoten über 3 Availability-Zones hält Daten konsistent auch bei kompletten Zone-Ausfällen. Auto-Failover in Sekunden statt Minuten.

Drittens: Postgres-Kompatibilität als Migrationspfad. Wer mit Postgres startet und in 2-3 Jahren auf verteilte Last umsteigen muss, kann mit minimalen Anwendungs-Änderungen auf Cockroach wechseln. Wire-Protokoll und SQL-Syntax sind weitgehend kompatibel; einige Postgres-spezifische Features (z.B. einige PL/pgSQL-Konstrukte, sequence-Verhalten) müssen angepasst werden, aber das Schema ist portierbar.

Für typische CH-KMU-Treuhand-Setups ist Cockroach 2026 Overkill. Ein einzelnes Büro mit 200 Mandanten und einem Server in Falkenstein bekommt keinen Mehrwert aus verteilter Konsensus-Schicht -- nur zusätzliche Komplexität. Wer Cockroach in Erwägung zieht, sollte zuerst prüfen, ob Postgres mit gutem Backup und ggf. einem Hot-Standby nicht ausreicht.

Wichtig: die 2024er Lizenz-Änderung war ein Vertrauens-Schock für manche OSS-Anwender. Die 2026er-Ankündigung der 3-Jahres-Apache-Konversion hat einiges davon zurückgewonnen -- ist aber noch nicht in jedem Release-Cycle eingespielt. Wer Lizenz-Klarheit über alles stellt, wartet das erste Apache-2.0-Release im 2027 ab.

Wie es funktioniert

CockroachDB läuft als symmetrisches Cluster -- jeder Knoten ist gleichwertig, kein Primary, kein Slave. Daten werden in Ranges aufgeteilt (64 MB pro Range default), jede Range wird auf 3-5 Knoten via Raft repliziert. Ein Raft-Leader pro Range koordiniert Schreib-Operationen, Lese-Operationen können von jedem Replikat bedient werden (mit follower-reads für Lese-Skalierung).

Ein Drei-Knoten-Cluster ist das Minimum: bei einem Knoten-Ausfall bleibt das Cluster verfügbar (2 von 3 Knoten verfügbar = Raft-Mehrheit). Production-Setups laufen typisch mit 3-9 Knoten über mehrere Availability-Zones oder Regionen. Cross-Region-Latency bei Schreib-Operationen liegt im Bereich der RTT zwischen Knoten -- typisch 30-100 ms bei intra-EU-Setups.

Ein minimal-produktiver Setup mit Docker:

# Drei Knoten starten (Beispiel für Hetzner-Cluster) docker run -d --name=cockroach-1 -p 26257:26257 -p 8080:8080 \ -v cockroach-data-1:/cockroach/cockroach-data \ cockroachdb/cockroach:v24.2.0 start \ --advertise-addr=cockroach-1 --join=cockroach-1,cockroach-2,cockroach-3 \ --insecure

# Schema im Postgres-kompatiblen SQL CREATE DATABASE treuhand; CREATE TABLE treuhand.mandanten ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name STRING NOT NULL, region STRING NOT NULL, created_at TIMESTAMPTZ DEFAULT now() );

Multi-Region-Tabellen: ALTER TABLE mandanten SET LOCALITY REGIONAL BY ROW AS region. Damit werden Datenreihen in der Region gespeichert, in der die zugehörigen Anwender sind -- DSGVO-konform mit Daten in EU-Region, Latenz für EU-Kunden niedrig.

Clients: alle Postgres-Treiber funktionieren (pg, node-postgres, psycopg, JDBC). ORMs wie Prisma, Drizzle, TypeORM unterstützen CockroachDB explizit oder via Postgres-Dialect. Spezifische Cockroach-Features (Multi-Region, Time-Travel-Queries via AS OF SYSTEM TIME) braucht man explizit.

Backup: BACKUP-Command schreibt in S3-kompatiblen Speicher oder GCS. PITR via Incremental-Backups plus Time-Travel-Queries. In Cockroach Cloud automatisch konfiguriert; im Self-Host muss man Backup-Schedules selbst aufsetzen.

Monitoring: eingebauter Web-UI über Port 8080 mit Cluster-Health, Range-Verteilung, Query-Performance. Prometheus-Endpoint /metrics für Grafana-Integration. Slow-Query-Log und Statement-Diagnostics built-in.

CockroachDB in 5 Schritten produktiv

1. 01Entscheidung Cloud vs. Self-Host: bei Single-Stack < USD 10 Mio. Umsatz und ohne Cluster-Erfahrung -> Cockroach Cloud Serverless. Bei wirklich verteilten Self-Host-Anforderungen -> 3-Knoten-Cluster über 3 Availability-Zones.
2. 02Cluster initialisieren: drei Knoten mit gemeinsamem --join Parameter starten, cockroach init ausführen. Bei Multi-Region: Locality-Tags pro Knoten setzen.
3. 03Schema designen mit Postgres-Wire-Protokoll-Kompatibilität: UUID Primary Keys, TIMESTAMPTZ für Zeiten, REGIONAL BY ROW für Multi-Region-Tabellen.
4. 04Anwendungs-Anbindung: Prisma/Drizzle mit Postgres-Connection-String, retry-Logik für Conflict-Errors (Cockroach gibt SERIALIZATION_FAILURE bei Transaktions-Konflikten -- App muss Retry können).
5. 05Backup und Monitoring: BACKUP-Schedule in S3 (täglich Full + stündlich Incremental), Prometheus-Scraper, Grafana-Dashboard mit Latency, QPS, Raft-Health.

Wann CockroachDB einsetzen

Die richtige Wahl, wenn (a) echte Multi-Region-Konsistenz benötigt wird, (b) Hochverfügbarkeit mit RTO unter 30 Sekunden zwingend ist, oder (c) horizontale Skalierung jenseits Postgres-Vertikal-Limits nötig ist.

Konkrete Szenarien: ein internationaler Konzern mit Standorten in CH, DE, USA und SEA, der konsistente Buchhaltungs-Daten an allen Standorten unter 100 ms Latenz braucht. Eine Banking- oder Versicherungs-Software mit SLA "Zero Data Loss" auch bei Datacenter-Ausfall. Eine SaaS-Plattform, die schnell über Lizenzgrenzen von Postgres-Vertikal-Skalierung hinauswächst (z.B. > 50k QPS schreibend).

Cockroach Cloud Serverless ist attraktiv für Prototypen mit globaler Ausrichtung: scale-to-zero, pay-per-use, EU-Regionen verfügbar. Wer schnell einen Multi-Region-Stack braucht ohne Cluster-Operations-Wissen, beginnt dort.

Hybride Setups: Postgres-Hauptdatenbank für Single-Region-Workload, CockroachDB für global-konsistenten Sub-Set (z.B. User-Profile, Session-Daten über Regionen). Das ist eine vernünftige Architektur für Anwendungen, die nur partiell global sind.

Wann NICHT

Für Single-Region-CH-KMU-Anwendungen ist CockroachDB Overkill. Ein Büro in Zürich mit 200 Mandanten und einem Server in Falkenstein bekommt keinen Mehrwert aus verteilter Konsensus-Schicht -- nur zusätzliche Komplexität, Latenz und Lizenz-Themen.

Für Postgres-spezifische Features ohne Multi-Region-Bedarf: einige Postgres-Funktionen sind in Cockroach nicht oder anders verfügbar (z.B. komplexe PL/pgSQL-Procedures, einige Extensions wie PostGIS in vollem Umfang). Wer diese Features explizit nutzt, bleibt bei Postgres.

Für reine OLAP-Workloads ist Cockroach nicht das richtige Werkzeug -- ClickHouse oder DuckDB sind schneller für Aggregate über Millionen Zeilen. Cockroach ist auf OLTP optimiert.

Für Setups mit < USD 10 Mio. Umsatz und 1-2 Servern in einer Region: Self-Host kostenfrei bis Schwellwert, aber operativ aufwendiger als Postgres. Postgres mit Standby-Replikation reicht in 95 Prozent der KMU-Fälle und ist deutlich einfacher.

Für Teams ohne Cluster-Operations-Erfahrung: CockroachDB Cluster zu betreiben braucht Erfahrung mit verteilten Systemen -- Knoten-Outages diagnostizieren, Rebalancing nach Knoten-Hinzufügen, Backup-Restore in Multi-Region-Szenarien. Wer 1-2 IT-Personen hat ohne diese Erfahrung, geht zu Cockroach Cloud oder bleibt bei Postgres.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. CockroachDB v24 release notes · 2026-05
2. CockroachDB Licensing FAQ 2024-2026 · 2026-04
3. CockroachDB Multi-Region documentation · 2026-05
4. CockroachDB pricing and Cloud regions · 2026-05