Marimo notebook Pythonban: reaktív, git-barát Jupyter alternatíva 2026

Frissítve: 2026. július 30.

A Marimo egy nyílt forráskódú, reaktív Python notebook, amely tiszta .py fájlként tárolódik, DAG-alapú végrehajtási modellel automatikusan újrafuttatja a függő cellákat, és egyetlen paranccsal deployolható interaktív alkalmazásként. Jupyter alternatívaként a rejtett állapotot és a JSON-formátumú notebookok verziókezelési problémáit oldja meg, a fájl pedig végrehajtható scriptként (python notebook.py), importálható modulként, illetve futtatható a marimo run notebook.py paranccsal önálló webappként. Az Apache 2.0 licenc alatt ingyenes.

• A Marimo statikus kódanalízissel felépít egy DAG-ot (irányított körmentes gráf) a cellák változóhivatkozásaiból, és minden változtatásnál automatikusan újrafuttatja az érintett cellákat, így nincs rejtett állapot.
• A notebookok tiszta Python fájlok (.py), így git diff-fel értelmesen összehasonlíthatók, code review-zhatók és importálhatók FastAPI vagy CI/CD pipeline-ba.
• Beépített SQL cellák dolgoznak DuckDB, Polars, Pandas, Postgres és SQLite backendekkel, a lekérdezés eredménye automatikusan DataFrame lesz.
• A marimo run notebook.py paranccsal a notebook azonnal deployolható webappként, a szerkesztő UI eltűnik, csak az interaktív widgetek és outputok maradnak.
• A marimo convert your.ipynb > your.py automatikusan importálja a meglévő Jupyter notebookokat, de a reaktív szemantikára át kell írni a kódot.
• 2026-ban a Marimo integrálódik Claude Code-dal (marimo pair) és beépített sandbox-alapú csomagkezeléssel bír, ami reprodukálható virtuális környezetet biztosít cellánként.

Mi az a Marimo és miért érdemes használni?

Backend fejlesztőként érkeztem az adatelemzés világába, és őszintén szólva a Jupyter notebookokat évekig kerültem. A JSON-formátum, a rejtett állapot és a "működik nálam" reprodukálhatóság mind olyan problémák, amelyeket egy FastAPI végpontnál soha nem tolerálnék. Amikor először láttam a Marimót, azt éreztem, amit egy pydantic modell látásakor: valaki végre komolyan vette a fegyelmezett Python fejlesztés alapelveit egy notebook környezetben.

A Marimo egy 2023 augusztusában elindult, jelenleg aktívan fejlesztett projekt, amely a Stanford Computational Neuroscience Lab-ból nőtt ki, és Apache 2.0 licenc alatt érhető el. A projekt központi ígérete egyszerű: egy notebook, amely tiszta Python fájlként él, reaktívan végrehajtódik, és production-ready alkalmazásként deployolható. Ez három olyan tulajdonságot ötvöz, amelyek eddig három különböző eszközt igényeltek (Jupyter, Streamlit és Papermill).

Miért fontos ez? Egy 2019-es tanulmány szerint a GitHubon lévő Jupyter notebookok több mint 75%-a egyáltalán nem fut le, és 96%-uk nem reprodukálható. Ez nem csupán elméleti probléma. Data engineerként rendszeresen találkozom olyan üzleti riportot generáló notebookkal, amelyet senki nem mer újrafuttatni, mert nem tudja, milyen sorrendben kell végrehajtani a cellákat. A Marimo ezt a problémát a gyökerénél oldja meg: a végrehajtási sorrendet a változóhivatkozásokból származó DAG határozza meg, nem a cellák pozíciója.

Hogyan működik a Marimo reaktív végrehajtása?

A Marimo reaktív végrehajtása statikus kódanalízisen alapszik: a Marimo Python parser-e (a ast modul felett) minden cellához meghatározza, hogy milyen globális változókat definiál és milyeneket használ. Ezekből felépít egy irányított körmentes gráfot (DAG). Amikor egy cellát futtatsz, a Marimo lekérdezi a DAG-ot, és topológiai sorrendben lefuttatja az összes érintett leszármazottat, hasonlóan ahhoz, ahogy egy táblázatkezelőben egy cella módosítása minden ráépülő cellát újraszámol.

Nézzünk egy konkrét példát:

# Cell 1
import polars as pl
df = pl.read_csv("sales_2026.csv")

# Cell 2
filtered = df.filter(pl.col("revenue") > 1000)

# Cell 3
summary = filtered.group_by("region").agg(pl.col("revenue").sum())

Ha a Cell 1-ben átírod a CSV elérési útját, a Marimo automatikusan újrafuttatja a Cell 2-t és a Cell 3-at is, mert mindkettő a df-ből származik. Jupyterben ehhez kézzel kellene végigmenned a "Run All Below" opción, és jó eséllyel el is felejtenéd (én az utolsó heti riportnál pontosan ezért kaptam hibás számot).

Két kényszerítő szabály tartja fenn a modell integritását. Először, egy globális változót pontosan egy cellában lehet definiálni, hogy különböző cellák ne írhassák felül egymást váltakozó sorrendben. Másodszor, körkörös függőségek nem megengedettek: ha A cellának B kell, és B-nek A, a Marimo hibaüzenetet ad, nem csendben rossz eredményt. Ez a két megszorítás elsőre kényelmetlennek tűnhet, de pontosan ez az, ami eltünteti a rejtett állapotot.

Nagy notebookok esetén a reaktív futás drága lehet. Erre a Marimo két megoldást kínál: lazy mód, amelyben a függő cellák csak "stale" jelzést kapnak és kézzel kell futtatni őket; illetve mo.stop(), amellyel korai kilépést lehet elhelyezni egy cellában.

Telepítés, első notebook és a molab

A Marimo telepítése egyetlen parancs, és a virtuális környezetre vonatkozó szokásos best practice-ek érvényesek. Én uv-t használok 2026-ban, ami villámgyors:

# uv-vel (ajánlott 2026-ban)
uv pip install marimo

# vagy hagyományos pip-pel
pip install marimo

# vagy conda-forge-ról
conda install -c conda-forge marimo

Új notebook létrehozása és megnyitása:

# Új notebook indítása
marimo edit sales_analysis.py

# Beépített tutorial (nagyon jó a kezdéshez)
marimo tutorial intro

# SQL tutorial
marimo tutorial sql

A böngésződben megnyílik a Marimo szerkesztő. Az első pillanattól látni fogsz egy különbséget a Jupyterhez képest: a cellák sorrendje nem determinálja a végrehajtást. Nyugodtan tedd a helper függvényeidet a notebook aljára, a df.head() preview-t pedig a tetejére, a Marimo úgyis a DAG szerint futtatja őket.

Ha nem akarsz semmit installálni, próbáld ki a molab-ot, a Marimo hivatalos böngészőben futó ingyenes környezetét. Ez egy Google Colab-szerű szolgáltatás, ahol egy URL-lel megoszthatók a notebookok, és .py, .ipynb vagy PDF formátumba exportálhatók.

Mi a különbség a Marimo és a Jupyter között?

A leggyakoribb kérdés, amit backend fejlesztő kollégáktól hallok: "megéri váltani?" A választ az alábbi összehasonlító táblázatba sűrítettem. Ezek nem elméleti különbségek, mindegyiket production data pipeline-ban futottam.

Jellemző	Marimo	Jupyter
Fájlformátum	Tiszta Python (.py)	JSON (.ipynb)
Verziókezelés (git diff)	Olvasható diff, code review-zható	JSON-diff nyomkövethetetlen; jupytext szükséges
Végrehajtási modell	Reaktív DAG (változófüggőség alapján)	Top-down cell sorrend + kézi újrafuttatás
Rejtett állapot	Nincs (cella törlése törli a változóit)	Gyakori (törölt cella változói memóriában maradnak)
Interaktív widgetek	Beépített, reaktív mo.ui	ipywidgets, extra setup
SQL támogatás	Natív SQL cellák, backend-választással	Külső bővítmények (pl. jupysql)
App deploy	marimo run, beépített	Külön eszköz (Streamlit, Voilà, Panel)
Scriptként futtatás	python notebook.py, közvetlen	Papermill vagy nbconvert szükséges
Reprodukálhatóság	DAG + sandbox venv beépítve	Kézi requirements.txt kezelés
AI integráció (2026)	marimo pair, Claude Code natív	JupyterAI extension

Fontos árnyalat: a Jupyter érett ökoszisztémája (JupyterLab, ipywidgets, papermill, kernelek) még mindig hatalmas előny bizonyos munkafolyamatokban, különösen ha R vagy Julia kerneleket használsz, vagy a JupyterHub-alapú, több felhasználós szervezeti telepítésre építesz. A Marimo kizárólag Python.

SQL cellák: DuckDB, Polars és Postgres a Marimo-ban

Az egyik funkció, amivel a Marimo elnyerte a tetszésemet, a natív SQL cellák. Backend munkában folyton váltogatnék SQL és Python között, és a Marimo pontosan ezt oldja meg: mo.sql() egy Python cellában, amely visszaad egy DataFrame-et. A lekérdezés hivatkozhat Python változókra, és reaktív, tehát a UI változásoktól automatikusan újrafut.

import marimo as mo
import polars as pl

# Töltsünk be egy DataFrame-et
sales = pl.read_parquet("s3://my-bucket/sales_2026.parquet")

# SQL cella, a Polars DataFrame-et táblaként hivatkozzuk
result = mo.sql(
    f"""
    SELECT region,
           SUM(revenue)  AS total_revenue,
           COUNT(*)      AS orders
    FROM sales
    WHERE order_date >= '2026-01-01'
    GROUP BY region
    ORDER BY total_revenue DESC
    """
)

# A `result` egy Polars DataFrame, közvetlenül továbbadható
result.head()

A háttérben alapértelmezetten DuckDB fut, amely a memóriában lévő DataFrame-eket automatikusan táblaként exponálja. Ez egyben azt is jelenti, hogy a DuckDB és Pandas integráció Pythonban minden előnyét megkapod egy notebookban is: streamelt Parquet-olvasás, S3-integráció, oszloporientált tárolás. Postgres, MySQL vagy SQLite csatlakozáshoz csak egy Python-oldali connection stringet kell definiálni, és a mo.sql() a helyes engine-t választja ki.

Ha a fő adatlekérdezési munkafolyamatod a Polars köré épül, a Marimo SQL cellái elegánsan együttműködnek a Polars LazyFrame-alapú query optimization-nal: a végeredményt lazy módban tarthatod, és csak a .collect() hívja ki az execution-t.

Interaktív UI elemek: slider, dropdown, dataframe transformer

A Marimo a mo.ui namespace-en keresztül biztosítja az interaktív widgeteket. Ezek reaktívan összekötöttek a Python változókkal, ha csúsztatsz egy slidert, minden érintett cella újra fut a friss értékkel. Nincs szükség callback-ekre, event handlerekre, ipywidgets observer-ekre.

import marimo as mo
import polars as pl

# Interaktív slider a küszöbértékre
threshold = mo.ui.slider(
    start=0, stop=10000, step=500, value=1000,
    label="Bevételi küszöb ($)"
)
threshold  # a widget megjelenik a cellában

# Egy másik cellában:
filtered = df.filter(pl.col("revenue") > threshold.value)
mo.ui.table(filtered)   # interaktív, kereshető táblázat

A slider mozgatásával az alsó cella azonnal frissül. A mo.ui.table egy önálló táblázatnézetet ad, sortöréssel, kereséssel és exporttal, mindezt anélkül, hogy Streamlitre vagy Plotly Dash-re volna szükség. Elérhető widgetek közé tartozik: slider, dropdown, multiselect, date, file (feltöltés), chat (LLM interfész), refresh, és a dataframe transzformer, ami no-code stílusban ad szűrő/csoportosító UI-t egy DataFrame felett.

A widgetek reaktivitása mögötti trükk az, hogy a threshold.value hivatkozás a DAG-ban függést hoz létre magára a widgetre, így amikor a felhasználó változtat, a lefelé irányuló cellák értesülnek róla. Backend fejlesztőknek ez ismerős lesz: valójában egy observable/signal pattern-t implementál, csak deklaratív módon.

Notebook mint alkalmazás: deploy marimo run-nal

Ez a funkció volt az, ami átbillentett a Marimo használatába a saját projekteimben. Régen a Jupyter notebookot végigfejlesztettem, majd Streamlit-re vagy FastAPI-ra portoltam a UI-t. A Marimo ezt a lépést kiiktatja:

# A notebook indítása app módban (a szerkesztő UI eltűnik)
marimo run sales_dashboard.py

# Portra bindolás és host beállítás production Docker konténerben
marimo run sales_dashboard.py --host 0.0.0.0 --port 8080

# Konténerbe csomagolva:
# Dockerfile
# FROM python:3.13-slim
# COPY sales_dashboard.py .
# RUN pip install marimo polars duckdb
# CMD ["marimo", "run", "sales_dashboard.py", "--host", "0.0.0.0"]

A háttérben ilyenkor a Marimo egy uvicorn-alapú ASGI szervert indít, ami WebSocket-en tartja a kapcsolatot a böngészővel, pontosan úgy, mint egy FastAPI app. Ha eddig FastAPI-val ML endpointot deployoltál, a mentális modell ugyanaz: a notebook = alkalmazás. Ha a következő lépés a modell szervírozása egy REST endpointon keresztül, olvasd el a részletes FastAPI ML modell deployment útmutatót.

Fontos, hogy app módban a Marimo elrejti a szerkesztő UI-t, de a reaktivitás megmarad: a felhasználó widget-műveletei ugyanúgy triggerelik a függő cellák újrafuttatását. Ez egyenértékű egy tiszta Streamlit alkalmazással, csak nincs kettős kódbázis.

Hogyan migráljunk Jupyter notebookról Marimóra?

A Marimo hivatalos konverzió-eszközt biztosít, amely egy .ipynb fájlt átalakít Marimo-kompatibilis Python fájllá:

# Egy notebook konvertálása
marimo convert my_notebook.ipynb > my_notebook.py

# Batch konverzió több fájlra
for nb in *.ipynb; do
    marimo convert "$nb" > "${nb%.ipynb}.py"
done

# Konvertálás után szerkesztés indítása
marimo edit my_notebook.py

A konverzió mechanikus: átveszi a cellákat, a markdownokat, a magic parancsokat próbálja hatályosítani. De ez csak az első lépés. A reaktív szemantikához kézzel át kell nézni a kódot, mert a következő minták nem működnek:

1. Változó újradefiniálása több cellában. Egy Jupyter notebookban gyakori a df = df.dropna()-szerű mintázat több cellán át. Marimo-ban minden globális változó pontosan egy cellához tartozik. Nevezd el kaszkádolt DataFrame-jeidet (df_clean, df_featured).
2. Mutációk helyett tiszta transzformációk. A df["new_col"] = df["a"] + df["b"] típusú mutációkat cseréld le df.assign(new_col=...) vagy df.with_columns(...) hívásokra.
3. Körkörös függőségek. Ha két cella egymás változóit használja, a Marimo panaszkodni fog. Vagy vond össze őket, vagy húzz be egy közös alap-cellát.

Az én tapasztalatom szerint egy 30 cellás Jupyter notebook migrálása 20-40 perc között van (a legtöbb idő az újradefiniálások kigyomlálása). A visszaút is támogatott: marimo export ipynb my_notebook.py visszaad egy Jupyter fájlt.

Sandbox csomagkezelés és reprodukálhatóság

A Marimo egyik erős funkciója a 2026-os verziókban a sandbox mode. A notebook maga tartalmazza a függőségeket PEP 723 script metadata formájában, és a Marimo automatikusan létrehoz egy izolált virtuális környezetet uv-val, amikor a notebook megnyílik.

# Notebook fájl teteje: PEP 723 metadata blokk
# /// script
# requires-python = ">=3.13"
# dependencies = [
#     "polars==1.20.0",
#     "duckdb==1.2.0",
#     "marimo>=0.10.0",
# ]
# ///

import polars as pl
import duckdb
import marimo as mo

Amikor ezt a fájlt átküldöd egy kollégának, elég a marimo edit --sandbox notebook.py parancs, és a Marimo lokálisan felépít egy virtualenv-et pontosan ezekkel a verziókkal, majd futtatja. Nincs requirements.txt szinkronizálás, nincs "nálam ment" hibaüzenet. Ez a megoldás megfelel a PEP 723 script inline metadata szabványnak, tehát nemcsak Marimo, hanem bármely PEP 723-tudatos toolchain (pl. pipx run) is felismeri.

Ez a funkció Docker nélkül is reprodukálhatóvá teszi az elemzéseket. Data engineerként számomra ez a legfontosabb érv a Jupyterrel szemben: egy notebookot le lehet tenni egy git clone után, és garantált, hogy egy fél év múlva is fut.

Mikor NE használd a Marimót?

Nem minden esetben a Marimo a helyes választás. Nézzük őszintén a korlátait:

• Nem-Python kernelek. Ha R, Julia vagy Scala kerneleket használsz, a Jupyter/JupyterLab az egyetlen valós opció. A Marimo szigorúan Python-only.
• Nagyon nagy, incremental, drága számítások. A reaktív végrehajtás gyors visszajelzés esetén ragyog, de ha egyetlen cella futása 30 perc, a lazy mód elengedhetetlen, és akkor is jó megfontolni, hogy a folyamat inkább egy dbt Python model + Snowpark pipeline-ban kap otthont.
• JupyterHub-alapú, több felhasználós szervezeti telepítés. A Marimo nem kínál multi-tenant környezetet a doboz szintjén; ehhez saját deployment-et kell építeni.
• Kliens által elvárt .ipynb output. Ha az üzleti fél Google Colab-ban vagy Databricks notebookban vár egy fájlt, a Marimo marimo export ipynb parancsa segít, de nem minden interakció konvertál át tökéletesen.

Az én ökölszabályom: új, Python-only data science és ML projekthez alapértelmezés szerint Marimo; meglévő, nagy Jupyter-alapú kódbázisokban fokozatos migráció, kezdve az újonnan írt notebook-okkal. További részletek a Marimo hivatalos Marimo dokumentációjában találhatók, a source pedig a marimo-team/marimo GitHub repository-ban.

Gyakran Ismételt Kérdések

Ingyenes a Marimo?

Igen, a Marimo teljesen ingyenes és nyílt forráskódú, az Apache 2.0 licenc alatt érhető el a GitHubon. A hivatalos cloud szolgáltatás, a molab, szintén ingyenes; hasonlóan működik a Google Colab-hoz, és böngészőből fut mindenféle telepítés nélkül.

Használhatok Jupyter notebookjaimat közvetlenül Marimóban?

Nem közvetlenül, de a marimo convert my.ipynb > my.py parancs automatikusan átalakítja őket. A konverzió a szintaktikai átalakítást elvégzi; kézi átnézés kell a reaktív szemantika betartására, például minden globális változót csak egy cellában szabad definiálni, és a DataFrame mutációkat tiszta transzformációkra kell cserélni.

Támogatja a Marimo az SQL lekérdezéseket?

Igen, a Marimo natív SQL cellákkal érkezik, amelyek DuckDB-t, Polars-t, Pandas DataFrame-eket, Postgres-t, MySQL-t és SQLite-ot támogatnak backendként. Az mo.sql() hívás egy lekérdezés eredményét DataFrame-ként adja vissza, és a query hivatkozhat Python változókra. A reaktivitás automatikusan újrafuttatja a lekérdezést, ha a paraméterek változnak.

Hogyan deployolhatom a Marimo notebookot alkalmazásként?

A marimo run notebook.py paranccsal egyetlen lépésben webappként indíthatod. A háttérben egy ASGI szerver fut (uvicorn), így --host 0.0.0.0 --port 8080 paraméterekkel Docker konténerbe csomagolható, és bármely container platformra (Fly.io, Cloud Run, Kubernetes) deployolható. Nem kell külön Streamlit vagy Flask kód.

Mi a különbség a Marimo reaktív végrehajtása és a Jupyter kézi cellafuttatása között?

A Jupyter cellák sorrendjét a felhasználó adja meg, és egy változó módosítása nem frissíti automatikusan az attól függő cellákat. A Marimo statikus kódanalízissel felépít egy DAG-ot a változóhivatkozásokból, és minden módosításnál automatikusan újrafuttatja az érintett cellákat, mint egy Excel táblázat képletei. Ez megszünteti a rejtett állapotot és a "milyen sorrendben futtattam a cellákat?" reprodukálhatósági problémát.