2026-03-09

Ankündigung: DuckDB 1.5.0

The DuckDB team

Wir sind stolz, DuckDB v1.5.0 zu veröffentlichen, benannt „Variegata“ nach der Paradieskasarka (Tadorna variegata), die in Neuseeland endemisch ist.

In diesem Blogbeitrag behandeln wir die wichtigsten Updates dieses Releases rund um Support, Features und Extensions. Wie immer gibt es mehr: 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 Extensions (z. B. die UI) und Client-Bibliotheken (z. B. Go, R, Java) erscheinen, wegen der zusätzlichen Änderungen und Review-Runden.

Mit diesem Release haben wir zwei DuckDB-Releases verfügbar: v1.4 (LTS) und v1.5 (aktuell). Das nächste Release – geplant für September – wird eine Major-Version ausliefern, DuckDB v2.0.

Neue Features

Command-Line-Client

Für Nutzer, die DuckDB über das Terminal nutzen, ist das Highlight des neuen Releases eine Überarbeitung des CLI-Clients mit einem neuen Farbschema, dynamischen Prompts, einem Pager und vielen weiteren Komfort-Features.

Farbschema

Wir haben eine neue Farbpalette ausgeliefert und sie mit der Dokumentation harmonisiert. Die Farbpalette ist im Dark Mode und im Light Mode verfügbar. Beide nutzen zwei Grautöne und fünf Farben für Keywords, Strings, Fehler, Funktionen und Zahlen. Die Palette nutzt zwei Grautöne plus fünf Farben für Keywords, Strings, Fehler, Funktionen und Zahlen.

Sie können das Farbschema mit dem Dot-Command .highlight_colors anpassen:

.highlight_colors column_name darkgreen bold_underline
.highlight_colors numeric_value red bold
.highlight_colors string_value purple2
FROM ducks;

Dynamische Prompts in der CLI

