DuckDB oder SQLite: Index und Vollscan entscheiden

Für lokale Transaktionen und gezielte Abfragen über einen passenden Index ist SQLite meist die bessere Wahl. DuckDB spielt seine Stärken aus, wenn Abfragen große Teile eines Datenbestands lesen und auswerten. Ein veröffentlichter Vergleich einfacher Abfragen zeigt, wie deutlich sich das Ergebnis mit dem Zugriffsmuster ändern kann.

Bei der Auswahl zählen außerdem die Schreiblast und die Herkunft der Daten. Eine Anwendung, die laufend einzelne Datensätze ändert, braucht ein anderes Betriebsmodell als ein Analyseprozess für CSV- und Parquet-Dateien. Besonders wichtig ist, ob mehrere Prozesse dieselbe Datenbankdatei beschreiben sollen.

Warum Index und Vollscan verschiedene Stärken verlangen

Ein Index hilft bei einer selektiven Abfrage, die nur wenige passende Zeilen sucht: Die Datenbank kann die gesuchten Einträge finden, ohne die ganze Tabelle zu durchlaufen. Ein Vollscan liest dagegen viele Zeilen. Das ist etwa nötig, wenn eine Auswertung einen großen Teil der Daten berücksichtigt oder für die Suchbedingung kein geeigneter Index vorhanden ist.

DuckDB ist auf solche analytischen Lasten ausgelegt. Die DuckDB-Projektbeschreibung nennt Aggregationen über große Tabellen und eine spaltenorientierte, vektorisierte Ausführung, die Werte blockweise verarbeitet. DuckDB unterstützt auch sekundäre Indizes für die Suche nach einzelnen Einträgen. Dass ein Index existiert, macht eine konkrete Punktabfrage aber noch nicht ebenso schnell wie in SQLite.

Die Dateigröße allein entscheidet deshalb wenig. Eine große Tabelle kann für eine Suche nach einem Schlüssel gut beherrschbar sein, wenn der Zugriff selektiv ist und ein passender Index greift. Umgekehrt kann schon eine einfache Abfrage teuer werden, wenn sie ohne Index wiederholt viele Zeilen lesen muss. Für die Wahl der Datenbank ist die häufige und für die Anwendung wichtige Abfrage aussagekräftiger als ein pauschaler Vergleich von OLTP und OLAP.

Was der GTFS-Benchmark misst

GTFS-Fahrten im deutschen Nahverkehr verdeutlichen den Unterschied zwischen gezielter Suche und breitem Scan im Vergleich von SQLite und DuckDB.

Im GTFS-Test von Lukas Barth aus dem November 2023 mit SQLite 3.41.2 und DuckDB 0.9.1 dauerte die indizierte Suche nach einer Fahrt im Mittel 0,063 Millisekunden mit SQLite und 0,927 Millisekunden mit DuckDB; bei der unindizierten Suche nach Fahrten einer Route waren es 182 beziehungsweise 7,70 Millisekunden. Für die erste Aufgabe lag SQLite vorne, für die zweite DuckDB.

Der Test verwendete Fahrten und Haltezeiten des deutschen öffentlichen Verkehrs. SQLite erhielt vorbereitete Tabellen mit Schlüsseln und Indizes; DuckDB las CSV-Daten ein und bekam anschließend ebenfalls Indizes. Vor der Zeitmessung wurde jede Abfrageserie zum Aufwärmen der Caches ausgeführt. Gemessen wurden einfache Abfragen auf einem Laptop, keine allgemeine Rangliste für sämtliche Datenbanklasten.

Die Unterscheidung ist entscheidend: Der schnelle DuckDB-Wert stammt aus einer Suche ohne Index, bei der viele Einträge geprüft werden mussten. Er ist kein gemessener Vorteil für jede Aggregation. Ebenso wenig belegt der SQLite-Wert, dass DuckDB grundsätzlich keine Indizes nutzen könnte. Die Resultate beschreiben die getesteten Abfragen, Daten, Versionen und Vorbereitungen; für andere Konfigurationen kann sich der Abstand ändern.

Wann lokale Transaktionen für SQLite sprechen

SQLite passt zu Anwendungen, die ihren veränderlichen Zustand lokal halten, einzelne Zeilen über Schlüssel finden und kleine Transaktionen abschließen. Dazu gehören Vorgänge wie das Anlegen eines Datensatzes, eine gezielte Änderung und das anschließende Wiederfinden. Indizes können die Lesezugriffe beschleunigen, während die Daten in einer Datei verfügbar bleiben.

Die SQLite-Empfehlungen für Einsatzfälle nennen zugleich die Schreibgrenze: Pro Datenbankdatei ist nur ein Schreiber gleichzeitig aktiv; weitere Schreiber müssen warten. Viele Leser können parallel zugreifen. Bei kurzen Schreibtransaktionen ist das Warten oft handhabbar, während lange oder häufige Schreibvorgänge die Warteschlange stärker belasten.

Wenn viele unabhängige Prozesse gleichzeitig schreiben müssen und sich die Vorgänge nicht sinnvoll nacheinander ausführen lassen, empfiehlt SQLite ein Client-Server-Datenbanksystem. Die Zahl der Anfragen allein reicht für diese Entscheidung nicht: Maßgeblich sind die Dauer der Transaktionen und die Wartezeit, die der Betrieb verträgt. SQLite bleibt außerdem für Auswertungen nutzbar, wenn Daten bereits dort liegen oder CSV-Daten einmalig importiert werden.

Was sich an der Prozessgrenze ändert

Bei einer nativen DuckDB-Datenbankdatei schreibt im eingebetteten Betrieb ein Prozess, während weitere Prozesse lesend zugreifen können.

Bei DuckDB ist zwischen Threads innerhalb eines Prozesses und eigenständigen Prozessen zu unterscheiden. Die DuckDB-Dokumentation zur Nebenläufigkeit erlaubt im eingebetteten Schreibbetrieb mehrere Schreib-Threads innerhalb eines Prozesses; mehrere Prozesse können dieselbe native Datenbankdatei nur dann lesend öffnen, wenn keiner schreibt. Versuchen Threads zugleich dieselbe Zeile zu ändern, kann ein Transaktionskonflikt entstehen.

Für einen Analyseprozess, der Daten lädt und Abfragen ausführt, ist diese Grenze häufig gut planbar. Schwieriger wird es, wenn mehrere eigenständige Dienste dieselbe native Datei dauerhaft verändern sollen. Ein zusätzlicher Koordinationsdienst oder ein anderes Datenmodell verändert dann die Architektur und gehört ausdrücklich zur Auswahl. Die Geschwindigkeit eines Vollscans löst diese Schreibfrage nicht.

SQLite und DuckDB setzen hier unterschiedliche Schwerpunkte. SQLite lässt Schreibzugriffe auf eine Datei nacheinander zu, auch wenn sie aus mehreren Prozessen kommen; DuckDB begrenzt den eingebetteten Schreibzugriff auf einen Prozess, erlaubt dort aber mehrere Threads. Wer „viele Schreiber“ sagt, muss daher klären, ob Threads eines Dienstes oder getrennte Prozesse gemeint sind.

Wie CSV und Parquet die Wahl beeinflussen

CSV- und Parquet-Daten stellen unterschiedliche Leseaufgaben dar; DuckDB kann für Parquet-Abfragen benötigte Spalten auswählen.

Liegen Daten schon als CSV- oder Parquet-Dateien vor, kann DuckDB sie für SQL-Abfragen direkt lesen. Die DuckDB-Hinweise zu Dateiformaten beschreiben direkte Parquet-Abfragen sowie das Einlesen von CSV-Dateien. Ein dauerhafter Import in eine eigene Datenbanktabelle ist damit nicht für jede Analyse erforderlich.

Parquet speichert Daten spaltenorientiert. DuckDB kann bei einer Abfrage nur die benötigten Spalten lesen und Filter in den Dateiscan schieben; ob sich dadurch weitere Dateibereiche überspringen lassen, hängt von den vorhandenen Statistiken und dem Aufbau der Datei ab. CSV bietet diese spaltenweise Struktur nicht und muss beim Lesen als Text verarbeitet werden. Ergebnisse einer Parquet-Abfrage lassen sich deshalb nicht ohne Weiteres auf dieselben Daten im CSV-Format übertragen.

Direkter Dateizugriff ist allerdings nicht immer die schnellste Lösung für wiederholte Abfragen. Das Laden in native DuckDB-Tabellen kostet zunächst Zeit und Speicherplatz, kann spätere Abfragen aber beschleunigen. SQLite kann CSV ebenfalls importieren und danach Indizes und Transaktionen auf den gespeicherten Daten nutzen. Ob der Import lohnt, hängt davon ab, wie oft dieselben Daten erneut abgefragt oder geändert werden.

Die Auswahl nach tatsächlicher Last

Die Entscheidung lässt sich nach vier getrennten Anforderungen treffen:

Indizierte Punktabfragen und kleine Änderungen: SQLite ist der naheliegende Ausgangspunkt für lokal gepflegte Anwendungsdaten.
Breite Scans und Aggregationen: DuckDB passt besser zu einer Last, bei der große Datenbereiche regelmäßig ausgewertet werden.
Konkurrierende Schreibzugriffe: Bei SQLite zählt die Wartezeit vor dem einzelnen Schreiber; bei DuckDB zählt zusätzlich, ob Schreibzugriffe aus getrennten Prozessen kommen.
CSV- und Parquet-Auswertung: DuckDB erlaubt direkte Abfragen. Bei wiederholter Nutzung gehören auch Ladezeit und spätere Abfragezeit in den Vergleich.

Eine gemischte Anwendung kann beide Aufgaben trennen: SQLite verwaltet den veränderlichen Zustand, DuckDB wertet einen dafür bereitgestellten Datenstand aus. Diese Kombination setzt einen Datentransfer und klare Regeln für die Aktualität der Analysedaten voraus. Sie ist sinnvoll, wenn der Nutzen der Auswertungen diesen zusätzlichen Aufwand rechtfertigt.

Lesen Sie auch: