Doltgres: Versionskontrolle für PostgreSQL auf Dolt-Basis

Doltgres als Postgres-Dialekt der Dolt-Engine

Doltgres stammt von denselben Entwicklern wie Dolt, das im README als erste versionierte SQL-Datenbank der Welt vorgestellt wird. Die Kernidee bleibt gleich: Git versioniert Dateien, Doltgres versioniert Tabellen. Wer eine Doltgres-Instanz betreibt, kann Branches anlegen, sie zusammenführen, Repositories forken und klonen sowie Push und Pull gegen entfernte Ablagen ausführen. Der Zugriff läuft über das übliche Postgres-Protokoll, sodass Standardclients wie psql ohne Anpassung funktionieren.

Technisch nutzt Doltgres laut README dieselbe SQL-Engine und dasselbe Speicherformat wie Dolt. Postgres-SQL wird in einen abstrakten Syntaxbaum geparst, um einen Postgres-Server zu emulieren. Versionsoperationen erscheinen nicht als separates Werkzeug, sondern als Systemtabellen, Funktionen und Prozeduren im SQL-Raum: select * from dolt.status zeigt offene Änderungen, dolt.log listet Commits mit Hash, Autor und Zeitstempel.

Das Repository dolthub/doltgresql ist in Go geschrieben, steht unter Apache-2.0 und zeigt nach Metadaten vom 29. August 2026 rund 2.105 Sterne, 71 Forks und 112 offene Issues. Die letzte Version 1.3.0 erschien am 28. August 2026, davor 1.2.0 am 18. August und 1.1.0 am 12. August 2026, was auf einen sehr kurzen Release-Takt hindeutet.

Beta-Erklärung und die 24-Stunden-Zusage der Maintainer

Das README stuft Doltgres seit dem Blogbeitrag vom 16. April 2025 als Beta ein und behauptet zugleich, die Datenbank sei bereit für Produktionsfälle. Diese Kombination klingt widersprüchlich, wird aber durch eine konkrete Zusage gestützt: Wer einen Fehler auf GitHub meldet, könne laut Maintainer-Blog vom 15. Mai 2024 damit rechnen, dass die meisten Fehler innerhalb von 24 Stunden behoben werden. Solche Zusagen gelten nur, solange das Team von DoltHub Ressourcen in das Projekt steckt, und das README sagt nichts über eineExit-Strategie aus.

Die Community-Rollen sind klar verteilt: Issues für Fehler, Issues für fehlende Funktionen und Codebeiträge über den Contribution Guide. Wer das Projekt unterstützen will, wird im README gebeten, einen Stern zu setzen oder Kollegen darauf aufmerksam zu machen. Genau die 112 offenen Issues zeigen, wo die Grenzen der Beta liegen; wer eine bestimmte Funktion braucht, kann dort prüfen, ob sie bereits gemeldet ist.

In der Dokumentation nicht angegeben ist, wie lange die Beta-Phase noch dauern soll oder welche Kriterien den Sprung zur stabilen Version markieren. Der knappe Release-Rhythmus mit drei Major-Versionen im August 2026 spricht dafür, dass sich Schemafunktionen und Kompatibilität derzeit schnell bewegen, was für Produktionsplanungen eine feste Versionspinning nahelegt.

Installation über install.sh, MSI-Paket und Docker-Image

Unter Linux und macOS installiert man Doltgres mit einer Zeile: sudo bash -c 'curl -L https://github.com/dolthub/doltgresql/releases/latest/download/install.sh | bash'. Das Skript lädt das aktuelle Release herunter und legt die Binärdatei in /usr/local/bin/ ab, das normalerweise im PATH liegt. Windows-Nutzer greifen zur MSI-Datei aus der Release-Liste. Für Tests in Containern veröffentlicht das Projekt bei jedem Release ein offizielles Docker-Image dolthub/doltgresql, gestartet etwa mit docker run -e DOLTGRES_PASSWORD=myPassword -p 5432:5432 dolthub/doltgresql:latest.

Wer aus dem Quellcode bauen will, ruft ./scripts/build.sh auf. Beim ersten Start erzeugt doltgres im aktuellen Verzeichnis einen Superuser postgres und eine Datenbank postgres, das Standardpasswort lautet password wie bei einer Postgres-Neuinstallation. Das Datenverzeichnis lässt sich über eine config.yaml oder die Umgebungsvariable DOLTGRES_DATA_DIR verlagern; Name und Passwort des Superusers setzen DOLTGRES_USER und DOLTGRES_PASSWORD vor dem ersten Start.

Als Client genügt psql, das mit einer normalen Postgres-Installation kommt. Der Verbindungsbefehl aus dem README lautet PGPASSWORD=password psql -h localhost -U postgres. Für den Einstieg reicht also ein Docker-Daemon und ein vorhandener psql-Binary, ein separates Administrationswerkzeug gibt es nicht.

Von create table bis dolt.log: eine Beispiel-Sitzung

