Pandas vs. DuckDB: Ein praxisnaher Vergleich für Python-Datenworkflows

Pandas gilt seit mehr als zehn Jahren als eines der wichtigsten Werkzeuge für die Datenbearbeitung in Python. Wenn Sie Features für ein Machine-Learning-Modell aufbereiten, eine CSV-Datei in einem Notebook untersuchen oder einen kleinen ETL-Prozess erstellen, basiert Ihr Code sehr wahrscheinlich auf einem Pandas DataFrame. Pandas nimmt seit Langem eine zentrale Rolle im Python-Datenökosystem ein.

Mit wachsenden Datenmengen und anspruchsvolleren Analyseaufgaben stoßen jedoch die In-Memory-Verarbeitung und die überwiegend single-threaded Arbeitsweise von Pandas zunehmend an Grenzen. DuckDB setzt genau an diesen Herausforderungen an. Es handelt sich um eine In-Process-SQL-OLAP-Engine, also eine Engine für Online Analytical Processing, die direkt im Python-Prozess läuft. Die häufig verwendete Beschreibung als „SQLite für Analytics“ fasst gut zusammen, wofür DuckDB steht:

• Schnelle und skalierbare analytische Abfragen
• Native Unterstützung für Parquet und Arrow
• Parallele Ausführung
• Verarbeitung von Datensätzen, die größer als der verfügbare Arbeitsspeicher sind

Dieser Beitrag stellt beide Werkzeuge aus einer praktischen, entwicklerorientierten Perspektive gegenüber. Er zeigt, wie sich Pandas und DuckDB hinsichtlich Architektur, Performance, Skalierbarkeit und Entwicklererfahrung unterscheiden. Außerdem wird erklärt, in welchen Situationen DuckDB Aufgaben von Pandas sinnvoll übernehmen kann und wo Pandas weiterhin die bessere Wahl bleibt.

Wichtige Erkenntnisse

• DuckDB sollte nicht als vollständiger Ersatz für Pandas verstanden werden, sondern als sinnvolle Ergänzung. DuckDB ist auf umfangreiche analytische Workloads ausgelegt, während Pandas weiterhin sehr gut für kleine bis mittlere Datensätze, Feature Engineering und allgemeine Python-native Datenmanipulation geeignet ist.
• Die Architektur beider Werkzeuge unterscheidet sich grundlegend. Pandas ist eine Python-Bibliothek rund um ein In-Memory-DataFrame-Objekt. DuckDB ist dagegen eine vektorisierte, SQL-first und spaltenorientierte OLAP-Engine, die parallele Ausführung unterstützt und Daten auch jenseits der Speichergrenze abfragen kann.
• Bei Performance und Skalierbarkeit hat DuckDB häufig Vorteile, besonders bei großen Parquet- oder Arrow-Datensätzen. Durch Projection Pushdown, Filter Pushdown, Multi-Threading und diskgestützte Ausführung können Abfragen deutlich schneller sein als vergleichbare Pandas-Workflows.
• Eine große Stärke von DuckDB liegt in hybriden Workflows. DuckDB kann Pandas-, Polars- und Arrow-DataFrames direkt abfragen, sie mit großen externen Parquet-, CSV- oder SQLite-Dateien kombinieren und Ergebnisse in unterschiedlichen Formaten zurückgeben. Dadurch lässt sich SQL nahtlos direkt in Notebook-Workflows nutzen.
• Die passende Lösung hängt vom jeweiligen Anwendungsfall ab. DuckDB eignet sich besonders für OLAP-ähnliche Abfragen, große Joins und umfangreiche Datensätze. Pandas überzeugt weiterhin bei interaktiver Datenbereinigung, individueller Python-Logik, enger Integration mit Machine-Learning- und Visualisierungsbibliotheken sowie bei Datenmengen, die bequem in den Arbeitsspeicher passen.

Was sind Pandas und DuckDB?

Um Performance und Workflow-Möglichkeiten sinnvoll vergleichen zu können, ist zunächst wichtig zu verstehen, wofür beide Werkzeuge entwickelt wurden. Pandas ist eine DataFrame-Bibliothek, die eng mit Python verbunden ist. DuckDB hingegen ist eine eingebettete SQL-Analytics-Engine, die direkt innerhalb des Python-Prozesses ausgeführt wird.

Pandas als Python-DataFrame-Bibliothek

Pandas wird häufig als Standardbibliothek für Data Wrangling in Python angesehen. Die Bibliothek brachte das DataFrame-Konzept bereits 2008 in die Python-Welt und entwickelte sich seitdem zu einem der wichtigsten Werkzeuge im Data-Science-Ökosystem. Ein Pandas DataFrame ist eine zweidimensionale, im Arbeitsspeicher gehaltene Tabellenstruktur mit beschrifteten Zeilen und Spalten. Über eine Python-API bietet er schnellen, indexbasierten Zugriff. Operationen wie Slicing, Filtern und Transformieren werden durch C- und NumPy-Operationen unterstützt und dadurch vektorisiert ausgeführt.

Zentrale Eigenschaften von Pandas

• In-Memory-Verarbeitung: Pandas DataFrames befinden sich im Arbeitsspeicher. Das ermöglicht bei kleineren Datensätzen sehr schnellen Direktzugriff, bedeutet aber auch, dass der gesamte Datensatz in den RAM passen muss. Bei mehreren Millionen Zeilen können schnell Speicherfehler oder deutliche Geschwindigkeitseinbußen auftreten, wenn der verfügbare Arbeitsspeicher knapp wird.
• Umfangreiche API und großes Ökosystem: Pandas bietet eine breite, Python-freundliche API für Filtern, Aggregieren, Zusammenführen, Zeitreihenverarbeitung und viele weitere Datentätigkeiten. Die Bibliothek ist sehr flexibel und erlaubt auch eigene Python-Logik innerhalb von DataFrame-Workflows. Zudem funktioniert Pandas sehr gut mit anderen Bibliotheken, darunter Visualisierungstools und scikit-learn. Dadurch lassen sich DataFrames einfach an Diagramme oder Machine-Learning-Modelle übergeben.
• Einfache Nutzung: Viele Data Scientists empfinden Pandas als intuitiv. Da der Code in normalem Python geschrieben wird, lässt er sich meist gut debuggen und iterativ weiterentwickeln. Für grundlegende Pandas-Aufgaben ist die Einstiegshürde vergleichsweise niedrig.

DuckDB als In-Process-SQL-Engine

DuckDB wird oft als „SQLite für Analytics“ beschrieben. Ähnlich wie Pandas kann DuckDB Daten direkt innerhalb eines Python-Prozesses verarbeiten. Unter der Oberfläche funktioniert DuckDB jedoch völlig anders:

• Spaltenorientierte, vektorisierte Engine: DuckDB speichert Daten spaltenorientiert und nutzt vektorisierte Ausführung. Dabei werden Blöcke von Spaltenwerten, sogenannte Vektoren, verarbeitet.
• SQL-zentrierte Schnittstelle: DuckDB wird hauptsächlich über SQL-Abfragen wie SELECT, JOIN und GROUP BY verwendet. Es handelt sich um eine vollständige SQL-Engine mit einem umfangreichen Dialekt, der PostgreSQL-SQL ähnelt. Abläufe, die in Pandas viele Codezeilen benötigen, lassen sich in DuckDB häufig als eine einzelne SQL-Abfrage ausdrücken.
• Festplattenbasiert und speicherschonend: DuckDB kann spaltenorientierte Dateiformate wie Parquet, CSV und JSON direkt von der Festplatte abfragen, ohne sie vorher vollständig in den Arbeitsspeicher zu laden. In der Praxis kann DuckDB auf eine 10-GB-Parquet-Datei zeigen und eine begrenzte SELECT-Abfrage fast sofort mit geringem Speicherbedarf ausführen.
• Eingebettete OLAP-Datenbankfunktionen: Da DuckDB eine Datenbank-Engine ist, bringt es typische Datenbankfunktionen mit. Dazu gehören gleichzeitige Abfragen, Transaktionen, Window Functions, Common Table Expressions, parallele Ausführung und weitere fortgeschrittene SQL-Funktionen.
• Leichtgewichtig und ohne Serverabhängigkeit: DuckDB ist ein kleines Paket von ungefähr 10 MB und benötigt keinen separaten Server. Nach der Installation mit pip ist es einsatzbereit. Alles, was DuckDB benötigt, ist statisch eingebunden, sodass kein zusätzlicher Datenbankdienst betrieben werden muss.

Architektonische Unterschiede zwischen Pandas und DuckDB

Beim Vergleich von DuckDB und Pandas zeigen sich mehrere wichtige Unterschiede in der Architektur:

DuckDB ist als spaltenorientierte Datenbank konzipiert. Eine Aggregation wie SELECT SUM(value) kann daher nur die benötigten Spalten lesen, anstatt vollständige Zeilen zu verarbeiten. Durch vektorisierte Ausführung werden Operationen auf großen Werteblöcken durchgeführt, wodurch der Aufwand pro Operation sinkt. Pandas verarbeitet Daten standardmäßig häufig zeilenweise oder in kleineren Datenabschnitten. Deshalb ist DuckDB bei Aggregationen, Filtern und Joins oft schneller und speichereffizienter, besonders wenn die Datenmengen größer werden.

Benchmarks

Der folgende Benchmark vergleicht DuckDB, Polars und Pandas. Er wurde auf einem MacBook Pro M2 mit 16 GB RAM ausgeführt. Der synthetische Benchmark-Datensatz repräsentiert 1 Million Personen und 10 Millionen Positionsdatensätze. Die Ergebnisse zeigten DuckDB als schnellste Lösung. Im Durchschnitt beendete DuckDB die Verarbeitung in 3,84 Sekunden. Polars folgte mit einer durchschnittlichen Laufzeit von 5,77 Sekunden knapp dahinter. Pandas war im Vergleich zu DuckDB und Polars langsamer und erreichte eine durchschnittliche Laufzeit von 19,57 Sekunden. Damit war Pandas mehr als fünfmal langsamer als DuckDB.

Dieses Ergebnis ist hilfreich, um die Stärken und Grenzen von Pandas einzuschätzen, insbesondere bei großen Datensätzen oder performancekritischer Datenverarbeitung. Gleichzeitig zeigt es, warum neuere und stärker spezialisierte Datenverarbeitungswerkzeuge wie DuckDB und Polars immer wichtiger werden. Je nach Workload können sie deutliche Performance-Vorteile gegenüber Pandas bieten.

Integration von DuckDB und Pandas

Eine der größten Stärken von DuckDB besteht darin, dass man sich nicht strikt zwischen SQL und Pandas entscheiden muss. Stattdessen fügt sich DuckDB in bestehende Python-Workflows ein:

• SQL-Abfragen direkt auf In-Memory-Pandas-DataFrames ausführen.
• Abfrageergebnisse als Pandas-, Polars- oder Arrow-Objekte zurückgeben.
• Externe Dateien wie CSV, Parquet oder JSON mit DataFrames in einer einzigen Abfrage kombinieren.
• Den gleichen Integrationsstil auch mit Polars und Apache Arrow nutzen.

DuckDB wird dadurch zu einer SQL-Engine im Notebook und nicht zu einem separaten System, das zusätzlich verwaltet werden muss.

1. Pandas DataFrames mit SQL über Replacement Scans abfragen

Mit dem Replacement-Scan-Mechanismus von DuckDB kann ein Pandas DataFrame wie eine SQL-Tabelle behandelt werden, indem einfach der Variablenname in der Abfrage verwendet wird. Eine explizite Registrierung ist nicht erforderlich.

Beispiel: Pandas DataFrame mit SQL filtern und transformieren

pip install duckdb
import duckdb
import pandas as pd

# Einen kleinen DataFrame in Pandas erstellen
df = pd.DataFrame(
    {
        "city": ["Paris", "Berlin", "Lagos", "Delhi"],
        "temp_c": [21, 19, 30, 35],
    }
)

# DuckDB erkennt 'df' über Replacement Scans als Tabelle
result = duckdb.sql("""
    SELECT
        city,
        temp_c,
        temp_c * 9.0/5.0 + 32 AS temp_f
    FROM df
    WHERE temp_c >= 25
""").df()

print(result)

Wichtige Punkte

