Preswald: Python-Datenapps als einzelne HTML-Datei, ausgeliefert über Pyodide und DuckDB

Das Problem: Analyseergebnisse, die niemand installieren will

Der übliche Weg, eine Datenauswertung an eine andere Person zu geben, führt über ein Notebook, ein Repository oder einen gehosteten Dienst. Alle drei Varianten verlangen etwas von der empfangenden Seite: eine Python-Umgebung, einen Account, eine laufende Instanz. Preswald setzt an dieser Stelle an und beschreibt das Ziel im README so: eine App soll als einzelne Datei oder als Ordner teilbar sein, ohne dass die Gegenseite etwas installiert. Die Zielgruppe sind damit nicht Plattformteams, sondern Analysten, die ein Ergebnis ausliefern, und Entwickler, die einem nicht-technischen Publikum ein Werkzeug in die Hand geben wollen. Das README nennt vier Situationen, in denen das hilft: Logik, UI und Daten in einer Datei bündeln, ein Werkzeug an jemanden liefern, der nichts installieren soll, mit sensiblen Daten lokal arbeiten, und KI-Systemen strukturierte, veränderbare Werkzeuge geben.

Wie die App zustande kommt: Pyodide, DuckDB und ein Abhängigkeitsgraph

Preswald beschreibt sich selbst als Static-Site-Generator. Der Bauvorgang erzeugt einen Ordner dist/, der laut README alles enthält, was zum Ausführen nötig ist. Zur Laufzeit passiert die Arbeit im Browser: Pyodide stellt die Python-Laufzeit bereit, DuckDB übernimmt die Abfragen, und die Daten liegen als Dateien bei. Der Nutzer schreibt Python, nicht JavaScript, und ruft Komponenten wie text(), table() oder get_df() auf. Die Reaktivität kommt aus einem Abhängigkeitsgraphen, den das README als DAG bezeichnet: Wenn sich eine Eingabe ändert, läuft nicht das ganze Skript erneut, sondern nur der Teil, der von dieser Eingabe abhängt. Das ist die eigentliche technische Entscheidung des Projekts. Sie erkauft kurze Reaktionszeiten mit einem Datenmodell, in dem alles, was die App braucht, vorher im Paket liegen muss. Ein Datenbankserver, der zur Laufzeit abgefragt wird, passt in dieses Modell nicht hinein.

Installation und Projektgerüst in vier Befehlen

Die Installation läuft über PyPI, wahlweise mit pip oder uv. Das README zeigt den Ablauf kompakt: pip install preswald, dann preswald init my_app, cd my_app, preswald run. Der Init-Schritt legt ein festes Gerüst an, bestehend aus hello.py für die App-Logik, preswald.toml für Metadaten und Konfiguration, secrets.toml für Zugangsdaten wie API-Schlüssel, einem Ordner data/ mit sample.csv und einem Ordner images/ für Branding. Der Entwicklungsserver meldet sich laut README typischerweise unter http://localhost:8501. Für die Auslieferung existiert ein eigener Befehl: preswald export baut die App in dist/. Wer den Port ändern will, setzt port in der Projektsektion der preswald.toml, nicht als Kommandozeilenargument. Das ist eine kleine, aber folgenreiche Festlegung: Die Konfiguration lebt in der Datei, nicht im Aufruf.

Was in preswald.toml tatsächlich konfigurierbar ist

Die Konfigurationsdatei gliedert sich in Abschnitte. Unter [project] stehen title, version, port, slug und entrypoint, wobei entrypoint auf hello.py zeigt und damit bestimmt, welche Datei die App startet. Unter [branding] lassen sich name, logo, favicon und primaryColor setzen, im Beispiel der Hexwert #F89613. Unter [logging] gibt es level mit den zulässigen Werten DEBUG, INFO, WARNING, ERROR und CRITICAL sowie format, im Beispiel ein Muster mit asctime, name, levelname und message. Auffällig ist, was fehlt: Es gibt im gezeigten Ausschnitt keine Sektion für Datenquellen, obwohl das README erwähnt, dass die Datei auch data sources definiert. Wer eine Verbindung zu einer externen Quelle braucht, muss die Dokumentation unter docs.preswald.com konsultieren. Das ist eine echte Lücke in diesem Material, und sie betrifft ausgerechnet den Teil, der für Data-Workflows am wichtigsten wäre.

Die Grenze liegt dort, wo die Datenmenge den Browser erreicht

Preswald lädt Daten in den Browser. Das ist die Stärke und gleichzeitig die harte Grenze. Eine CSV-Datei mit einigen zehntausend Zeilen ist unproblematisch. Ein Data Warehouse mit mehreren Gigabyte ist es nicht, weil das Paket diese Daten mitführen müsste und der Browser sie im Speicher halten muss. Das README spricht von Apps, die offline laufen, sogar mit großen Daten, nennt aber keine Obergrenze und keine Speicheranforderungen. Wer eine solche Zahl braucht, findet sie in diesem Material nicht. Ein zweiter Punkt: secrets.toml ist Teil des Projektgerüsts. Wenn Zugangsdaten in einem Paket liegen, das als Ordner weitergereicht wird, ist die Frage, wer dieses Paket am Ende öffnet, keine Nebensache. Preswald positioniert sich als Werkzeug für lokale Kontrolle, und dieser Anspruch hängt daran, wie sorgfältig man mit dem verteilten Ordner umgeht.

Was Preswald von Streamlit unterscheidet

Der naheliegende Vergleich ist Streamlit. Beide erlauben Datenapps in reinem Python mit fertigen Komponenten für Tabellen und Diagramme, und beide lösen das Reaktivitätsproblem über einen Abhängigkeitsgraphen. Der Unterschied sitzt in der Ausführungsschicht. Streamlit startet einen Python-Server, der die App rendert und an den Browser ausliefert. Preswald verschiebt die Ausführung in den Browser über Pyodide und DuckDB. Daraus folgen zwei Dinge: Ein Preswald-Export braucht keinen Server und läuft offline, während eine Streamlit-App ohne laufenden Prozess nicht existiert. Umgekehrt kann eine Streamlit-App zur Laufzeit auf alles zugreifen, was der Server erreicht, also Datenbanken, Dateisysteme, interne APIs. Preswald kann das nicht, weil im Browser kein Server steht, der die Verbindung halten könnte. Wer Datenzugriff und Zugriffskontrolle serverseitig braucht, wählt das falsche Werkzeug.

Pflegeaufwand, Versionen und die Lizenzfrage

Die Release-Historie zeigt einen schnellen Rhythmus: v0.1.57 und v0.1.58 erschienen beide im Mai 2025, v0.1.59 am 5. Juni 2025. Alle drei liegen auf einer 0.1.x-Nummer, was auf eine frühe Phase hindeutet. Wer Preswald produktiv einsetzt, sollte damit rechnen, dass sich APIs zwischen Minor-Versionen bewegen können, auch wenn das Material keine konkreten Breaking Changes auflistet. Der letzte Push auf main wird mit Juni 2026 angegeben, das Projekt ist nicht archiviert. Zur Lizenz: Preswald steht unter Apache-2.0, wie die Lizenzdatei und das Badge im README zeigen. Das erlaubt kommerzielle Nutzung und Modifikation unter den Bedingungen dieser Lizenz, üblicherweise inklusive Beibehaltung von Copyright- und Lizenzhinweisen. Eine rechtliche Bewertung des eigenen Falls ersetzt das nicht. Praktisch relevant ist ein anderer Punkt: Weil Pyodide und die mitgelieferten Python-Pakete im Export landen, wandern auch deren Lizenzen in das ausgelieferte Paket, und die sollte man beim Weitergeben kennen.

Wann sich der Blick auf dist/ lohnt

Der aussagekräftigste Test vor einer Entscheidung ist unspektakulär: eine App mit den echten Daten bauen und sich den dist/-Ordner ansehen. Dort zeigt sich, wie groß das Paket wird, wenn die eigenen CSV-Dateien und die Pyodide-Laufzeit zusammenkommen. Ob das Ergebnis noch per Chat oder E-Mail weitergegeben werden kann oder nur über einen Dateitransfer, entscheidet darüber, ob der zentrale Nutzen des Projekts in der eigenen Umgebung überhaupt trägt. Preswald ist kein Ersatz für eine gehostete Analysedatenbank und will es laut README auch nicht sein. Es ist ein Auslieferungsformat für abgeschlossene Auswertungen, und in dieser Rolle ist die Größe des Ergebnisses die Zahl, an der sich die Eignung entscheidet.

Redaktionelles Fazit

Wer einem Stakeholder eine Analyse als Ordner schicken will, der ohne Installation und ohne Netz läuft, findet in Preswald ein passendes Werkzeug. Wer serverseitige Datenbankverbindungen, Benutzerkonten oder Zugriffskontrolle braucht, ist hier falsch. Vor dem ersten echten Einsatz sollte man prüfen, wie groß der erzeugte dist/-Ordner mit den eigenen CSV-Dateien wird und ob das eigene Datenvolumen überhaupt sinnvoll in den Browser passt.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. StructuredLabs/preswald on GitHub