Mit Dolt 2.0 ändert sich vieles an der Storage-Engine der versionierten SQL-Datenbank. Mehrere zentrale Funktionen sind nun erstmals standardmäßig aktiv: eine automatische Garbage Collection und ein neues Archivformat für historische Daten. Hinzu kommen ein Beta-Support für Vektordaten sowie ein neues Verfahren namens Adaptive Storage für Datentypen wie JSON oder BLOBs. Laut den Entwicklern erreicht Dolt zudem inzwischen bessere Sysbench-Werte als MySQL.

Das Open-Source-Projekt Dolt ist eine relationale Datenbank mit einer Versionsverwaltung nach Vorbild von Git. Entwickler können Datenbanken committen, branchen, mergen und Unterschiede zwischen Datenständen vergleichen. Technisch kombiniert das Projekt eine MySQL-kompatible SQL-Schicht mit einer eigenen versionierten Storage-Engine. Eingesetzt wird Dolt unter anderem für kollaborative Datenpflege, reproduzierbare Datensätze, Auditing oder Data-Engineering-Workflows.

Automatische Aufräumarbeiten

Die nun standardmäßig aktive Garbage Collection entfernt nicht mehr referenzierte Datenblöcke im Hintergrund und soll vor allem den Betrieb großer oder stark verzweigter Datenbanken vereinfachen. Gerade bei versionierten Datenbanken wächst der Speicherbedarf schnell, da Dolt jede Änderung historisiert. Bislang mussten Administratoren die Bereinigung häufig manuell oder per geplantem Job anstoßen. Eine Online Garbage Collection, die auch im laufenden Betrieb arbeitet, hatte das Projekt bereits zuvor eingeführt.

Ebenfalls standardmäßig aktiv ist das neue Archivformat. Es speichert historische Datenstände kompakter und reduziert so den Speicherbedarf. Während der Entwicklung hatte das Projekt Einsparungen von bis zu 50 Prozent genannt. Das Format zielt vor allem auf Datenbanken mit vielen Snapshots oder langen Änderungshistorien und soll langfristige Archivierung sowie Cold-Storage-Szenarien erleichtern.

Schneller als MySQL

Bei der Performance verweist DoltHub auf eigene Sysbench-Ergebnisse, in denen Dolt insgesamt leicht vor MySQL liegt. Sysbench ist ein verbreitetes Benchmark-Werkzeug für OLTP-Workloads und misst typische Datenbankoperationen wie Inserts, Updates und Reads. Laut Dokumentation schneidet Dolt bei Schreiboperationen rund 10 Prozent schneller ab als MySQL, während Lesezugriffe mit rund 5 Prozent noch etwas langsamer ausfallen. Performance galt bislang als eine der größten Hürden versionierter Datenbanken.

Neu ist außerdem der Beta-Support für Vektordaten. Dabei handelt es sich um numerische Embeddings, wie sie etwa KI-Anwendungen für semantische Suche oder Retrieval-Systeme nutzen. Vergleichbare Funktionen bieten inzwischen auch PostgreSQL-Erweiterungen wie pgvector oder spezialisierte Vektordatenbanken. Die Release Notes sprechen allerdings ausdrücklich noch von einem Beta-Status.

Adaptive Speicherung großer Werte

Mit Adaptive Storage führt Dolt zudem eine neue Speicherstrategie für die Typen TEXT, JSON, GEOMETRY und BLOB ein. Große Inhalte kodiert die Engine dynamisch anders oder lagert sie aus. Die Entwickler vergleichen den Mechanismus mit TOAST aus PostgreSQL, das große Werte ebenfalls automatisch außerhalb der eigentlichen Tabellenzeilen ablegt. Ziel sind ein geringerer Speicherverbrauch und effizientere I/O-Zugriffe, etwa bei umfangreichen JSON-Dokumenten oder Binärdaten.

Details zu allen Änderungen finden sich in den Release Notes auf GitHub. Dolt 2.0 bleibt nach Angaben der Entwickler grundsätzlich kompatibel zu 1.x-Datenbanken. Allerdings lassen sich nicht alle mit 2.x erzeugten Datenbanken auch mit älteren 1.x-Clients lesen. Wer gemischte Deployments betreibt oder Rollbacks einplant, sollte das bei der Migration berücksichtigen.

