DuckDB: Kassenauswertung ohne Datenbankserver

Der Karton voller Exporte

Ein Kunde, mehrere Filialen, in jeder eine Kasse, und die Frage klang harmlos: „Können Sie uns aus den Kassendaten eine ordentliche Umsatzauswertung bauen?” Die Daten gab es, als Exporte aus dem Kassensystem, über mehrere Jahre gesammelt. Kein Karton voller Bons also, sondern der digitale Gegenwert: ein Verzeichnis voller Dateien, je Kasse und Zeitraum eine.

Der erste Instinkt heißt immer Excel. Ich habe nichts gegen Excel, es hat mehr Jahresabschlüsse gerettet, als ihm je gedankt wurde. Aber Exporte aus mehreren Kassen über Jahre zusammenzuführen, jeden Monat aufs Neue, mit handgebauten Pivot-Tabellen und einem Kollegen, der sich erinnern muss, welche Spalte er letztes Mal wo hingezogen hat: Das ist keine Auswertung, das ist ein Ritual. Und Rituale haben die unangenehme Eigenschaft, mit dem Kollegen in Urlaub zu fahren.

Der zweite Instinkt heißt Datenbankserver. PostgreSQL aufsetzen, Importstrecke bauen, Daten laden, pflegen, patchen. Für eine monatliche Auswertung ist das, als würde man für den Sonntagsbraten eine Großküche einbauen.

Es gibt eine Mitte, und sie heißt DuckDB.

Eine Datenbank, die keine Installation will

DuckDB ist eine analytische Datenbank, die ohne Server auskommt. Sie läuft im Prozess des Werkzeugs, das sie aufruft: als einzelnes Programm auf der Kommandozeile, als Bibliothek in Python oder R. Kein Dienst, der gepatcht werden will, keine Ports, keine Benutzerverwaltung, nichts, was nachts um drei Alarm schlägt. Das Projekt beschreibt sich selbst in Anlehnung an SQLite, nur eben für Auswertungen statt für Transaktionen: eine Datei statt einer Infrastruktur. MIT-lizenziert, quelloffen, und die Engine ist spaltenorientiert, also genau für das gebaut, was Auswertungen tun: wenige Spalten über sehr viele Zeilen aggregieren.

Für einen alten Kommandozeilen-Igel wie mich ist das Beste daran: Es ist ein CLI-Werkzeug. Man tippt duckdb, und dann spricht man SQL.

SQL direkt auf die Exporte

Der Teil, der beim ersten Mal nach Zauberei aussieht: DuckDB braucht keinen Import. Es liest CSV-, Excel-, JSON- und Parquet-Dateien direkt, erkennt Spalten und Datentypen selbst, und ein Platzhalter im Pfad führt alle Dateien zusammen:

SELECT filiale,
       date_trunc('month', verkauft_am) AS monat,
       sum(betrag)                      AS umsatz
FROM 'exporte/*/kasse-*.csv'
GROUP BY ALL
ORDER BY monat, filiale;

Das ist die ganze Zusammenführung. Kein Ladeskript, keine Zwischentabelle, kein „bitte erst Blatt 3 in Blatt 1 kopieren”. Die Abfrage läuft über alle Filialen und alle Jahre in einem Rutsch, und weil die Engine spaltenorientiert arbeitet, ist sie damit schnell fertig, auch wenn die Zeilen in die Millionen gehen.

Fürs Kennenlernen fremder Exporte gibt es SUMMARIZE: eine Zeile SQL, und DuckDB zeigt für jede Spalte Minimum, Maximum, Durchschnitt, Anzahl der Nullwerte. Bevor man auswertet, sieht man, was man da eigentlich vor sich hat. Genau in dieser Übersicht fallen die ersten Merkwürdigkeiten auf, noch bevor irgendjemand eine Frage gestellt hat.

Die unbequemen Fragen

Umsatz nach Monat und Filiale kann jeder. Interessant wird eine Kassenauswertung dort, wo sie Fragen beantwortet, die niemand gern stellt: Gibt es Tage, an denen eine Kasse gar nichts gemeldet hat, und war da Feiertag oder fehlt ein Export? Häufen sich Stornos an bestimmten Tagen? Passt die Summe der Einzelpositionen zur Belegsumme?

Mit SQL sind das keine Detektivarbeiten, sondern Abfragen. Eine Kalendertabelle gegen die tatsächlichen Buchungstage gestellt, zeigt Lücken. Eine Window-Funktion legt jeden Tag neben den Durchschnitt seiner Nachbarn und macht Ausreißer sichtbar. Das Ergebnis ist keine Anklage, meistens ist die Erklärung banal: ein vergessener Export, eine Kasse im Wartungsmodus. Aber man weiß es dann, statt es zu ahnen. Für die Plausibilität der eigenen Zahlen ist dieser Teil mehr wert als jedes bunte Dashboard.

Von der Auswertung zur Prognose

Der Kunde wollte am Ende nicht nur wissen, was war, sondern was kommt: eine Umsatzprognose für die Planung. Ich bleibe da ehrlich, DuckDB ist kein Orakel und will keins sein. Was es liefert, ist die Grundlage, ohne die jede Prognose Kaffeesatz bleibt: eine saubere, lückengeprüfte Zeitreihe. Gleitende Durchschnitte und Vorjahresvergleiche sind mit Window-Funktionen ein paar Zeilen SQL, Saisonmuster werden sichtbar, wenn man Monate übereinanderlegt. Die eigentliche Vorhersage ist dann Handwerk obendrauf, und sie ist nur so gut wie die Reihe darunter. Der Unterschied zwischen „Prognose aus dem Bauch” und „Prognose aus den Daten” entsteht nicht im Modell, sondern in der Datenqualität davor.

Monat für Monat derselbe Handgriff

Der eigentliche Gewinn zeigt sich im zweiten Monat. Die Auswertung ist kein Zustand in einer Arbeitsmappe, sondern ein Satz SQL-Skripte in einem Ordner. Neuer Export rein, Skript laufen lassen, fertig. Dieselben Abfragen, dieselben Definitionen, dieselben Ergebnisse, egal wer sie startet. Was letzten Monat „Umsatz” hieß, heißt auch diesen Monat „Umsatz”, weil es dieselbe Zeile Code ist.

Zwei Eigenschaften machen das für Kassendaten besonders passend. Erstens bleiben die Daten auf dem Rechner, auf dem sie liegen: Umsatzzahlen wandern in keine Cloud und zu keinem Auswertungsdienst, die Frage nach dem Auftragsverarbeitungsvertrag stellt sich gar nicht erst. Zweitens bleiben die Roh-Exporte unangetastet. DuckDB liest sie nur; Ergebnisse lassen sich als CSV für den Steuerberater oder als Parquet für die nächste Stufe exportieren. Parquet ist dabei nichts Exotisches, nur ein komprimiertes Spaltenformat, das große Tabellen klein und schnell lesbar macht.

Wo DuckDB aufhört

Damit kein falscher Eindruck entsteht: DuckDB ist kein Ersatz für die Datenbank hinter dem Kassensystem oder dem ERP. Es gibt keine Benutzerverwaltung, keinen Mehrbenutzerbetrieb übers Netz, kein Transaktionssystem fürs Tagesgeschäft. Wer viele gleichzeitige Schreiber braucht, ist bei PostgreSQL oder MariaDB richtig, und das ist keine Schwäche, sondern Arbeitsteilung: Die eine Datenbank betreibt das Geschäft, die andere beantwortet Fragen dazu.

Genau diese Arbeitsteilung macht DuckDB zum idealen Werkstatt-Werkzeug: Es liegt im Koffer, wiegt nichts, und wenn ein Kunde mit einem Verzeichnis voller Exporte kommt, ist die erste belastbare Auswertung eine Frage von Stunden, nicht von Projekten.

Wer so einen Datenbestand herumliegen hat, aus Kassen, aus dem Webshop, aus einem Altsystem, und wissen will, was drinsteckt: Wir schauen ihn uns an. Und wenn aus der Auswertung eine laufende Datenstrecke werden soll, mit automatischem Einsammeln und Bericht, macht das unsere Schwester-Marke pad.software als Daten-Anbindung. Was wir im Handel sonst betreuen, von der Kasse bis zur Warenwirtschaft, steht unter IT für Einzelhandel & Großhandel.