- Quack ermöglicht die Kommunikation zwischen DuckDB-Instanzen und macht damit Client-Server-Setups sowie die Nutzung derselben Datenbank durch mehrere gleichzeitige Schreibende möglich
- DuckDB behält seine In-Process-Architektur bei, verarbeitet aber die notwendige Zustandssynchronisierung per Remote-Protokoll, wenn mehrere Prozesse dieselbe Datei ändern
- Quack ist ein HTTP-basiertes Request-Response-Protokoll, verwendet die
application/duckdb-Serialisierung und Token-Authentifizierung und nutzt standardmäßig Port 9494
- In Benchmarks übertrug Quack 60 Millionen Zeilen in 4,94 Sekunden und erreichte selbst in kleinen Append-Tests mit 8 Threads etwa 5.434 tx/s
- Geplant sind die Integration mit DuckLake, ein entfernter Catalog-Server, automatische Installation und automatisches Laden, Protokollerweiterungen sowie ein Replikationsprotokoll; ein Production-Release ist für die Zeit um DuckDB v2.0 vorgesehen
Zweck und Hintergrund von Quack
- Quack ist ein Remote-Protokoll, das DuckDB-Instanzen miteinander kommunizieren lässt, sodass DuckDB in einer Client-Server-Konfiguration laufen kann und mehrere gleichzeitige Schreibende dieselbe Datenbank nutzen können
- DuckDB betont seit 2019 seine In-Process-Architektur; die Arbeitsweise ohne separaten Server oder eigenes Protokoll, direkt über Low-Level-API-Aufrufe, passte gut zu interaktiven Data-Science-Workflows wie Python-Notebooks und zur Bereitstellung von SQL-Funktionalität innerhalb von Anwendungen
- Damit mehrere Prozesse dieselbe DuckDB-Datenbankdatei gleichzeitig ändern können, muss viel Zustand, den DuckDB im Hauptspeicher hält, prozessübergreifend synchronisiert werden
- Bisher gab es Umgehungslösungen wie einen separaten RPC-Prozess, Projekte mit dem Arrow Flight SQL protocol, das proprietäre Protokoll von MotherDuck oder „EleDucken“ aus PostgreSQL und pg_duckdb
- Um DuckDB zu einem allgemeinen Datenverarbeitungswerkzeug auszubauen, kann ein Client-Server-Protokoll zusätzlich zu den In-Process-Fähigkeiten neue Anwendungsfälle erschließen
Verwendung von Quack
- Bei Quack kommunizieren zwei oder mehr DuckDB-Instanzen miteinander, wobei DuckDB sowohl die Client- als auch die Serverrolle übernimmt
- Die beiden Instanzen können auf unterschiedlichen Computern, an entfernten Standorten oder in verschiedenen Terminalfenstern auf demselben Laptop laufen
- Die Quack-Erweiterung liegt derzeit im Repository
core_nightly und kann mit der aktuellen Release-Version DuckDB v1.5.2 verwendet werden
- Auf der Server-Seite wird Quack installiert und geladen, danach wird
quack_serve aufgerufen; im Beispiel werden quack:localhost und token = 'super_secret' verwendet
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve(
'quack:localhost',
token = 'super_secret'
);
CREATE TABLE hello AS
FROM VALUES ('world') v(s);
- Auf der Client-Seite wird Quack ebenfalls installiert und geladen, dann wird per
CREATE SECRET ein Token gesetzt und mit ATTACH 'quack:localhost' AS remote; die entfernte Instanz verbunden
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (
TYPE quack,
TOKEN 'super_secret'
);
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;
- Mit dieser Konfiguration kann DuckDB #2 den Wert
world aus der entfernten Tabelle hello abfragen
- Daten lassen sich auch von der lokalen Instanz zur entfernten Instanz kopieren; im Beispiel erstellt DuckDB #2 die Tabelle
remote.hello2, die dann in DuckDB #1 mit FROM hello2; geprüft wird
- Bei komplexen Queries oder großen Datensätzen lässt sich mit der
query-Funktion, die die Query unverändert an die Gegenseite sendet, besser steuern, welche Arbeit remote ausgeführt wird
FROM remote.query(
'SELECT s FROM hello'
);
Protokolldesign
-
HTTP-basiert
- Quack wurde direkt auf HTTP aufgebaut; HTTP hat sich oberhalb von TCP und den darunterliegenden Schichten faktisch als Standard-Protokollebene etabliert
- HTTP-Stacks sind effizient für das Übertragen von Nachrichtenströmen optimiert und verursachen bei korrekter Implementierung nur geringen Overhead
- Wie man mit HTTP in Bereichen wie Load Balancing, Authentifizierung, Firewalls oder Intrusion Detection umgeht, ist weithin bekannt
- Durch die Nutzung von HTTP kann auch die DuckDB-Wasm-Distribution Quack nativ verwenden
- Im Browser laufendes DuckDB kann sich per Quack direkt mit einer auf einem EC2-Server laufenden DuckDB-Instanz verbinden
-
Request-Response-Muster
- Die Interaktion in Quack folgt immer einem vom Client gesteuerten Request-Response-Muster
- Zu den Nachrichten gehören Verbindungsanfragen für die Token-Authentifizierung, Anfragen zur Query-Ausführung, die Rückgabe des ersten Teils der Antwort und nachfolgende Fetch-Nachrichten zum Abrufen großer Ergebnisse
- Große Ergebnisse können parallel über mehrere Threads abgerufen werden
-
Serialisierung
- Requests und Responses werden mit dem neuen MIME-Typ
application/duckdb kodiert
- Diese Kodierung nutzt interne DuckDB-Serialisierungsprimitive für komplexe Strukturen wie Datentypen und Ergebnismengen
- Dieselben Primitive werden seit Jahren auch in den WAL-Dateien von DuckDB verwendet und sind entsprechend stark optimiert und validiert
-
Verschlüsselung und Exposition
- Beim Start erzeugt Quack standardmäßig ein zufälliges Authentifizierungs-Token, das der Client vorlegen muss
- Ein Quack-Server bindet standardmäßig nur an
localhost, dieses Verhalten lässt sich überschreiben
- Standardmäßig wird kein SSL verwendet, weil man es für reine
localhost-Kommunikation nicht für sinnvoll hält, dafür zusätzliche Infrastruktur und Abhängigkeiten einzuführen
- Es wird nicht empfohlen, einen DuckDB-Quack-Endpunkt direkt ins Internet zu stellen
- Wenn Quack im Web exponiert werden muss, wird dringend empfohlen, einen normalen HTTP-Endpunkt wie nginx zu verwenden und dort per Reverse Proxy SSL etwa mit Let’s Encrypt terminieren zu lassen
- Quack-Clients gehen bei nicht-lokalen Verbindungen standardmäßig davon aus, dass SSL aktiviert ist; auch dieses Verhalten kann überschrieben werden
- Relevante Einstellungen sind in der Reverse-Proxy-Dokumentation beschrieben
-
Optimierung der Roundtrips
- Quack wurde so entworfen, dass die Zahl der Protokoll-Roundtrips pro Query reduziert wird
- Nach dem Verbindungsaufbau kann eine einzelne Query in nur einem Roundtrip verarbeitet werden, was in latenzsensiblen Umgebungen vorteilhaft ist
- Auch die Übertragung großer Responses wurde optimiert; das DuckDB-Team sieht Quack derzeit als den schnellsten Weg, Tabellen über Sockets zu übertragen
- Benchmarks zeigen, dass sich Millionen von Zeilen in wenigen Sekunden übertragen lassen
-
Authentifizierung und Autorisierung
- Quack entwirft sein Modell für Authentifizierung und Autorisierung im Sinne der DuckDB-Philosophie der Erweiterbarkeit
- Es bietet eine Standard-Authentifizierung und eine standardmäßig uneingeschränkte Autorisierung, beides kann jedoch durch benutzerdefinierten Code ersetzt werden
- Beim Start erzeugt der Server ein zufälliges Authentifizierungs-Token, und der Client übergibt beim Verbindungsaufbau eine Authentifizierungszeichenkette
- Der Server ruft einen Authentifizierungs-Callback auf; der Standard-Callback vergleicht das vom Client gelieferte Token mit dem vom Server erzeugten Token
- Der Authentifizierungs-Callback kann per Konfiguration ersetzt werden, etwa durch LDAP-Abfragen, das Einlesen einer Textdatei oder beliebige eigene Logik
- Auch die Autorisierungsfunktion lässt sich austauschen; standardmäßig erlaubt sie alle Requests
- Eine benutzerdefinierte Autorisierungsfunktion kann jede vom Client auszuführende Query prüfen und sie mit der zuvor verwendeten Authentifizierungszeichenkette verknüpfen
- Solche Callbacks lassen sich sogar als gewöhnliche SQL-Makros schreiben
-
Standardport
- Ein Quack-Server lauscht standardmäßig auf Port
9494
- Die
94 ist eine leicht merkbare Anspielung auf das Jahr 1994, in dem Netscape Navigator veröffentlicht wurde
Benchmarks
- Die Benchmarks wurden auf AWS-VMs mit Ubuntu on Arm durchgeführt
- Der Instanztyp war m8g.2xlarge mit 8 vCPU, 32 GB RAM und einer Netzwerkbandbreite von „bis zu 15 Gbit/s“
- Ziel war es, ein realistisches Szenario nachzubilden, in dem sich Client und Server im selben Rechenzentrum, aber auf unterschiedlichen Maschinen befinden
- Beide Instanzen wurden in derselben Availability Zone platziert; die durchschnittliche Ping-Zeit lag bei etwa 0,280 ms
-
Bulk Transfer
- Der erste Benchmark misst Bulk-Transfer-Workloads, also die Übertragung vieler Zeilen über ein Datenbankprotokoll
- Verglichen wurden Quack, das PostgreSQL-Protokoll und das Arrow-Flight-SQL-Protokoll
- Arrow Flight wurde über den Server GizmoSQL bereitgestellt, der intern DuckDB verwendet
- Gemessen wurde auf der TPC-H-Tabelle
lineitem, wobei die Zeilenzahl schrittweise bis auf 60 Millionen Zeilen erhöht wurde
- 60 Millionen Zeilen entsprechen im CSV-Format 76 GB
- Jeder Wert wird als Median der Wall-Clock-Zeit aus fünf Durchläufen angegeben
- Die wichtigsten Ergebnisse:
- 100k Zeilen: DuckDB Quack
0.07 s, Arrow Flight 0.07 s, PostgreSQL 0.20 s
- 1M Zeilen: DuckDB Quack
0.24 s, Arrow Flight 0.38 s, PostgreSQL 2.20 s
- 10M Zeilen: DuckDB Quack
0.89 s, Arrow Flight 2.90 s, PostgreSQL 25.64 s
- 60M Zeilen: DuckDB Quack
4.94 s, Arrow Flight 17.40 s, PostgreSQL 158.37 s
- Quack übertrug 60 Millionen Zeilen in unter 5 Sekunden und zeigte damit starke Leistung bei der Übertragung großer Ergebnismengen
- Selbst das zweckgerichtete Arrow Flight SQL blieb in diesem Ergebnis hinter Quack zurück, und das zeilenbasierte PostgreSQL-Protokoll war insgesamt im Nachteil
- Standard-PostgreSQL-Clients parallelisieren das Lesen nicht über mehrere Threads, Quack und Arrow dagegen schon
- Auch der PostgreSQL-Client von DuckDB kann in manchen Fällen parallel lesen
-
Kleine Schreibvorgänge
- Der zweite Benchmark misst kleine Append-Workloads
- Das entspricht Szenarien, in denen kleine Schreibvorgänge zentralisiert werden, etwa beim Sammeln von Observability-Daten in einer zentralen DuckDB-Instanz
- Für Protokolle, die mehrere Client-Server-Roundtrips benötigen, um eine einzelne Transaktion abzuschließen, ist das ein ungünstiger Test
- Es wird eine leere Tabelle mit derselben Struktur wie TPC-H
lineitem erstellt, dann werden zufällige Werte zeilenweise eingefügt, jeweils als eigene INSERT-Transaktion
- Der Test lief jeweils 5 Sekunden mit steigender Zahl paralleler Threads; nach fünf Wiederholungen wurde der Median der Transaktionen pro Sekunde angegeben
- Die wichtigsten Ergebnisse:
- 1 Thread: DuckDB Quack
1,038 tx/s, Arrow Flight 469 tx/s, PostgreSQL 839 tx/s
- 2 Threads: DuckDB Quack
1,956 tx/s, Arrow Flight 799 tx/s, PostgreSQL 1,094 tx/s
- 4 Threads: DuckDB Quack
3,504 tx/s, Arrow Flight 1,224 tx/s, PostgreSQL 2,180 tx/s
- 8 Threads: DuckDB Quack
5,434 tx/s, Arrow Flight 1,358 tx/s, PostgreSQL 4,320 tx/s
- Quack lag bis zu 8 parallelen Threads vor PostgreSQL und erreichte einen Transaktionsdurchsatz von maximal rund 5.500 tx/s
- Darüber hinaus stößt DuckDB aktuell an seine eigene Grenze bei gleichzeitigen Inserts in dieselbe Tabelle pro Sekunde
- PostgreSQL skaliert in diesem Bereich besser; das DuckDB-Team sieht das als Thema für die nähere Zukunft
- Arrow Flight schnitt wie erwartet schwach ab und erreichte nur etwa die Hälfte der PostgreSQL-Leistung
- Die Benchmark-Skripte sind veröffentlicht
Anwendungsfälle und Bedeutung für DuckDB
- Quack ermöglicht Multi-Player-DuckDB, bei dem mehrere unabhängige Prozesse lokal oder remote parallel denselben Tabelleninhalt verändern können
- Ein Teil davon war bereits mit DuckLake möglich, Quack macht es jedoch einfacher und bietet deutlich höhere Performance
- Für Anwendungsfälle, in denen zentraler Zustand wichtiger ist als ultralokale Queries, erweitert sich damit der Einsatzbereich von DuckDB
- Mit der Verbreitung von Data Lakes ist bereits sichtbar geworden, dass Daten nicht immer lokal liegen; Quack passt zu dieser Entwicklung
- Quack soll in DuckLake integriert werden und es ermöglichen, dass DuckDB selbst zu einem remote zugänglichen Catalog-Server wird
- Diese Integration kann neue Funktionen wie Data Inlining ermöglichen
- Weitere Fragen werden in den Quack-FAQ beantwortet
- DuckDB entfernt sich damit weiter von seiner ursprünglichen Nische als In-Process-Datenbank für interaktive Analysen und bewegt sich stärker in Richtung einer Kernkomponente moderner Datenarchitekturen
Warum nicht Arrow Flight SQL?
- Verwandte Projekte wie Arrow und ADBC sind als Austausch-APIs wertvoll, um wie ODBC oder JDBC Reibung beim Datenaustausch zwischen Systemen zu verringern
- Innerhalb von DuckDB ist man jedoch zurückhaltend beim Einsatz von Austauschformaten wie Arrow
- Die internen Strukturen von Zwischenergebnissen in DuckDB ähneln Arrow in mancher Hinsicht, unterscheiden sich in anderer aber deutlich
- Um die Innovation in Datensystemen fortsetzen zu können, will man sich nicht durch extern kontrollierte Formate einschränken lassen; deshalb verwendet Quack eine eigene Serialisierung
- Mit eigener Serialisierung lassen sich neue Datentypen oder Protokollnachrichten sofort ausrollen, sobald sie benötigt werden
- Arrow Flight SQL ist so entworfen, dass jede Query mindestens zwei Protokoll-Roundtrips benötigt, nämlich
CommandStatementQuery und DoGet
- Das ist für kleine Update-Workloads, besonders in Umgebungen mit höherer Latenz, nicht ideal
- Quack wurde so gestaltet, dass bei kleinen Queries die Ausführung und das Fetching des Ergebnisses in einem einzigen Roundtrip erfolgen können
Ausblick
- Quack soll in DuckLake integriert werden, sodass sich ein entfernter DuckDB-Server als DuckLake-Catalog verwenden lässt
- Diese Integration dürfte besonders beim Inlining die Performance deutlich verbessern
- In den kommenden Monaten soll Quack weiter verfeinert werden; die erste Production-Release ist zusammen mit DuckDB v2.0 im Herbst dieses Jahres geplant
- Geplant ist außerdem, die automatische Installation und das automatische Laden der Quack-Erweiterung zu ermöglichen, wenn sie benötigt wird
- Mit dem neuen Parser soll auch die Syntax für die Interaktion von DuckDB mit entfernten SQL-Datenbanken verbessert werden
- Auf Seiten des DuckDB-Kerns soll die Zahl der Transaktionen pro Sekunde stark erhöht werden, damit Transaktionen deutlich über 8 parallele Threads hinaus skalieren können
- Über Authentifizierung und Autorisierung hinaus wird auch geprüft, Erweiterungen des Quack-Protokolls zu erlauben, sodass DuckDB-Erweiterungen neue Protokollnachrichten und Verarbeitungscode hinzufügen können
- Ebenfalls geprüft wird ein Replikationsprotokoll auf Basis von Quack, um Änderungen einer DuckDB-Instanz auf andere Server zu replizieren und Cluster mit Read Replicas aufzubauen
- Quack und seine frühe Einführung sollen auch auf der Community-Konferenz DuckCon #7 am 24. Juni behandelt werden
- Zusätzlich gibt es eine eigene Quack-Projektseite
1 Kommentare
Hacker-News-Kommentare
So etwas hätte ich letzte Woche genau gebraucht, perfektes Timing
Ich habe Sensorwerte mit einem Deno-Server in DuckDB geschrieben, konnte die Daten aber nicht mit
duckdb -uiansehen, ohne den Server herunterzufahrenIch wollte dem Server keine Funktion nur zum Ansehen des DB-Inhalts hinzufügen und hatte mich damit abgefunden, erst mal so weiterzuleben, aber das hier löst dieses Problem und ähnliche Probleme, die ich mit DuckDB hatte, sehr elegant
DuckDB ist 2025/26 meine Lieblingstechnologie und steckt inzwischen tief in vielen Workflows für LLM-Arbeit, Datenspeicherung, Analyse, Datenpipelines usw.
Ich finde es sehr spannend, habe DuckDB aber noch nicht wirklich natürlich in meine Art, Probleme zu lösen, eingebaut und weiß auch nicht genau, auf welche Use Cases ich es gut abbilden könnte
Großartig. Ich habe gerade überlegt, DuckDB in unserem internen App-Framework zu verwenden, und das hier beantwortet die Frage „Wie skaliert man das dann horizontal?“
Applaus an das DuckDB-Team, und ich mag auch, dass das Protokoll Quack heißt
Ich habe an einem Open-Source-Projekt gearbeitet, das Observability-Daten, also Metriken, Logs und Traces, in Parquet speichert und abfragt, und ich stimme stark zu, dass man offene Speicherformate und Kataloge verwenden will, fand die Bedienbarkeit von Apache Iceberg aber frustrierend
Dadurch wirkt DuckLake für meinen Use Case jetzt deutlich interessanter, und ich bin gespannt, wohin sich das entwickelt
https://github.com/smithclay/duckdb-otlp
DuckDB ist toll, aber ich weiß nicht so recht, was es eigentlich werden will
Es tauchen ständig neue Arten auf, es zu verwenden, und es ist nicht leicht, auf einen Blick zu erkennen, welcher Ansatz der richtige ist
Dieser Vorstoß ist ziemlich konsistent und bringt es in gewisser Weise zu einem vertrauten Nutzungsmodell als traditionelle Client-Server-Relationaldatenbank zurück
Relationale DBMS waren ursprünglich Mehrbenutzer-Konkurrenzsysteme, und DuckDB ist eine extrem schnelle lokale Engine, die sich in andere Systeme einbetten lässt und dadurch viele verschiedene Use Cases hat
Das ist ähnlich, als würde man fragen, was SQLite eigentlich sein will. Es steckt in Telefonen, Browsern, Desktop-Apps und IoT-Geräten, und Leute haben es in viele Richtungen erweitert. Der Unterschied ist hier, dass es nicht von Dritten, sondern vom First-Party-Team kommt, und für mich ist das ein sehr nachvollziehbarer Schritt
Die App beobachtet Assets auf S3 und holt sie, wenn sich der etag ändert
Man bekommt auf einfache Weise Performance wie bei BigQuery oder ClickHouse, ohne diese Infrastruktur selbst betreiben oder dafür bezahlen zu müssen
Nicht für jeden Fall perfekt, aber es deckt viel mehr ab, als man erwarten würde
Die Engine selbst ist inzwischen nicht mehr immer der problematische Teil, sondern das Drumherum: Live-Datenbanken, S3-Pfade, Parquet-Dateien, Credentials, reproduzierbare Ausführung, Exporte, Validierung und die Momente, in denen Einweg-Skripte still und leise zu Infrastruktur werden
Quack macht den Remote-/Server-Teil sauberer, aber der größere Trend sieht für mich so aus, dass DuckDB eher die SQL-Schicht innerhalb von Tools wird als ein Endnutzerwerkzeug
Es wurde nicht erklärt, was mit „gleichzeitigen Schreibern“ gemeint ist
Auf den ersten Blick sieht es so aus, als würde man serverseitig Schreibvorgänge serialisieren
Ich sehe keinen Grund, warum dieses Feature plötzlich alle Schreibvorgänge serialisieren sollte
Für kleine interne Analyse-Datensätze, die man auf einen gemeinsamen Team-Server legen will, wirkt das nützlich
Für ein Homelab ist es definitiv ebenfalls einen Blick wert
Ein großer Vorteil dieses Serverprotokolls ist, dass man sich einen Server mit viel Speicher teilen und einen gemeinsamen Cache für aktuelle Daten nutzen kann
Ich habe eine C++-Anwendung, und zur Laufzeit ist alles im Speicher
Zwischen Sitzungen speichere ich auf Platte als XML, und das funktioniert gut, ist aber strikt nur für einen Benutzer gedacht, und einige Kunden möchten das verallgemeinern, sodass mehrere Benutzer gleichzeitig lesen und schreiben können
Die Performance-Anforderungen sind niedrig, eher 2–3 Personen, die gleichzeitig ein paar Tausend Einträge aktualisieren. Wäre DuckDB + Quack dafür eine gute Wahl, oder gibt es etwas Besseres? Ich habe mir auch SQLite angesehen, verstehe es aber so, dass es nicht als Client-Server arbeitet
Es dürfte schwer sein, eine gute Option zu finden, um eine DB mit gleichzeitigen Benutzern zu verwenden, ohne irgendeine Form von serverseitigem Hosting zu betreiben
Klar, es ist möglich, so wie manche Spiele ihren eigenen Client-Server für Multiplayer bauen, aber ehrlich gesagt ist es absurd günstig und einfach, Postgres oder SQLite zu hosten, und vor allem ist das der Standardansatz für dieses Problem
Hervorragend. Ich habe mit DuckDB eine spaltenorientierte Tabellenkalkulations-App ähnlich wie Excel gebaut und musste den „Client“ über eine traditionelle HTTP-Schicht wieder neu erschaffen
Die Frage „Was will DuckDB eigentlich werden?“ kommt immer wieder auf, aber ich finde, die Antwort ist längst klar
Es will das SQLite für Analytik sein: einbettbar, ohne Konfiguration und überall lauffähig
Quack ist einfach der Teil, der dieses „überall“ auch auf Remote erweitert
Bei der Frage „Kann man mit Quack DuckDB als Katalogdatenbank für DuckLake verwenden?“ steht: „Noch nicht, aber wir arbeiten daran!“
Das wirkt wie ein Nischen-Use-Case, ist aber genau der Teil, der mich am meisten interessiert
Unser Lakehouse nutzt DuckLake und Postgres als Katalog, aber ein DuckDB-/Quack-Katalog scheint eine hervorragende Alternative zu sein
Dafür gibt es mehrere Gründe. Erstens gibt es bei der Inlining-Verarbeitung keine Typinkonsistenzen. Wenn man einen Nicht-DuckDB-Katalog verwendet, lassen sich viele Typen nicht 1:1 abbilden, was zusätzlichen Overhead verursacht, sobald man mit diesen Datentypen arbeitet
Zweitens bekommt man auf dem Katalog obendrauf direkt die Analyse-Performance von DuckDB und jetzt auch die Transaktions-Performance. Dass DuckDB DuckDB liest, ist schlicht schneller als unsere Scanner für Postgres/SQLite
Drittens gibt es keine Roundtrips für Retries. Die gesamte Retry-Logik lässt sich einfach(tm) serverseitig in DuckDB ausführen. Aktuell erzeugen solche Retries mehrere Roundtrips zu Postgres und werden bei Workloads mit hoher Konkurrenz zu einem Performance-Flaschenhals
Zur Einordnung: Ich bin Entwickler bei duckdb/ducklake
Man wird es in ein paar Tagen testen können