(fo)

Die Geschichte der App von Anton Baranov ist eine von der Sorte: Wo ein Wille ist, ist auch ein Weg. Nein, nicht gleich die vom Tellerwäscher zum Millionär, aber immerhin vom Küchentisch nach Cupertino hat es der 22-Jährige gebracht. Seine erste Reise in die USA. All das gelang mithilfe der Apple-Programmiersprache Swift. Und mit großem Engagement und Zeiteinsatz, was er im Gespräch eher beiläufig erwähnt.

Für Anfang Juni hat Apple ihn nach Kalifornien, in den Apple Park, den futuristischen Stammsitz des iPhone-Herstellers, eingeladen. Dort beginnt am 8. Juni 2026 die Entwicklerkonferenz WWDC. Baranov ist einer von 50 geladenen Nachwuchsentwicklern aus aller Welt, die beim jährlichen Wettbewerb Swift Student Challenge die Jury begeistern konnten und dorthin eingeladen wurden.

Erste Teilnahme und gleich nach Cupertino

Aus dem Stand hat der Student es geschafft, gleich bei seiner ersten Teilnahme an der Challenge in die erste Reihe der Distinguished Winners aufzusteigen. Die Reise nach Cupertino ist die höchste Ehre. Manche brauchen dafür Jahre, viele schaffen es nie. Insgesamt hat Apple 350 junge Menschen aus 37 Ländern ausgezeichnet. 50 erhielten den Titel des „Distinguished Winner“ – für herausragende Einreichungen. Die frohe Botschaft erreichte ihn im Frankfurter Hauptbahnhof, erinnert er sich. „Ich habe die Mail aufgemacht und dachte erst: Okay, ich habe verloren. Weil die normalerweise direkt mit Glückwunsch anfangen.“ Er öffnet sie trotzdem. Liest. Liest noch einmal. Und war begeistert.

Die App, um die es geht, heißt „Pitch Coach: Sicher auftreten“ und sie ist seit März im App Store verfügbar. Pitch Coach analysiert Sprache in Echtzeit. Die App erkennt Füllwörter wie „ähm“, „halt“ oder „irgendwie“ und misst die Redegeschwindigkeit. Nach jeder Sitzung wird eine KI-generierte Auswertung angezeigt. Das Besondere: Die gesamte Verarbeitung läuft auf dem Gerät selbst. Kein Ton, keine Daten verlassen das iPhone. Möglich macht dies Apples Foundation-Models-Framework, das seit iOS 26 für Entwicklerinnen und Entwickler zugänglich ist.

Noch eine Funktion sticht heraus: Wer AirPods trägt, bekommt auch Feedback zur Körperhaltung. Die Bewegungssensoren in den Ohrhörern verraten, ob jemand den Kopf hängen lässt, ob die Haltung kippt. „Ich habe irgendwo gelesen, dass AirPods so einen Sensor haben. Einfach gegoogelt – und es hat funktioniert“, sagt Baranov. „Voll cool.“

Idee entstand am Küchentisch

Die Idee zur App entstand am heimischen Küchentisch. Seine Mutter, von Beruf Professorin, erzählte vom Uni-Alltag. Von talentierten Studenten, die hinter ihren Möglichkeiten bleiben, weil Sprache und Haltung nicht das ausstrahlen, was sie können. Baranov hörte zu – und erkannte sich selbst. Dass es darauf ankommt, wie man sich präsentiert, wie man spricht, wie man wirkt. Eine App, die dabei hilft, fand er im App Store nicht.

Die gute Idee ist das eine, die Umsetzung aber nochmal eine ganz andere Sache. Im August 2024 fing der 22-Jährige an, erste Projekte mit Swift umzusetzen, las Bücher und veröffentlichte Apps im App Store. Hier war es von Vorteil, dass Baranov Softwaretechnologie an der Technischen Hochschule Mittelhessen (THM) studiert – dual, in Kooperation mit der Deutschen Bank.

Seine App wurde inzwischen 9000 Mal heruntergeladen – das Neunfache dessen, was er sich als Ziel bis zum Sommer vorgenommen hatte. Und das Interesse dürfte durch die Medienberichterstattung über die Student Challenge noch zunehmen. Die Lokalisierung in 20 Sprachen ist bereits erledigt, weitere Updates sollen folgen. Und mit jedem User kommen neue Ideen. Manche Nutzungsszenarien überraschen ihn, sagt er. „Ich dachte, die Menschen bereiten Präsentationen vor, üben für Vorstellungsgespräche. Und dann schickt mir jemand eine Audio-Datei von einem Rap. Jemand anderes übt Stand-up-Comedy.“ Er zuckt mit den Schultern. „Users define the app. Wenn sie sie dafür benutzen, dann ist das eben so.“

Vibe-Coding und die Zukunft

Vibe-Coding – die Möglichkeit, dass jeder ohne Programmierkenntnisse heutzutage eine App per Zuruf erstellen kann – bereitet dem Challenge-Gewinner übrigens keine großen Sorgen. Man müsse wissen, welche Libraries gefragt sind, welche APIs genutzt werden, wie man ein Problem überhaupt präzise beschreibt. „Man steuert das trotzdem.“ Damit bestätigt er, was Forscher zuletzt in Studien herausgefunden haben: Entwickler mit solidem Hintergrundwissen sind die besseren Vibe-Coder – weil sie KI-Werkzeugen genau sagen können, was sie brauchen. Baranov sieht das pragmatisch: Die Tools erleichtern die Arbeit, aber sie machen nicht die Arbeit.

Und wo geht seine Reise nach diesem Erfolg beruflich hin? Die WWDC sieht Baranov auch als große Chance an, zu netzwerken. An seiner derzeitigen beruflichen Laufbahn bei der Bank will er aber aktuell nicht rütteln: Diese Erfahrung sei wertvoll, sagt er. Aber dass der Bilderbuchstart bei der Swift Student Challenge irgendwann doch in eine Solo-Karriere mündet – wer möchte das schon ausschließen?

(mki)

Mit Version 5.0.0 baut La Suite Docs vor allem seine Dokument-API um. Der größte Einschnitt: Inhalt und Metadaten eines Dokuments sind nun getrennt. Laut den offiziellen Release Notes und der Upgrade-Anleitung heißt der bisherige Content-Pfad jetzt formatted-content, das Feld content fällt aus der regulären Dokumentantwort weg und für Lesen sowie Schreiben kommen eigene Endpunkte hinzu. Für bestehende API-Clients ist das ein Breaking Change.

La Suite Docs ist ein quelloffener Editor für die Zusammenarbeit von Teams und versteht sich als souveräne Alternative zu Notion oder Google Docs. Zielgruppen sind öffentliche Einrichtungen ebenso wie Unternehmen. Hinter dem Projekt stehen das deutsche Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) und die französische Interministerielle Behörde für Digitales (DINUM).

Inhalt und Metadaten getrennt

Den Grund für den harten Schnitt nennen die Entwickler im Commit d7a186a. Bisher liefen Inhaltsänderungen über denselben Update-Endpunkt wie andere Dokumenteigenschaften. Selbst beim simplen Umbenennen lieferte der Server den kompletten Inhalt mit aus – und griff dafür unnötig auf den im S3-Speicher abgelegten Dokumentzustand zu. Dafür gibt es jetzt einen eigenen Endpunkt: PATCH /api/v1.0/documents/{document_id}/content/. Die Upgrade-Anleitung zeigt als erwartete Payload ein Base64-codiertes Feld content. Ist der übergebene Dokumentzustand ungültig, antwortet der Server mit 400 Bad Request und der Fehlermeldung invalid yjs document. Wer nur Metadaten wie Titel oder Sichtbarkeit ändert, muss damit nicht mehr den eigentlichen Dokumentinhalt mitschleppen.