Der Schnellstart im README führt durch eine vollständige Sitzung. Nach dem Start von doltgres verbindet man sich mit psql und legt eine Datenbank getting_started an. Dort entstehen drei Tabellen mit Primär- und Fremdschlüsseln: employees, teams und employees_teams. Ein Blick auf die Systemtabelle dolt.status zeigt alle drei als neue, noch nicht gestagte Tabellen.

Mit select dolt_add('teams', 'employees', 'employees_teams') werden die Tabellen in die Staging-Area übernommen; ein anschließender Commit schreibt den Zustand fest. select * from dolt.log liefert danach Commit-Hashes wie peqq98e2dl5gscvfvic71e7j6ne34533 mit Committer, E-Mail, Datum und Nachricht, etwa Created initial schema. Das Muster entspricht exakt dem Git-Ablauf von add und commit, nur eben in SQL formuliert.

Für weitere Versionierungsoperationen verweist das README auf die Dolt-Dokumentation, weil beide Datenbanken dieselbe Engine teilen. Praktisch bedeutet das: Schritte, die in der Doltgres-Doku fehlen, lassen sich oft über die Dolt-Dokumentation erschließen, sofern die Operation über SQL erreichbar ist und nicht die fehlende Kommandozeile betrifft.

Einschränkungen: keine CLI, kein DoltHub-Push, keine Erweiterungen

Das README zählt die Abweichungen von Dolt und Postgres explizit auf. Erstens fehlt eine Git-artige Kommandozeile für Versionskontrolle, wie sie Dolt bietet; Branching und Merging laufen ausschließlich über SQL. Zweitens ist ein Push zu DoltHub oder DoltLab nicht möglich, erlaubt sind nur eigene Remotes wie ein Dateisystempfad oder S3. Drittens sind Backup und Replikation laut README noch in Arbeit.

Weiterhin gibt es keine GSSAPI-Unterstützung und keine Unterstützung für Postgres-Erweiterungen. Einige Postgres-Syntax, Typen, Funktionen und Features sind noch nicht implementiert. Für Unternehmen mit etablierten Postgres-Erweiterungen ist das oft der härteste Blocker, weil dieselben Abfragen und Typen in Doltgres noch nicht laufen.

Diese Liste macht den Unterschied zwischen Demo und Betrieb sichtbar: Ohne Replikation trägt ein einzelner Doltgres-Prozess die Verfügbarkeit allein, und ohne DoltHub-Push muss jede Kollaborationsinfrastruktur selbst aufgebaut werden. Wer nur lokale Versionierung von Schema und Daten braucht, um Migrationen zu testen oder Fehlerstände wiederherzustellen, trifft dagegen auf ein Produkt, das genau dafür gebaut ist.

Benchmark- und sqllogictest-Zahlen des README im Einzelnen

Der Autor des README belegt die Performance mit einer Sysbench-Suite, dieselbe, mit der Dolt gegen MySQL gemessen wird, wo Dolt laut Doku nur 1,1-mal langsamer ist. Für Doltgres version 0.50.0 zeigt die Tabelle Median-Latenzen gegen PostgreSQL: Lesetests mit einem Mittelwert von 6,3, Schreibtests mit 3,6 und ein Gesamtmittel von 5,2. Doltgres braucht für dieselben Operationen also im Median mehrfach so lang wie Postgres, bei Lesezugriffen deutlich stärker als bei Schreibzugriffen.

Die Korrektheit wird über die sqllogictest-Suite gemessen. Von 5.691.305 Tests bestanden 5.188.604, 411.415 schlugen fehl, 16 endeten in einem Timeout und 91.270 liefen gar nicht erst. Der gemeldete Korrektheitswert liegt bei 91,16721 Prozent. Diese Zahl präzisiert, was Beta hier heißt: rund jede elfte Prüfung schlägt noch fehl.

Zum Vergleich nennt das README, dass Dolt dieselbe Suite zu 100 Prozent gegen MySQL besteht, und erklärt die Architektur: Doltgres parst Postgres-SQL in einen AST und emuliert einen Postgres-Server auf der Dolt-Engine. Wer Doltgres einsetzt, sollte die eigenen Abfragen daher an der Version 1.3.0 nachstellen und die offene Issue-Liste gegen die eingesetzten Postgres-Features abgleichen, statt die 91 Prozent als allgemeine Latenzgarantie zu lesen.

Redaktionelles Fazit

Doltgres passt für Teams, die Schema- und Datenstände von PostgreSQL-ähnlichen Datenbanken versionieren wollen und mit einer Beta rechnen, deren README 91 Prozent bestandene sqllogictest-Tests und klare Lückenlisten ausweist. Wer Postgres-Erweiterungen, GSSAPI oder Pushes zu DoltHub braucht, sollte erst prüfen, ob dolt.status, dolt_add und dolt.log die eigenen Workflows abdecken, und die Version 1.3.0 vom 28. August 2026 gegen die eigene Last testen.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes