marimo: Reaktives Python-Notebook mit SQL-Zellen, skriptfähiger Ablage und App-Modus

marimo: Ein reaktives Python-Notebook statt JSON-Ablage

marimo ist ein reaktives Python-Notebook, das laut README als Ersatz für Werkzeuge wie Jupyter, Streamlit, Jupytext, ipywidgets und Papermill auftritt. Der Kernunterschied zu klassischen Notebooks: Die Dateien werden als reines Python gespeichert, nicht als JSON. Dadurch passen sie in Git-Diffs, lassen sich wie Skripte ausführen und behalten trotzdem Interaktivität.

Das README führt die Hauptziele an: reproduzierbare Experimente, SQL-Zugriff auf Datenrahmen und Datenbanken, Ausführung als Skript, Bereitstellung als App und Versionierung mit Git. Als direkte Inspiration nennt das Projekt Pluto.jl, ObservableHQ und die Essays von Bret Victor. marimo ist ein NumFOCUS-Partnerprojekt und steht unter Apache-2.0.

Reaktive Ausführung und träger Modus für teure Zellen

Die Reaktivität ist das eigentliche Unterscheidungsmerkmal. Führt man eine Zelle aus, erkennt marimo über eine statische Analyse des Codes, welche anderen Zellen ihre Variablen referenzieren, und führt genau diese Zellen automatisch mit aus. Die Ausführungsreihenfolge richtet sich also nach Variablenreferenzen, nicht nach der Position der Zelle im Dokument.

Löscht man eine Zelle, entfernt marimo ihre Variablen aus dem Programmspeicher; das soll den klassischen Fehler versteckter Zustände ausschließen. Für teure Berechnungen lässt sich die Laufzeit auf einen trägen Modus umstellen: Betroffene Zellen werden dann als veraltet markiert statt automatisch ausgeführt. Der Programmzustand bleibt konsistent, ohne dass versehentlich große Rechnungen laufen.

Reines Python, git-freundlich und als Skript ausführbar

Gespeichert wird als .py-Datei, was die Notebooks von Natur aus git-freundlich macht. Das README zeigt, wie ein Notebook als normales Python-Skript läuft: python your_notebook.py, wobei CLI-Argumente die Ausführung parametrisieren. Bestehende Jupyter-Dateien wandelt man mit marimo convert your_notebook.ipynb in eine .py-Datei um.

Ein Kernpunkt bleibt dabei: Notebooks sind reines Python, selbst wenn SQL-Zellen enthalten sind. Wer also Abfragen gegen Datenquellen schreibt, erhält kein Zweitformat, sondern weiterhin eine einheitliche Python-Datei, die sich versionieren und in Skriptpipelines einhängen lässt.

SQL-Zellen und interaktive Dataframes

SQL ist in marimo eingebaut. Zellen akzeptieren Abfragen, die von Variablen im Python-Programm abhängen, und führen sie gegen Dataframes, Datenbanken, Lakehouses, CSV-Dateien, Google Sheets und weitere Quellen aus. Die eingebaute SQL-Engine liefert das Ergebnis als Python-Dataframe zurück, sodass die Abfrage direkt weiterverarbeitbar bleibt.

Ergänzend gibt es einen interaktiven Dataframe-Viewer, mit dem sich laut README Millionen von Zeilen ohne Code durchblättern, durchsuchen, filtern und sortieren lassen. Auch hier wird kein Code generiert, sondern eine gebundene Ansicht angezeigt, die mit den Daten Schritt hält.

UI-Elemente ohne Callbacks und dynamisches Markdown

Interaktive Elemente wie Schieberegler, Dropdowns, Dataframe-Transformatoren und Chat-Oberflächen werden direkt an Python gebunden, ohne dass Callback-Funktionen geschrieben werden müssen. Interagiert ein Nutzer mit einem Element, führt marimo die Zellen, die dieses Element verwenden, mit den neuen Werten automatisch neu aus.

Markdown lässt sich mit Python-Variablen parametrisieren, sodass erklärender Text auf die Daten reagiert. Wie genau diese Bindungen intern umgesetzt sind, legt das README nicht dar. Für Visualisierungen ist das Zusammenspiel aus Reaktivität und parametrisiertem Text ein sichtbarer Vorteil gegenüber einem statischen Skript.

Paketverwaltung und reproduzierbare Abhängigkeiten

Reproduzierbarkeit adressiert marimo über mehrere Wege: keinen versteckten Zustand, deterministische Ausführung, eine eingebaute Paketverwaltung und die konfigurierbare Laufzeit. Die Paketverwaltung unterstützt laut README die gängigen Paketmanager, kann Pakete beim Import installieren, Anforderungen in die Notebook-Datei serialisieren und sie in isolierten venv-Sandboxes automatisch installieren.

Wer Experimente nachvollziehbar halten will, kann die Abhängigkeiten damit direkt im Notebook ablegen. Das übernimmt einen Teil der Arbeit, die sonst in Umgebungsdateien oder Containerimages ausgelagert wird, und macht das Notebook als Einheit transportabler.

Ausführungsmodi: App, Folien, WASM und mo.lab

Wie ein Notebook am Ende läuft, wählt man beim Aufruf. Neben dem Skriptbetrieb per python your_notebook.py gibt es marimo run your_notebook.py, das das Notebook als interaktive Web-App bereitstellt; laut README ist dabei der Python-Code ausgeblendet und nicht editierbar. Für Präsentationen ist ein Folien-Layout vorgesehen.

Im Browser läuft marimo über WASM, ohne dass lokal Python installiert sein muss. Dazu kommt mo.lab, ein gehosteter Notebook-Dienst, mit dem sich Notebooks online erstellen und als Links teilen lassen, vergleichbar mit einem Colab, aber auf marimo zugeschnitten. Der Einstieg beginnt laut README mit pip install marimo und marimo tutorial intro.

Editor, KI-Pairing und Grenzen gegenüber Jupyter

Der Editor ist laut README modern ausgestattet: GitHub Copilot, ein KI-Assistent mit Kontext zu den Variablen im Speicher, Vim-Tastenkombinationen, ein Variablen-Explorer und Ruff-Formatierung zählen zu den eingebauten Funktionen, HTML-Export ist ebenfalls erwähnt. Für die Zusammenarbeit mit Agenten verweist das Projekt auf marimo pair, das mit Claude Code, Codex oder OpenCode funktioniert; eigene API-Schlüssel oder lokale Modelle werden akzeptiert. In VS Code, Cursor und PyCharm gibt es Erweiterungen, in neovim oder Zed lässt sich ebenfalls bearbeiten.

Die Grenzen sind an der Architektur ablesbar. Wer auf bestehende Callback-Widgets aus ipywidgets oder auf Streamlit-Dashboards mit eigenen Komponenten setzt, muss diese Teile neu implementieren, denn marimo bindet UI-Elemente ohne Callbacks an. Wer die Reihenfolge der Zellen manuell steuern will, kollidiert mit der deterministischen Ordnung nach Variablenreferenzen. Als Ausweg bleibt das klassische Jupyter für vorhandene zellenreihenfolgeabhängige Notebooks oder Streamlit, wenn nur schnelle Dashboards ohne Notebook-Semantik gebraucht werden. Das README selbst trifft keine Aussagen zu Sicherheitsgarantien oder Benchmarks; zum Erfassungszeitpunkt war die aktuelle Version 0.24.0 vom 17. August 2026.

Redaktionelles Fazit

marimo eignet sich für Datenarbeiter, die reproduzierbare, git-versionierbare Notebooks führen und SQL direkt im Python-Editor verwenden wollen, sofern sie bereit sind, auf zellenreihenfolgeabhängiges Arbeiten zu verzichten. Wer auf bestehende Callback-Widgets oder Streamlit-Dashboards setzt, muss Teile davon neu bauen. Vor der Übernahme lohnt ein Test: ein eigenes Notebook mit marimo convert wandeln und als Skript ausführen, um zu prüfen, ob die Zellen deterministisch laufen; die Apache-2.0-Lizenz gestattet Nutzung und Modifikation, ohne Garantieübernahmen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes