DuckDB 2.0 LTS: Quack bringt Serverbetrieb, Agent-Modus und Trigger
Die Analysedatenbank bleibt eingebettet nutzbar, kann nun aber auch entfernte Clients bedienen, Tabellenänderungen automatisch verarbeiten und ihre CLI-Ausgaben für Coding-Agenten verdichten.
DuckDB 2.0.0 LTS erweitert die eingebettete, spaltenorientierte SQL-Datenbank um einen zweiten Betriebsmodus: Mit Quack kann eine DuckDB-Instanz Abfragen anderer DuckDB-Instanzen über HTTP beantworten. Damit lassen sich lokale Analysedaten und Rechenleistung auf einem Rechner halten, während mehrere entfernte Clients darauf zugreifen. Gleichzeitig richtet der neue Agent-Modus die Kommandozeile auf Programme aus, die kurze, eindeutig begrenzte und maschinenlesbare Antworten benötigen. DuckDB-Ankündigung · Quack-Dokumentation
Das Release trägt den Namen „Cinnamon Teal“ und ist als LTS-Version mindestens bis Oktober 2027 unterstützt. Zum Veröffentlichungstermin am 21. Oktober 2026 standen die Kommandozeile und das Python-Paket bereit; andere Clientbibliotheken und Erweiterungen konnten mit einigen Tagen Abstand folgen. Diese zeitversetzte Verfügbarkeit ist relevant, wenn eine Anwendung nicht nur Python oder die CLI verwendet. DuckDB-Ankündigung
Quack trennt Analyse und Zugriffsort
DuckDBs bekanntes Grundmodell bleibt erhalten: Die Datenbank lässt sich weiterhin direkt in einen Prozess einbetten, ohne einen separaten Datenbankdienst zu betreiben. Quack ergänzt dieses Modell um eine Client-Server-Verbindung. Eine DuckDB-Instanz übernimmt die Serverrolle; eine andere verbindet sich als Client und schickt ihre SQL-Abfragen über HTTP. In DuckDB 2.0 stehen dafür auch die SQL-Befehle CONNECT und DISCONNECT zur Verfügung. Die Quack-Funktion selbst existiert laut Dokumentation seit Version 1.5.3, wird mit den neuen Befehlen nun aber zu einem sichtbareren Bestandteil der regulären SQL-Bedienung. Dokumentationsübersicht zu DuckDB 2.0
Der praktische Unterschied zeigt sich beim Ort der Daten. Eine große lokale Datei oder eine vorbereitete DuckDB-Datenbank muss nicht mehr zu jedem Arbeitsplatz kopiert werden. Sie kann auf dem Rechner verbleiben, der Speicherplatz, Datenzugriff und Rechenleistung bereitstellt. Die Clients schicken SQL dorthin und erhalten das Resultat zurück. Das ist kein allgemeiner Ersatz für jede verteilte Datenbank: Quack macht gezielt eine DuckDB-Sitzung erreichbar und stellt deren SQL-Oberfläche bereit.
Entfernte Clients fragen denselben Datenbestand ab
Ein konkretes Einsatzbild ist ein Analysecomputer mit umfangreichen Parquet-Dateien oder einer persistenten DuckDB-Datenbank. Darauf läuft der Quack-Server. Analyst:innen verbinden ihre eigenen DuckDB-Instanzen mit diesem Endpunkt und können die freigegebene Sitzung abfragen, ohne die Quelldateien lokal vorzuhalten. Ebenso kann eine Python-Anwendung den entfernten Bestand nutzen, sofern die passende DuckDB-Version und Erweiterung verfügbar sind.
Nach dem Verbindungsaufbau benötigt eine Abfrage einen Request-Response-Durchlauf. Kleine Resultate können unmittelbar zurückkommen. Für große Ergebnismengen verwendet Quack zusätzliche FETCH-Anfragen, die optional parallel ausgeführt werden. Diese Trennung ist technisch wichtig: Nicht jede Abfrage wird zu einer einzigen riesigen HTTP-Antwort, und die Übertragung größerer Resultate kann mehrere Abrufe nutzen. Zugleich bleibt die Netzwerklatenz Teil jeder entfernten Abfrage. Besonders passend sind daher analytische Abfragen, die Daten nahe am Server verdichten und ein vergleichsweise kleines Ergebnis liefern. Quack Remote Protocol
Ein Beispiel ist die Auswertung mehrerer großer Dateien nach Zeitraum und Produktgruppe. Statt alle Rohdaten über das Netz zu ziehen, führt der Server Filter, Aggregation und Sortierung aus. Der Client erhält nur die gruppierte Tabelle. Eine Abfrage, die Millionen unverdichteter Zeilen zurückliefert, ist dagegen stärker von den zusätzlichen FETCH-Übertragungen abhängig. Quack verändert also nicht nur den Zugriffsort, sondern macht die Form der SQL-Abfrage für die Netzwerkkosten bedeutsamer.
Der Agent-Modus begrenzt Ausgaben bewusst
Coding-Agenten können eine Datenbank-CLI aufrufen, doch klassische Terminalausgaben sind dafür oft unnötig groß oder schwer zuverlässig auszuwerten. DuckDB 2.0 führt deshalb einen Agent-Modus ein. Erfolgreiche Abfragen erscheinen als kompakte Markdown-Tabellen. Werden Ergebnisse gekürzt, weist die Ausgabe darauf hin. Fehler landen als JSON auf stderr, sodass ein aufrufendes Programm Fehlermeldungen getrennt von regulären Resultaten verarbeiten kann. Dokumentation zum Agent-Modus
Die Standardgrenzen sind konkret: Bis zu 1.000 Zeilen und insgesamt 10.000 Byte werden vollständig ausgegeben. Größere Resultate erscheinen gekürzt; einzelne Zellen werden bei 500 Zeichen abgeschnitten. Diese Grenzen schützen den Kontext eines Agenten davor, durch eine versehentlich sehr große Ergebnismenge belegt zu werden. Sie sind allerdings keine SQL-Grenzen der Datenbank. Wer vollständige Massendaten benötigt, sollte sie mit SQL weiter verdichten oder in ein dafür geeignetes Ziel schreiben, statt die Terminalausgabe als Transportformat zu verwenden.
Der Modus kann mit -agent ausdrücklich aktiviert werden. Automatisch schaltet DuckDB ihn nur ein, wenn eine Agent-Umgebung erkannt wird, die Standardausgabe umgeleitet ist und kein anderes Ausgabeformat ausdrücklich gewählt wurde. Dadurch bleibt die gewohnte interaktive Darstellung für Menschen erhalten, während automatisierte Aufrufe eine vorhersehbar kompakte Antwort bekommen. Ein Agent kann beispielsweise zuerst Schema und Stichprobe abfragen, danach eine gezielte Aggregation formulieren und JSON-Fehler auswerten, ohne eine unkontrollierte Tabelle in seinen Kontext zu übernehmen.
Trigger reagieren direkt auf Tabellenänderungen
Mit Triggern kann DuckDB Aktionen automatisch ausführen, wenn sich eine Tabelle verändert. Die Dokumentation nennt zwei typische Anwendungen: Audit-Datensätze schreiben und Invarianten durchsetzen. Damit lässt sich etwa eine Änderung an einer fachlich wichtigen Tabelle zusätzlich in einer Protokolltabelle festhalten. Alternativ kann eine Regel verhindern, dass eine Änderung einen unerlaubten Zustand erzeugt. Dokumentationsübersicht zu DuckDB 2.0
Das ergänzt den neuen Serverbetrieb sinnvoll, ohne auf ihn beschränkt zu sein. Wenn mehrere Clients dieselbe über Quack erreichbare Instanz verändern, liegt die Reaktion auf die Änderung in der Datenbank und nicht in jedem einzelnen Client. Die Clients müssen die Audit-Aktion dann nicht jeweils selbst nachbauen. Auch im eingebetteten Betrieb sind Trigger nützlich, wenn mehrere Codepfade dieselbe Tabelle beschreiben und eine gemeinsame Regel zuverlässig am Datenbestand hängen soll.
Dabei ist die Aufgabenverteilung klar: Quack transportiert Verbindung, Abfrage und Ergebnis; ein Trigger reagiert innerhalb der Datenbank auf eine Tabellenänderung. Der Agent-Modus wiederum formatiert die Ausgabe der CLI. Die drei Neuerungen lösen unterschiedliche Probleme und können kombiniert werden, sind aber nicht voneinander abhängig.
VARIANT hält semistrukturierte Daten in der Spaltenausführung
Der neue Datentyp VARIANT nimmt schemalose, semistrukturierte Werte wie JSON auf und verarbeitet sie innerhalb von DuckDBs spaltenorientierter Ausführung. Das ist interessant, wenn ein Datensatz stabile Spalten mit wechselnden Zusatzfeldern verbindet: Identifikator, Zeitpunkt und Kategorie können reguläre Spalten bleiben, während uneinheitliche Attribute in einer VARIANT-Spalte liegen. Dokumentationsübersicht zu DuckDB 2.0
Damit muss nicht jedes seltene oder erst später auftauchende Feld sofort eine eigene Tabellenspalte erhalten. Zugleich bleibt SQL der Zugriffspunkt für die Analyse. Ein mögliches Muster sind Ereignisdaten verschiedener Versionen, deren gemeinsamer Kern stabil ist, während der Nutzdatenbereich unterschiedliche Felder enthält. VARIANT ersetzt dabei kein durchdachtes Schema für häufig gefilterte und aggregierte Merkmale. Es schafft vielmehr einen definierten Platz für den Teil der Daten, dessen Struktur tatsächlich variabel ist.
Asynchrone Datei-I/O hält Abfragen in Bewegung
DuckDB 2.0 nennt asynchrone Datei-I/O als weitere zentrale Neuerung. Dateioperationen können damit so organisiert werden, dass Wartezeit auf I/O andere Arbeit weniger stark blockiert. Das passt zu einer Analysedatenbank, die häufig direkt auf Dateien zugreift und große Datenmengen scannt. Der Nutzen liegt besonders nahe, wenn Speicher oder Netzdateien nicht sofort antworten und die Ausführung währenddessen weitere verfügbare Arbeit erledigen kann. DuckDB-Ankündigung
Hinzu kommt ein neuer erweiterbarer SQL-Parser auf PEG-Basis. Erweiterbarkeit bedeutet hier, dass zusätzliche SQL-Syntax nicht ausschließlich im festen Kern des bisherigen Parsers verankert werden muss. Für Nutzer:innen wird das vor allem dort sichtbar, wo Erweiterungen eigene Syntax anbieten. Zusammen mit VARIANT, Triggern und Quack vergrößert dieser Parser die technische Fläche von DuckDB: Das Release betrifft nicht nur schnellere Ausführung, sondern auch Sprache, Datentypen, Reaktionen auf Änderungen und die Verbindung zwischen Instanzen.
Externe Quack-Server brauchen eine klare Sicherheitsgrenze
Ein Quack-Server stellt grundsätzlich die vollständige SQL-Oberfläche bereit. Dazu gehören Lese- und Schreibzugriffe auf alle Tabellen, die für seine Sitzung sichtbar sind. Nach erfolgreicher Authentifizierung erlaubt die Voreinstellung jede Abfrage; das standardmäßig zufällig erzeugte Zugriffstoken ersetzt keine feinere Rechteverteilung. Wer unterschiedliche Clients auf verschiedene Daten oder Operationen beschränken will, muss diese Autorisierung ausdrücklich konfigurieren. Quack-Sicherheit
Die Netzwerkeinstellung beginnt konservativ: Standardmäßig bindet der Server nur an localhost. Eine extern erreichbare Adresse muss ausdrücklich freigegeben werden. Sobald Clients über Rechnergrenzen hinweg zugreifen, empfiehlt DuckDB, Quack nicht direkt ins Internet zu stellen. Davor gehört ein bewährter Reverse Proxy, der TLS terminiert. So wird die HTTP-Verbindung verschlüsselt und der Datenbankdienst bleibt hinter einer kontrollierten Netzwerkschicht. Quack Remote Protocol · Quack-Sicherheit
Das passende Einsatzprofil ergibt sich daraus recht deutlich. Lokal bleibt DuckDB weiterhin eine unkomplizierte eingebettete Analysedatenbank. Quack ist interessant, wenn mehrere bekannte Clients denselben Datenbestand oder denselben leistungsfähigen Rechner nutzen sollen. Der Agent-Modus eignet sich für kompakte CLI-Abfragen durch Coding-Agenten. Trigger zentralisieren Reaktionen auf Änderungen, und VARIANT nimmt Daten mit wechselnder Struktur auf. Für einen öffentlich erreichbaren Mehrmandantendienst mit stark unterschiedlichen Rechten reicht die Quack-Voreinstellung dagegen nicht aus; dort werden die eigens konfigurierte Autorisierung, TLS und eine bewusst begrenzte Server-Sitzung zu tragenden Teilen des Betriebs.
Was mit Version 2.0 jetzt anders ist
Die stärkste Kombination entsteht bei analytischen Aufgaben, die nah an den Daten ausgeführt werden sollen: Ein zentraler Rechner hält Dateien und Datenbank, Quack nimmt SQL entgegen, DuckDB verdichtet die Daten und liefert ein begrenztes Resultat zurück. Ein Coding-Agent kann dasselbe Prinzip über die CLI nutzen, bekommt aber dank Agent-Modus eine knappe Markdown-Tabelle oder einen strukturierten Fehler. DuckDB bleibt damit lokal einbettbar, ist in Version 2.0 jedoch nicht mehr auf den lokalen Prozess als einzigen Zugangspunkt festgelegt.