2025-09-16

Ankündigung: DuckDB 1.4.0 LTS

The DuckDB team

Wir sind stolz, DuckDB v1.4.0 zu veröffentlichen, benannt „Andium“ nach der Andenente (Anas andium), die in den Andenhochländern von Kolumbien, Venezuela und Ecuador lebt.

In diesem Blogbeitrag behandeln wir die wichtigsten Updates dieses Releases rund um Support, Features und Extensions. DuckDB bewegt sich ziemlich schnell, und wir können nur einen kleinen Teil der Änderungen in diesem Release abdecken. Die vollständigen Release Notes stehen auf der Release-Seite auf GitHub.

Zur Installation der neuen Version besuchen Sie bitte die Installationsseite. Hinweis: Es kann ein paar Tage dauern, bis einige Client-Bibliotheken (z. B. Go, R, Java) erscheinen, wegen der zusätzlichen Änderungen und Review-Runden.

Long-Term-Support-(LTS-)Edition

Wir freuen uns, dass DuckDB regelmäßig in Produktionsumgebungen genutzt wird, und wissen, dass solche Deployments oft langfristige Wartung brauchen. Früher haben wir alte DuckDB-Versionen automatisch deprecated, sobald die neuere Version erschien. Das ändern wir heute.

Ab diesem Release wird jede zweite DuckDB-Version eine Long-Term-Support-(LTS-)Edition. Für LTS-DuckDB-Versionen dauert der Community-Support ein Jahr nach dem Release (vorerst). DuckLabs beginnt außerdem, Support für ältere LTS-Versionen anzubieten, nachdem ihr Community-Support abgelaufen ist.

Klicken Sie, um die End-of-Life-(EOL-)Daten für DuckDB-Releases zu sehen.

Version	Codename	End of community support
0.*		2024-06-03
1.0.*	Nivis	2024-09-09
1.1.*	Eatoni	2025-02-05
1.2.*	Histrionicus	2025-05-21
1.3.*	Ossivalis	2025-09-16
1.4.* LTS	Andium	2026-09-16

Neue Features

Datenbankverschlüsselung

DuckDB-Datenbankdateien verschlüsseln zu können war ein langjähriger Feature-Wunsch. Ab diesem Release unterstützt DuckDB die Verschlüsselung seiner Dateien. Verschlüsselungsschlüssel werden über den Parameter ENCRYPTION_KEY an ATTACH übergeben, so:

ATTACH 'encrypted.db' AS enc_db (ENCRYPTION_KEY 'quack_quack');

DuckDB nutzt die branchenübliche AES-Verschlüsselung mit 256 Bit Schlüssellänge im empfohlenen GCM-Modus als Standard.

Die Verschlüsselung umfasst die Hauptdatenbankdatei, die Write-Ahead-Log-(WAL-)Datei und sogar temporäre Dateien. Zum Verschlüsseln kann DuckDB entweder die eingebaute mbedtls-Bibliothek oder die OpenSSL-Bibliothek aus der httpfs-Erweiterung nutzen. Hinweis: Die OpenSSL-Varianten sind durch Hardware-Beschleunigung deutlich schneller, also unbedingt LOAD httpfs für gute Verschlüsselungsperformance.

Die Verschlüsselungsunterstützung in DuckDB wurde von Lotte Felius (@ccfelius) umgesetzt.

`MERGE`-Anweisung

DuckDB unterstützt jetzt MERGE INTO als Alternative zu INSERT INTO ... ON CONFLICT. MERGE INTO braucht keinen Primärschlüssel, weil es auf jeder benutzerdefinierten Merge-Bedingung arbeitet. Das ist eine sehr gängige Anweisung in OLAP-Systemen, die keine Primärschlüssel unterstützen, aber trotzdem Upserting (also UPDATE plus INSERT) anbieten wollen.

In diesem Beispiel nutzen wir eine einfache Bedingung, die auf einem Schlüssel matcht, und rufen die RETURNING-Anweisung auf, um eine Zusammenfassung der aktualisierten und eingefügten Zeilen zu bekommen.

CREATE TABLE Stock(item_id INTEGER, balance INTEGER);
INSERT INTO Stock VALUES (10, 2200), (20, 1900);

WITH new_stocks(item_id, volume) AS (VALUES (20, 2200), (30, 1900))
    MERGE INTO Stock
        USING new_stocks USING (item_id)
    WHEN MATCHED
        THEN UPDATE SET balance = balance + volume
    WHEN NOT MATCHED
        THEN INSERT VALUES (new_stocks.item_id, new_stocks.volume)
    RETURNING merge_action, *;

┌──────────────┬─────────┬─────────┐
│ merge_action │ item_id │ balance │
│   varchar    │  int32  │  int32  │
├──────────────┼─────────┼─────────┤
│ UPDATE       │      20 │    4100 │
│ INSERT       │      30 │    1900 │
└──────────────┴─────────┴─────────┘

MERGE INTO unterstützt auch komplexere Bedingungen und DELETE-Anweisungen.

WITH deletes(item_id, delete_threshold) AS (VALUES (10, 3000))
    MERGE INTO Stock
        USING deletes USING (item_id)
    WHEN MATCHED AND balance < delete_threshold
        THEN DELETE
    RETURNING merge_action, *;

┌──────────────┬─────────┬─────────┐
│ merge_action │ item_id │ balance │
│   varchar    │  int32  │  int32  │
├──────────────┼─────────┼─────────┤
│ DELETE       │   10    │  2200   │
└──────────────┴─────────┴─────────┘

Iceberg-Writes

Die duckdb-iceberg-Erweiterung unterstützt jetzt das Schreiben nach Iceberg.

Klicken Sie, um das Code-Snippet für Iceberg-Writes zu sehen.

```sql -- Having setup an Iceberg REST catalog using -- https://github.com/duckdb/duckdb-iceberg/blob/main/scripts/start-rest-catalog.sh INSTALL iceberg; LOAD iceberg; ATTACH '' AS iceberg_datalake ( TYPE iceberg, CLIENT_ID 'admin', CLIENT_SECRET 'password', ENDPOINT 'http://127.0.0.1:8181' ); CREATE SECRET ( TYPE S3, KEY_ID 'admin', SECRET 'password', ENDPOINT '127.0.0.1:9000', URL_STYLE 'path', USE_SSL false ); USE iceberg_datalake.default; ATTACH 'duckdb.db' AS duckdb_db; CREATE TABLE duckdb_db.t AS SELECT a FROM range(4) t(a); CREATE TABLE t AS SELECT * FROM duckdb_db.t; FROM iceberg_datalake.default.t; ```

┌───────┐
│   a   │
│ int64 │
├───────┤
│     0 │
│     1 │
│     2 │
│     3 │
└───────┘

Das heißt, das Kopieren von Daten von DuckDB oder DuckLake nach Iceberg ist jetzt möglich.

Kopieren von Iceberg nach DuckDB/DuckLake wird ebenfalls über die COPY-Anweisung unterstützt:
```
COPY FROM DATABASE iceberg_datalake TO duckdb_db;
```
Kopieren von DuckLake/DuckDB nach Iceberg braucht die manuelle Erstellung der Schemas auf der Iceberg-Seite:
```
CREATE SCHEMA iceberg_datalake.main;
COPY FROM DATABASE duckdb_db TO iceberg_datalake;
```

CLI-Fortschrittsbalken mit ETA

Community-Mitglied Rusty Conover (@rustyconover) hat eine ETA-(Estimated-Time-of-Arrival-)Funktion für den DuckDB-Kommandozeilen-Client beigetragen. Die verbleibende Zeit zu schätzen ist ein schwieriges Problem, weil Fortschrittsmessungen durch Rauschen stark schwanken können. Um das zu mildern, sammelt das ETA-Feature zuerst einige initiale Performance-Daten und verfeinert die Schätzung dann mit einem Kalman-Filter. So sieht es in der Praxis aus:

`FILL`-Window-Funktion

Richard (@hawkfish) hat eine neue Window-Funktion gebaut, FILL, mit der sich fehlende Werte in geordneten Windows interpolieren lassen. Hier ein Beispiel: Zwischen 1 und 42 fehlt ein Wert, im Ergebnis wird er zu 21 interpoliert.

FROM (VALUES (1, 1), (2, NULL), (3, 42)) t(c1, c2)
SELECT fill(c2) OVER (ORDER BY c1) f;

Das wird das Ergebnis sein:

f
1
21
42

Teradata-Connector

DuckDB hat jetzt einen Teradata-Connector. Ein eigener Blogbeitrag folgt.

Performance und Optimierungen

DuckDB v1.4.0 hat eine Reihe von Performance-Optimierungen erhalten.

Checkpointing von In-Memory-Tabellen

In-Memory-Tabellen unterstützen jetzt Checkpointing. Das hat zwei zentrale Vorteile:

In-Memory-Tabellen unterstützen jetzt Kompression, was für manche Abfragen einen deutlichen (5–10×) Performance-Schub bringen kann. Das ist standardmäßig deaktiviert – Sie können es so einschalten:
```
ATTACH ':memory:' AS memory_compressed (COMPRESS);
USE memory_compressed;
```
Checkpointing löst das Vacuuming gelöschter Zeilen aus und gibt nach Deletes/Truncation Platz frei.

Sortier-Rework

Laurens (@lnkuiper) hat DuckDBs Sortierimplementierung neu geschrieben (schon wieder). Diese neue Implementierung nutzt einen k-Wege-Merge-Sort, um Datenbewegung zu reduzieren. Sie ist außerdem adaptiv gegenüber vorsortierten Daten und nutzt eine neue API, mit der dieser neue Sortiercode an anderen Stellen in DuckDB genutzt werden kann, zum Beispiel in Window-Funktionen. Wir sehen deutlich bessere Thread-Scaling-Performance mit dieser Implementierung. Wir werden einen eigenen Blogbeitrag mit detaillierteren Performance-Messungen veröffentlichen.

Update: Wir haben das jetzt in einem eigenen Blogbeitrag behandelt.

Materialisieren von Common Table Expressions

Common Table Expressions (CTEs) werden jetzt standardmäßig materialisiert (statt sie zu inlinen). Das verbessert sowohl die Performance als auch einige Korrektheitsbugs, die durch Inlining entstanden. Dieses Feature wurde von Denis Hirn (kryonix) umgesetzt, der 2020 Unterstützung für rekursive CTEs beigetragen hat.

Weitere Optimierungen

DuckDB v1.4.0 behebt einige Scaling-Issues, unterstützt Caching für Hashes von String-Dictionaries und hat mehrere Aggregations-Optimierungen.

Distribution

macOS-Notarisierung

macOS hat ein ziemlich fortschrittliches Modell zur Sicherung der Systemintegrität, aufgebaut um kryptografische Signaturen zusammen mit sogenannter „Notarisierung“ durch Apple. Wir signieren unsere Binaries schon seit etwa zwei Jahren. Ab diesem Release werden das DuckDB-Kommandozeilen-Utility (duckdb) und die dynamische Bibliothek libduckdb...sdylib mit dieser Notarisierung veröffentlicht. Das reduziert die Beschwerden, wenn Webbrowser unsere Binaries herunterladen. Leider unterstützt macOS die Notarisierung von Kommandozeilen-Utilities noch nicht vollständig, der Use Case „mit Doppelklick öffnen“ muss also noch warten. Der empfohlene Weg, die CLI auf macOS zu installieren, bleibt unser Install-Skript:

curl https://install.duckdb.org | bash

Python-Integration in ein eigenes Repository verschoben

Wir haben Sprachintegrationen („Clients“) langsam aus duckdb/duckdb in eigene Repositories verschoben. Für dieses Release haben wir den Python-Client in sein eigenes Repository verschoben, duckdb/duckdb-python. Bitte melden Sie Issues zum Python-Client dort.

Schlussgedanken

Das waren ein paar Highlights – aber es gibt viele weitere Features und Verbesserungen in diesem Release. Seit v1.3.2 gab es über 3.500 Commits von über 90 Mitwirkenden. Die vollständigen Release Notes finden Sie auf GitHub. Wir danken unserer Community für detaillierte Issue-Berichte und Feedback. Und unser besonderer Dank gilt den externen Mitwirkenden, die Features direkt in diesem Release gelandet haben!