• df sollte ein regulärer Pandas DataFrame sein.
• duckdb.sql(…) liest df automatisch als SQL-Tabelle mit dem Namen df.
• Es ist keine Kopieroperation erforderlich, da DuckDB auf den vorhandenen DataFrame im Arbeitsspeicher zugreift.
• Das finale Ergebnis wird als weiterer Pandas DataFrame materialisiert.

Wenn mehr Kontrolle benötigt wird, kann alternativ eine explizite Verbindung mit Registrierung verwendet werden:

con = duckdb.connect()
con.register("cities", df)

hot_cities = con.sql("""
    SELECT city, temp_c
    FROM cities
    WHERE temp_c >= 25
""").df()

2. Ergebnisse als Pandas, Polars oder Arrow zurückgeben

Nach einer SQL-Abfrage arbeitet man meist in dem Python-Datenwerkzeug weiter, das am besten zum eigenen Workflow passt. Die Python-API von DuckDB bietet dafür praktische Umwandlungsmethoden:

• .df() gibt einen Pandas DataFrame zurück
• .pl() gibt einen Polars DataFrame zurück
• .arrow() gibt eine Apache Arrow Table zurück
• .fetchnumpy() gibt NumPy-Arrays zurück

Beispiel: Eine SQL-Abfrage mit mehreren Ergebnisformaten

import duckdb
import pandas as pd
import polars as pl
import pyarrow as pa

# Einfacher Beispieldatensatz
df = pd.DataFrame(
    {
        "product": ["A", "A", "B", "B"],
        "amount":  [100, 150,  80, 120],
    }
)

rel = duckdb.sql("""
    SELECT
        product,
        SUM(amount) AS total_amount
    FROM df
    GROUP BY product
    ORDER BY total_amount DESC
""")

# 1) Ergebnis als Pandas zurückgeben
pandas_result = rel.df()

# 2) Ergebnis als Polars zurückgeben
polars_result = rel.pl()

# 3) Ergebnis als Arrow Table zurückgeben
arrow_result = rel.arrow()

print("Pandas:\n", pandas_result)
print("Polars:\n", polars_result)
print("Arrow schema:\n", arrow_result.schema)

In einem realen Projekt könnten Sie:

• .df() verwenden, wenn das Ergebnis an scikit-learn oder Python-Visualisierungsbibliotheken übergeben werden soll.
• .pl() verwenden, wenn die anschließenden Verarbeitungsschritte ebenfalls in Polars geschrieben sind.
• .arrow() nutzen, wenn Daten an Systeme übergeben werden sollen, die Arrow unterstützen, oder wenn Zero-Copy-Austausch hilfreich ist.

3. Hybride Workflows: Dateien und DataFrames in einer Abfrage verbinden

DuckDB spielt seine Stärken besonders in hybriden Workflows aus, die Folgendes kombinieren:

• Große Datensätze, die in Dateien gespeichert sind, etwa Parquet auf Festplatte oder in Objektspeicher.
• Kleinere Referenztabellen, die über Pandas im Arbeitsspeicher liegen.

Diese Datenquellen lassen sich in einer einzigen SQL-Anweisung verbinden, ohne dafür eigene ETL-Logik schreiben zu müssen.

Beispiel: Eine große Parquet-Faktentabelle mit einer kleinen Pandas-Dimensionstabelle verbinden

Ein mögliches Szenario wäre:

• data/orders.parquet enthält mehrere zehn Millionen Bestellungen und ist zu groß, um komfortabel in Pandas verarbeitet zu werden.
• Ein kleiner Pandas DataFrame enthält Kundensegmente, die aus einem CRM-Export berechnet wurden.

import os
import duckdb
import pandas as pd
from pathlib import Path

# 1. Sicherstellen, dass das Verzeichnis 'data' existiert
data_dir = Path("data")
data_dir.mkdir(exist_ok=True)

# 2. Einen kleinen Demo-Bestelldatensatz in Pandas erstellen
orders = pd.DataFrame(
    {
        "order_id":    [101, 102, 103, 104, 105],
        "customer_id": [1,   2,   1,   3,   2],
        "order_date":  pd.to_datetime(
            ["2025-01-02", "2025-01-03", "2025-01-05", "2025-02-01", "2025-02-10"]
        ),
        "order_amount": [200.0, 150.0, 300.0, 80.0, 120.0],
    }
)

parquet_path = data_dir / "orders.parquet"

# 3. Daten als Parquet speichern, mit pyarrow oder fastparquet
orders.to_parquet(parquet_path, index=False)

print(f"Saved demo file at: {parquet_path.resolve()}")

# 4. Einen kleinen DataFrame mit Kundensegmenten erstellen
customer_segments = pd.DataFrame(
    {
        "customer_id": [1, 2, 3],
        "segment":     ["Enterprise", "SMB", "Consumer"],
    }
)

# 5. DuckDB verbinden und die Dimensionstabelle registrieren
con = duckdb.connect()
con.register("customer_segments", customer_segments)

# 6. Eine hybride Abfrage ausführen, die Parquet-Daten mit Pandas-Daten verbindet
query = f"""
    SELECT
        o.customer_id,
        s.segment,
        SUM(o.order_amount) AS total_spend
    FROM '{parquet_path.as_posix()}' AS o
    JOIN customer_segments AS s
      ON o.customer_id = s.customer_id
    WHERE o.order_date >= DATE '2025-01-01'
    GROUP BY o.customer_id, s.segment
    ORDER BY total_spend DESC
"""

top_customers = con.sql(query).df()
print(top_customers)

Dieses Muster zeigt einen Best-of-Both-Worlds-Ansatz:

• Pandas kann für spontane Datenaufbereitung, Feature Engineering oder das Erstellen von Lookup-Tabellen genutzt werden.
• DuckDB kann große spaltenorientierte Dateien effizient scannen und aggregieren.
• Alles läuft innerhalb eines einzelnen Python-Prozesses oder Notebooks, ohne dass Spark, Dask oder ein separates Data Warehouse benötigt werden.

4. Replacement Scans mit Polars und Arrow

DuckDB arbeitet gut mit Pandas zusammen, aber die Integration endet nicht dort. Auch mit Polars und Apache Arrow lässt sich DuckDB sehr gut kombinieren. Das ist besonders wichtig, wenn ein gemischter Datenstack verwendet wird.

Es gibt zwei typische Szenarien:

• Ein Polars DataFrame oder eine Arrow Table wird als Eingabe für DuckDB-Abfragen genutzt.
• DuckDB-Abfrageergebnisse werden als Polars- oder Arrow-Objekte zurückgegeben.

Beispiel A: Einen Polars DataFrame mit SQL abfragen

import duckdb
import polars as pl

# Einen Polars DataFrame erstellen
pl_df = pl.DataFrame(
    {
        "id":    [1, 2, 3, 4],
        "value": [10, 20, 30, 40],
    }
)

# DuckDB kann 'pl_df' ähnlich wie Pandas über Replacement Scans erkennen
rel = duckdb.sql("""
    SELECT
        id,
        value,
        value * 2 AS value_x2
    FROM pl_df
    WHERE value >= 20
""")

# Ergebnis wieder als Polars zurückgeben
result_pl = rel.pl()
print(result_pl)

Beispiel B: Mit Arrow Tables arbeiten

import duckdb
import pyarrow as pa

# Eine kleine Arrow Table erstellen
arrow_table = pa.table(
    {
        "event_type": ["click", "view", "click", "purchase"],
        "user_id":    [10, 10, 11, 10],
        "amount":     [None, None, None, 99.0],
    }
)

# Die Arrow Table zur besseren Übersicht explizit registrieren
con = duckdb.connect()
con.register("events", arrow_table)

# SQL auf der Arrow Table ausführen
agg = con.sql("""
    SELECT
        user_id,
        COUNT(*)                    AS num_events,
        SUM(CASE WHEN event_type = 'purchase' THEN amount ELSE 0 END) AS revenue
    FROM events
    GROUP BY user_id
""").arrow()

print(agg)

In beiden Beispielen gilt:

• Unnötige Kopien werden vermieden, da die Daten nah an den Speicherlayouts von Arrow oder Polars bleiben.
• DuckDB fungiert als schnelle SQL-Schicht über vorhandenen DataFrame- oder Arrow-Daten.
• Zwischen Pandas, Polars und Arrow kann an den Übergängen der Pipeline gewechselt werden, je nachdem, was der jeweilige Verarbeitungsschritt erfordert.

Wann DuckDB Pandas ersetzen kann und wann nicht

Sollte Pandas vollständig durch DuckDB ersetzt werden? In manchen Fällen ja, aber nicht grundsätzlich. Die folgende Übersicht zeigt, welche Aufgaben DuckDB gut übernehmen kann und welche meist besser zu Pandas passen:

Pandas bleibt stark, wenn Flexibilität gefragt ist und wenn es um die große Bandbreite kleiner bis mittlerer Workloads geht, bei denen der Overhead kaum auffällt und die enge Python-Integration ein Vorteil ist. DuckDB ist nicht dafür gedacht, diese Rolle vollständig zu ersetzen. Stattdessen ist DuckDB für Situationen ausgelegt, in denen Pandas an Grenzen stößt, etwa bei großen Datensätzen, anspruchsvollen analytischen Abfragen und SQL-zentrierten Workflows.

Einschränkungen und wichtige Überlegungen

Trotz klarer Vorteile ist DuckDB keine Universallösung. Wichtige Einschränkungen sind:

• Nebenläufigkeit: DuckDB verwendet ein Single-Writer-Modell. Mehrere gleichzeitige Leser werden unterstützt, aber es kann nur eine Schreibtransaktion zur gleichen Zeit geben. Für Multi-Writer-Workloads oder intensive OLTP-Anwendungsfälle ist eine serverbasierte Datenbank wie PostgreSQL besser geeignet.
• Reife des Ökosystems: Pandas existiert seit 2008 und verfügt über ein ausgereiftes Ökosystem aus Visualisierungs- und Machine-Learning-Bibliotheken. Das DuckDB-Ökosystem wächst schnell, doch einige komfortable High-Level-Funktionen aus Pandas fehlen weiterhin.
• Lernkurve: Die Pandas-Syntax kann für Analysten ohne SQL-Hintergrund natürlicher wirken. SQL bietet dagegen langfristige Stabilität, Portabilität und breite Vertrautheit über viele Systeme hinweg.
• Keine integrierte Diagrammerstellung: DuckDB ist eine Query Engine. Für Visualisierungen müssen Ergebnisse weiterhin mit Pandas, Matplotlib oder einer anderen Plotting-Bibliothek verwendet werden.
• Experimentelle Funktionen: DuckDB wird aktiv weiterentwickelt. Manche Funktionen können daher noch experimentell sein, beispielsweise bestimmte Erweiterungen oder die Unterstützung neuer Dateiformate. Solche Funktionen können sich zwischen Versionen ändern.

Fazit

DuckDB ist nicht dafür gedacht, Pandas zu verdrängen. Vielmehr erweitert es die Möglichkeiten von Pandas. Wenn Datenworkloads über einen einzelnen In-Memory-DataFrame hinauswachsen, bringt DuckDB eine moderne, leistungsstarke Analyse-Engine direkt in den Python-Workflow. DuckDB kann Parquet-Dateien lesen, Filter an die Speicherschicht weiterreichen, alle verfügbaren CPU-Kerne nutzen und mit Datensätzen arbeiten, die deutlich größer als der Arbeitsspeicher sind. Das ist möglich, ohne einen Server bereitzustellen, die Arbeitsumgebung zu verändern oder den Aufwand verteilter Datenbanksysteme in Kauf zu nehmen.

Pandas bleibt weiterhin eine sehr gute Wahl für tägliche Analysen, Prototyping und schnelles Feature Engineering, das von der Flexibilität von Python profitiert. Sobald ein Workload jedoch Millionen von Zeilen scannen, große Parquet-Dateien verbinden oder mit Arrow-basierten Datensätzen arbeiten muss, liefert DuckDB Geschwindigkeit und Skalierbarkeit, die Pandas allein nicht bietet.

DuckDB stellt Data Scientists die Performance einer lokalen analytischen Datenbank direkt im Notebook bereit und erweitert gleichzeitig Workflows rund um Pandas, Polars, Arrow und dbt.

In der Praxis geht es nicht um „DuckDB gegen Pandas“. Die Zukunft liegt in DuckDB und Pandas gemeinsam. Beide Werkzeuge haben eine klare Rolle im modernen Analytics-Stack. Zusammen ermöglichen sie einen Workflow, der schnell, flexibel und für die heutigen Datenmengen geeignet ist.