DuckDB v1.5.0 führt dynamische Prompts für die CLI ein (PR #19579). Standardmäßig zeigen sie die Datenbank und das Schema, mit dem Sie gerade verbunden sind:

duckdb

«memory» D ATTACH 'my_database.duckdb';
«memory» D USE my_database;
«my_database» D CREATE SCHEMA my_schema;
«my_database» D USE my_schema;
«my_database.my_schema» D ...

Diese Prompts lassen sich mit Bracket-Codes konfigurieren, um eine maximale Länge zu haben, eine eigene Query auszuführen, andere Farben zu nutzen usw. (#19579).

.tables und DESCRIBE

Um die Spalten einer einzelnen Tabelle zu zeigen, nutzen Sie die Anweisung DESCRIBE:

«memory» D ATTACH 'https://blobs.duckdb.org/data/animals.db' AS animals_db;
«memory» D USE animals_db;
«animals_db» D DESCRIBE ducks;

┌──────────────────────┐
│        ducks         │
│                      │
│ id           integer │
│ name         varchar │
│ extinct_year integer │
└──────────────────────┘

Das Dot-Command .tables listet die attached Catalogs, die Schemas und Tabellen darin sowie die Spalten jeder Tabelle.

«memory» D ATTACH 'https://blobs.duckdb.org/data/animals.db' AS animals_db;
«memory» D ATTACH 'https://blobs.duckdb.org/data/numbers1.db';
«memory» D .tables

 ────────────── animals_db ───────────────
 ───────────────── main ──────────────────
┌─────────────────┐┌──────────────────────┐
│      swans      ││        ducks         │
│                 ││                      │
│ id      integer ││ id           integer │
│ name    varchar ││ name         varchar │
│ species varchar ││ extinct_year integer │
│ color   varchar ││                      │
│ habitat varchar ││        5 rows        │
│                 │└──────────────────────┘
│     3 rows      │
└─────────────────┘
  numbers1
 ── main ──
┌──────────┐
│   tbl    │
│          │
│ i bigint │
│          │
│  2 rows  │
└──────────┘

Zugriff auf das letzte Ergebnis mit _

Sie können auf das letzte Ergebnis einer Query inline mit dem Unterstrich _ zugreifen. Das ist nicht nur praktisch, sondern macht es auch unnötig, potenziell lang laufende Queries erneut auszuführen:

«memory» D ATTACH 'https://blobs.duckdb.org/data/animals.db' AS animals_db;
«memory» D USE animals_db;
«animals_db» D FROM ducks WHERE extinct_year IS NOT NULL;
┌───────┬──────────────────┬──────────────┐
│  id   │       name       │ extinct_year │
│ int32 │     varchar      │    int32     │
├───────┼──────────────────┼──────────────┤
│     1 │ Labrador Duck    │         1878 │
│     3 │ Crested Shelduck │         1964 │
│     5 │ Pink-headed Duck │         1949 │
└───────┴──────────────────┴──────────────┘
«animals_db» D FROM _;
┌───────┬──────────────────┬──────────────┐
│  id   │       name       │ extinct_year │
│ int32 │     varchar      │    int32     │
├───────┼──────────────────┼──────────────┤
│     1 │ Labrador Duck    │         1878 │
│     3 │ Crested Shelduck │         1964 │
│     5 │ Pink-headed Duck │         1949 │
└───────┴──────────────────┴──────────────┘

Pager

Last but not least hat die CLI jetzt einen Pager! Er wird ausgelöst, wenn mehr als 50 Zeilen in den Ergebnissen sind.

«memory» D .maxrows 100
«memory» D FROM range(0, 100);

Sie können unter Linux und Windows mit Page Up / Page Down navigieren. Unter macOS nutzen Sie Fn + Up / Down. Um den Pager zu verlassen, drücken Sie Q.

Die initiale Implementierung des Pagers wurde von tobwen in #19004 bereitgestellt.

PEG-Parser

DuckDB v1.5 bringt einen experimentellen Parser auf Basis von PEG (Parser Expression Grammars). Der neue Parser ermöglicht bessere Vorschläge, verbesserte Fehlermeldungen und erlaubt Extensions, die Grammatik zu erweitern. Der PEG-Parser ist derzeit standardmäßig deaktiviert, Sie können ihn aber so aktivieren:

CALL enable_peg_parser();

Der PEG-Parser wird bereits für das Erzeugen von Vorschlägen genutzt. Sie können mit TAB durch die Optionen cyclen.

«animals_db» D FROM ducks WHERE habitat IS
IS           ISNULL       ILIKE        ⌊IN⌋           INTERSECT    LIKE

Wir planen, im kommenden DuckDB-Release auf den neuen Parser umzuschalten.

Als Trade-off hat der Parser einen leichten Performance-Overhead, der liegt aber im Bereich von Millisekunden und ist für analytische Queries vernachlässigbar. Mehr Details zur Begründung für einen PEG-Parser und Benchmark-Ergebnisse stehen im CIDR-2026-Paper von Hannes und Mark oder in ihrem Blogbeitrag, der das Paper zusammenfasst.

Typ VARIANT

DuckDB unterstützt jetzt nativ den VARIANT-Typ, inspiriert von Snowflakes semistrukturiertem Datentyp VARIANT und seit 2025 in Parquet verfügbar. Anders als der JSON-Typ, der physisch als Text gespeichert wird, speichert VARIANT getypte Binärdaten. Jede Zeile in einer VARIANT-Spalte ist selbstständig mit eigenen Typinformationen. Das führt zu besserer Kompression und Query-Performance. Hier ein paar Beispiele zur Nutzung von VARIANT.

Unterschiedliche Typen in derselben Spalte speichern:

CREATE TABLE events (id INTEGER, data VARIANT);
INSERT INTO events VALUES
    (1, 42::VARIANT),
    (2, 'hello world'::VARIANT),
    (3, [1, 2, 3]::VARIANT),
    (4, {'name': 'Alice', 'age': 30}::VARIANT);

SELECT * FROM events;

┌───────┬────────────────────────────┐
│  id   │            data            │
│ int32 │          variant           │
├───────┼────────────────────────────┤
│     1 │ 42                         │
│     2 │ hello world                │
│     3 │ [1, 2, 3]                  │
│     4 │ {'name': Alice, 'age': 30} │
└───────┴────────────────────────────┘

Den zugrunde liegenden Typ jeder Zeile prüfen:

SELECT id, data, variant_typeof(data) AS vtype
FROM events;

┌───────┬────────────────────────────┬───────────────────┐
│  id   │            data            │       vtype       │
│ int32 │          variant           │      varchar      │
├───────┼────────────────────────────┼───────────────────┤
│     1 │ 42                         │ INT32             │
│     2 │ hello world                │ VARCHAR           │
│     3 │ [1, 2, 3]                  │ ARRAY(3)          │
│     4 │ {'name': Alice, 'age': 30} │ OBJECT(name, age) │
└───────┴────────────────────────────┴───────────────────┘

Sie können Felder aus verschachtelten Variants mit der Dot-Notation oder der Funktion variant_extract extrahieren:

SELECT data.name FROM events WHERE id = 4;
-- or
SELECT variant_extract(data, 'name') AS name FROM events WHERE id = 4;

┌─────────┐
│  name   │
│ variant │
├─────────┤
│ Alice   │
└─────────┘

DuckDB unterstützt auch das Lesen von VARIANT-Typen aus Parquet-Dateien, einschließlich Shredding (Speichern verschachtelter Daten als flache Werte).

Funktion read_duckdb

Die Tabellenfunktion read_duckdb kann DuckDB-Datenbanken lesen, ohne sie zuerst zu attachen. Das kann das Lesen aus DuckDB-Datenbanken ergonomischer machen – zum Beispiel können Sie Globbing nutzen. Sie können die Beispiel-numbers-Datenbanken so lesen:

SELECT min(i), max(i)
FROM read_duckdb('numbers*.db');

┌────────┬────────┐
│ min(i) │ max(i) │
│ int64  │ int64  │
├────────┼────────┤
│      1 │      5 │
└────────┴────────┘

Azure Writes

Sie können jetzt auf Azure Blob oder ADLSv2 Storage schreiben mit der Anweisung COPY:

-- Write query results to a Parquet file on Blob Storage
COPY (SELECT * FROM my_table)
TO 'az://my_container/path/output.parquet';

-- Write a table to a CSV file on ADLSv2 Storage
COPY my_table
TO 'abfss://my_container/path/output.csv';

ODBC Scanner

Wir liefern jetzt eine ODBC-Scanner-Extension aus. Damit können Sie einen Remote-Endpunkt so abfragen:

LOAD odbc_scanner;
SET VARIABLE conn = odbc_connect('Driver={Oracle Driver};DBQ=//127.0.0.1:1521/XE;UID=scott;PWD=tiger;');
SELECT * FROM odbc_query(getvariable('conn'), 'SELECT SYSTIMESTAMP FROM dual;');

In den kommenden Wochen veröffentlichen wir die Dokumentationsseite und einen Folgebeitrag zum ODBC Scanner. In der Zwischenzeit verweisen wir auf das README des Projekts.

Wichtige Änderungen

Breaking Change für Datetime-Funktion

Die Funktion date_trunc gibt, angewendet auf ein DATE, jetzt ein TIMESTAMP statt eines Date zurück.

-- v1.4.4:
SELECT typeof(date_trunc('month', DATE('2026-03-27')));
-- returns DATE

-- v1.5.x:
SELECT typeof(date_trunc('month', DATE('2026-03-27')));
-- returns TIMESTAMP

Lakehouse-Updates

Alle von DuckDB unterstützten Lakehouse-Formate haben in DuckDB v1.5 Updates erhalten.

DuckLake

Die wichtigste DuckLake-Änderung für DuckDB v1.5 ist das Update der DuckLake-Spezifikation auf v0.4. Wir streben an, dass das dieselbe Spezifikation ist, die mit DuckLake v1.0 ausgeliefert wird, das im April erscheint. Die wichtigsten Highlights:

• Macro-Unterstützung.
• Sortierte Tabellen.
• Deletion Inlining und Hinzufügen partieller Delete-Dateien.
• Interne Überarbeitung der DuckLake-Optionen.

Mehr Details zu diesen Features kündigen wir im Blogbeitrag zu DuckLake v1.0 an.

Delta Lake

Für die Delta-Lake-Extension hat sich das Team auf bessere Write-Unterstützung über Unity Catalog, Delta-idempotente Writes und Tabellen-CHECKPOINTs konzentriert.

Iceberg

Für die Iceberg-Extension arbeitet das Team an einem größeren Release für v1.5.1. Für v1.5.0 ist das Hauptfeature das Hinzufügen von Table Properties in der Anweisung CREATE TABLE:

CREATE TABLE test_create_table (a INTEGER)
WITH (
    'format-version' = '2', -- format version will be elevated to format-version when creating a table
    'location' = 's3://path/to/data', -- location will be elevated to location when creating a table
    'property1' = 'value1',
    'property2' = 'value2'
);

Weitere kleinere Ergänzungen wurden vorgenommen, um EXTRA_HTTP_HEADERS beim Attachen an einen Iceberg Catalog zu übergeben, was Googles BigLake freigeschaltet hat.

Sowohl Delta als auch DuckLake haben den VARIANT-Typ umgesetzt. Icebergs VARIANT-Typ kommt im Release v1.5.1 zusammen mit weiteren Features, die spezifisch für die Iceberg-v3-Spezifikation sind.

Network Stack

Das Standard-Backend für die httpfs-Extension hat von httplib auf curl gewechselt. Als eines der beliebtesten und am besten getesteten Open-Source-Projekte erwarten wir, dass curl DuckDB langfristige Stabilität und Sicherheit bietet. Unabhängig von der genutzten http-Bibliothek bleibt openssl die hinterlegte SSL-Bibliothek, und Optionen wie http_timeout, http_retries usw. bleiben dieselben.

Unsere Community hat den neuen Network Stack in den letzten Wochen getestet. Wenn Sie trotzdem auf Probleme stoßen, bitte im duckdb-httpfs-Repository einreichen.

Lambda-Syntax

Bis DuckDB v1.2 nutzte die Syntax für Lambda-Ausdrücke die Arrow-Notation x -> x + 1. Das war eine schöne Syntax, kollidierte aber mit dem JSON-Extract-Operator (->) wegen Operator-Precedence und führte zu Fehlermeldungen, die manche Nutzer schwer zu debuggen fanden. Als Workaround haben wir eine neue, Python-artige Lambda-Syntax in v1.3 eingeführt, lambda x: x + 1.

DuckDB v1.5 unterstützt beide Stile, das Schreiben von Lambda-Ausdrücken mit der deprecated Arrow-Syntax wirft jetzt aber eine Warnung:

SELECT list_transform([1, 2, 3], x -> x + 1);

WARNING:
Deprecated lambda arrow (->) detected. Please transition to the new lambda syntax, i.e., lambda x, i: x + i, before DuckDB's next release.

Sie können die Konfigurationsoption lambda_syntax nutzen, um dieses Verhalten zu ändern und die Warnung zu unterdrücken oder strenger zu sein:

-- Suppress the warning
SET lambda_syntax = 'ENABLE_SINGLE_ARROW';
-- Turn the deprecation warning into an error
SET lambda_syntax = 'DISABLE_SINGLE_ARROW';

DuckDB 2.0 wird die Single-Arrow-Syntax standardmäßig deaktivieren; sie ist dann nur noch verfügbar, wenn Sie explizit opt-in.

Spatial Extension

Die spatial-Extension bringt mehrere wichtige Änderungen.

Breaking Change: Umkehrung der Achsenreihenfolge

Die meisten Funktionen in spatial arbeiten im kartesischen Raum und sind von der Achsenreihenfolge unbeeinflusst, z. B. ob die Achsen X und Y „Longitude“ und „Latitude“ darstellen oder umgekehrt. Es gibt aber einige Funktionen, bei denen das eine Rolle spielt, und bei denen die Annahme – kontraintuitiv – ist, dass alle Eingabegeometrien (x = Latitude, y = Longitude) nutzen. Das sind:

• ST_Distance_Spheroid
• ST_Perimeter_Spheroid
• ST_Area_Spheroid
• ST_Distance_Sphere
• ST_DWithin_Spheroid

Zusätzlich erwartet ST_Transform auch, dass die Eingabegeometrien in derselben Achsenreihenfolge liegen, wie sie das Quell-Koordinatensystem definiert, was im Fall von z. B. EPSG:4326 ebenfalls (x = Latitude, y = Longitude) ist.

Das war eine langjährige Quelle von Verwirrung und zahlreichen Issues, weil andere Datenbanken, Formate und GIS-Systeme X tendenziell immer als „Easting“, „links-rechts“ oder „Longitude“ und Y als „Northing“, „oben-unten“ oder „Latitude“ behandeln.

Wir ändern, wie das derzeit in DuckDB funktioniert, um konsistent mit anderen Systemen zu sein und hoffentlich weniger Verwirrung für neue Nutzer zu stiften. Um bestehende Workflows, die sich an diese Eigenheit angepasst haben (z. B. mit ST_FlipCoordinates), nicht still zu brechen, rollen wir diese Änderung schrittweise über eine neue Einstellung geometry_always_xy aus:

• In DuckDB v1.5 aktiviert geometry_always_xy = true das neue Verhalten (x = Longitude, y = Latitude). Ohne die Einstellung geben betroffene Funktionen eine Warnung aus.
• In DuckDB v2.0 wird die Warnung zu einem Fehler. Setzen Sie geometry_always_xy = false, um das alte Verhalten zu behalten.
• In DuckDB v2.1 wird geometry_always_xy = true der Standard.

Zusammengefasst ändert sich in diesem Release standardmäßig nichts, aber um von dieser Änderung in Zukunft nicht betroffen zu sein, setzen Sie geometry_always_xy jetzt explizit. Setzen Sie es auf true, um ins neue Verhalten zu opten, oder auf false, um das bestehende zu behalten.

Geometry-Überarbeitung

GEOMETRY wird ein Built-in-Typ

Der Typ GEOMETRY ist von der spatial-Extension ins DuckDB-Core gewandert!

Geospatial-Daten sind nicht mehr Nische. Der Parquet-Standard behandelt GEOMETRY jetzt als First-Class-Spaltentyp, und Open Table Formats wie Apache Iceberg und DuckLake bewegen sich in dieselbe Richtung. Viele weit genutzte Datenformate und Systeme haben auch geospatiale Pendants – GeoJSON, PostGIS, GeoPandas, GeoPackage/Spatialite und mehr.

DuckDB bietet bereits Extensions, die mit vielen dieser Formate und Systeme integrieren. Es gibt aber ein strukturelles Problem: Solange GEOMETRY in der spatial-Extension lebt, müssen andere Extensions, die geospatiale Daten lesen oder schreiben wollen, entweder von spatial abhängen, eine eigene inkompatible Geometry-Darstellung umsetzen oder Nutzer zwingen, die Konvertierungen selbst zu machen.

Indem GEOMETRY ins DuckDB-Core wandert, können Extensions jetzt Geometry-Werte nativ erzeugen und konsumieren, ohne von spatial abzuhängen. Die spatial-Extension liefert weiterhin die meisten Funktionen für die Arbeit mit Geometrien, der Typ selbst wird aber zu einem gemeinsamen Fundament, auf dem das gesamte Ökosystem aufbauen kann. Wir haben bereits GEOMETRY-Unterstützung zum Postgres Scanner und GeoArrow-Konvertierung für Arrow-Import und -Export hinzugefügt. Geometry-Unterstützung in weiteren Extensions kommt bald.

Diese Änderung ermöglicht auch eine tiefere Integration mit DuckDBs Storage Engine und Query Optimizer und schaltet neue Kompressionstechniken, Query-Optimierungen und CRS-Awareness frei, die nicht möglich waren, als GEOMETRY nur als Extension-Typ existierte. Das alles ist auf der neuen Geometry-Seite in der Dokumentation festgehalten, unten heben wir einiges hervor.

Verbesserter Storage: WKB und Shredding

Geometry-Werte werden jetzt im industrieüblichen Little-Endian-Well-Known-Binary-(WKB-)Encoding gespeichert und ersetzen das Custom-Format der spatial-Extension. Wir experimentieren aber noch mit der In-Memory-Darstellung, die wir in der Execution Engine nutzen wollen, Sie sollten also weiterhin die Konvertierungsfunktionen (z. B. ST_AsWKT, ST_AsWKB, ST_GeomFromText, ST_GeomFromWKB) nutzen, wenn Sie Daten in DuckDB hinein- oder herausbewegen.

Wir haben auch eine neue, für GEOMETRY spezialisierte Storage-Technik umgesetzt. Wenn eine Geometry-Spalte Werte enthält, die alle denselben Typ und dieselben Vertex-Dimensionen teilen, kann DuckDB zusätzlich „Shredding“ anwenden: Statt undurchsichtiger Blobs wird die Spalte in primitive STRUCT-, LIST- und DOUBLE-Segmente zerlegt, die sich deutlich effizienter komprimieren. Das kann die On-Disk-Größe für uniforme Geometry-Spalten wie Point Clouds um etwa 3× reduzieren. Shredding wird automatisch für uniforme Row Groups einer bestimmten Größe angewendet, lässt sich aber über die Konfigurationsoption geometry_minimum_shredding_size konfigurieren.

Geometry-Statistiken und Query-Optimierung

Geometry-Spalten tracken jetzt Statistiken pro Row Group – einschließlich der Bounding Box und der Menge der vorhandenen Geometry-Typen und Vertex-Dimensionen. Der Query Optimizer kann das nutzen, um Row Groups zu überspringen, die die Spatial-Prädikate einer Query nicht matchen können, ähnlich wie Min/Max-Pruning für numerische Spalten. Der Operator && (Bounding-Box-Intersection) ist der erste Nutznießer; breitere Unterstützung über spatial-Funktionen ist in Arbeit.

Unterstützung für Koordinatenreferenzsysteme

Der Typ GEOMETRY akzeptiert jetzt einen optionalen CRS-Parameter (z. B. GEOMETRY('OGC:CRS84')) und macht CRS zum Teil des Typsystems statt impliziter Metadaten. Spatial-Funktionen erzwingen CRS-Konsistenz über ihre Eingaben und fangen eine häufige Klasse stiller Fehler, die entsteht, wenn Geometrien aus unterschiedlichen Koordinatensystemen gemischt werden. Nur ein paar CRS sind standardmäßig eingebaut, das Laden der spatial-Extension registriert aber über 7.000 CRS aus dem EPSG-Datensatz. Die CRS-Unterstützung ist noch etwas experimentell, wir planen aber, sie weiterzuentwickeln, um z. B. eigene CRS-Definitionen zu unterstützen.

Optimierungen

Non-Blocking Checkpointing

Beim Checkpointing ist es jetzt möglich, parallele Reads (#19867), Writes (#20052), Inserts mit Indizes (#20160) und Deletes (#20286) auszuführen. Die Überarbeitung des Checkpointings kommt parallelen RW-Workloads zugute und erhöht den TPC-H-Throughput-Score auf SF100 von 246.115,60 auf 287.122,97, eine 17%-Verbesserung.

Aggregates

Aggregate-Funktionen haben mehrere Optimierungen erhalten. Zum Beispiel wurde die Aggregate-Funktion last vom Community-Mitglied xe-nvdk so optimiert, dass sie vom Ende jedes Vector-Batchs statt vom Anfang iteriert. In synthetischen Benchmarks ergibt das einen 40%-Speedup.

Distribution

Python Pip

Sie können die DuckDB-CLI auf jeder Plattform installieren, auf der pip verfügbar ist:

pip install duckdb-cli

Dann können Sie DuckDB in Ihrer virtuellen Umgebung so starten:

duckdb

Sowohl DuckDB v1.4 als auch v1.5 werden unterstützt. Wir arbeiten daran, Extensions als Extras mit der Syntax duckdb[extension_name] auszuliefern – stay tuned!

Windows-Install-Skript (Beta)

Unter Windows können Sie jetzt ein Install-Skript nutzen:

powershell -NoExit iex (iwr "https://install.duckdb.org/install.ps1").Content

Bitte beachten Sie, dass das derzeit im Beta-Stadium ist. Feedback gern an uns.

CLI für Linux mit musl libc

Wir verteilen CLI-Clients, die mit musl libc funktionieren (z. B. für Alpine Linux, häufig in Docker-Images genutzt). Die Archive stehen auf GitHub.

Hinweis: Der musl-libc-CLI-Client braucht libstdc++. Um dieses Paket zu installieren, führen Sie aus:

apk add libstdc++

Extension-Größen

Wir haben unser Build-System überarbeitet, um die Extension-Binaries kleiner zu machen! Die Größe der DuckLake-Extension wurde um etwa 30 % reduziert, von 17 MB auf 12 MB. Bei kleineren Extensions wie Excel liegt die Reduktion bei über 60 %, von 9 MB auf 3 MB.

Zusammenfassung

Das waren ein paar Highlights – aber es gibt viele weitere Features und Verbesserungen in diesem Release. Seit v1.4 gab es über 6500 Commits von knapp 100 Contributors. Die vollständigen Release Notes finden Sie auf GitHub. Wir danken unserer Community für detaillierte Issue-Reports und Feedback. Und wieder gilt unser besonderer Dank den externen Contributors!

PS: Wenn Sie diesen Blogbeitrag über einen direkten Link erreicht haben – wir haben auch eine neue Landing Page ausgerollt!

Anhang: Beispieldatensatz

</details>