Auch zum Lesen gibt es einen eigenen Endpunkt. GET /api/v1.0/documents/{document_id}/content/ streamt den Inhalt laut Upgrade-Anleitung als text/plain. Der Commit 6b3d197 zeigt, dass dafür StreamingHttpResponse und 8192 Byte große Chunks zum Einsatz kommen. Fehlt die Datei im Storage, liefert der Endpunkt trotzdem HTTP 200 mit leerem Body. Die Tests im selben Commit dokumentieren auch die Zugriffsmatrix: Anonyme Nutzer dürfen öffentliche Dokumente abrufen; für nicht öffentliche Dokumente erhalten sie 401. Authentifizierte Nutzer ohne Berechtigung bekommen bei restricted ein 403. Im Code spricht das Projekt von „raw Yjs content“. Yjs ist eine Bibliothek für Echtzeit-Kollaboration, die gemeinsame Datentypen automatisch synchronisiert. Der Endpunkt liefert also eher den kollaborativen Rohzustand eines Dokuments als ein fertig gerendertes Austauschformat.

Konverter und KI-Anbindung umgebaut

Für Selfhoster dürfte die zweite große Nachricht das Upgrade des Konvertierungsdiensts auf DocSpec 3.0.x sein. Pull Request #2220 hält ausdrücklich fest, dass das Docker-Image ghcr.io/docspecio/api:3.0.0 gemeinsam mit dem Anwendungscode aktualisiert werden muss. Das neue Request-Format ist nicht abwärtskompatibel; wer nur eine Seite aktualisiert, riskiert Ausfälle bei der Dokumentkonvertierung. Derselbe Pull Request beschreibt ferner die technische Umstellung: Statt eines Multipart-Uploads schickt der Client den Dokumentinhalt jetzt direkt im Request-Body und setzt Content-Type und Accept explizit. Wer eigene Compose-, Helm- oder Kubernetes-Setups pflegt, muss den Konverter also fest in den Major-Upgrade-Plan einplanen.

Neu ist außerdem eine Mistral-Anbindung für die neue KI-Pipeline. Der Commit b6efac3 führt eine Provider-Auswahl ein, die je nach Konfiguration entweder OpenAIChatModel oder MistralModel verwendet. In der Dokumentation der Umgebungsvariablen tauchen dafür OPENAI_SDK_API_KEY, OPENAI_SDK_BASE_URL, MISTRAL_SDK_API_KEY und MISTRAL_SDK_BASE_URL auf. Die Upgrade-Anleitung benennt zugleich die früheren Variablen AI_API_KEY und AI_BASE_URL in OPENAI_SDK_* um. Wichtig für Betreiber eigener KI-Infrastruktur: Der Mistral-Pfad funktioniert nur im Async-Betrieb mit uvicorn. Für Endanwender ändert sich damit zunächst wenig; die Neuerung zielt auf Installationen, die nicht ausschließlich OpenAI-kompatible Gegenstellen nutzen.

Kleinere Verbesserungen für Betrieb und Frontend

Daneben gibt es in Version 5.0.0 mehrere praxisnahe Updates für Betrieb und UI. Pull Request #2241 begründet den jetzt konfigurierbaren Forward-Auth-Header damit, dass Traefik andere Header-Namen verwendet; per Konfiguration lässt sich der auszulesende Header etwa auf HTTP_X_FORWARDED_URI setzen. Im Frontend wandert die Crisp-Hilfefunktion laut PR #2222 ins Hilfemenü – der bisherige Button habe Teile der App überlagert.

Hinzu kommen kleinere, aber nützliche Korrekturen: Angeheftete Dokumente sortiert das Backend laut PR #2028 nun nach updated_at absteigend und ungültige Verschiebeoperationen im Dokumentbaum quittiert der Server laut PR #2208 mit 400 Bad Request statt mit 500 Internal Server Error. Die Release Notes listen zudem mehrere Verbesserungen bei der Barrierefreiheit und kleinere Frontend-Fixes auf.

Unterm Strich ist Version 5.0.0 kein großes Feature-Release, sondern ein Backend- und Infrastruktur-Umbau mit spürbaren Folgen für API-Clients, Selfhoster und Betreiber eigener Zusatzdienste. Endanwender bekommen vor allem kleinere UI-Verbesserungen zu sehen. Für Integratoren bringt die neue Trennung zwischen Metadaten, formatiertem Inhalt und rohem Inhaltsstream dagegen einige Anpassungen mit sich.

(fo)