Why ML Engineers love marimo notebooks

Machine learning development has a dirty secret: our tools are lacking. We’ve made incredible advances in algorithms and compute but we’re still wrestling with notebooks that crash mysteriously. Models that work on my machine but not yours. Your teammate can’t reproduce your results because Jupyter executed cells in a different order. Your git history is cluttered with .ipynb files that show every metadata change as a massive diff. The frustration is real.

marimo notebooks represent a fundamental shift in how we think about interactive computing for ML. Built from the ground up to rethink traditional notebooks, marimo brings engineering discipline to data science without sacrificing the exploratory nature that makes notebooks powerful.

Self-contained notebooks that actually work

Traditional notebooks suffer from hidden state problems. You modify a variable in cell 5, forget to re-run cell 8, and suddenly your model is training on yesterday’s data preprocessing. The notebook looks correct, but the execution state can tell a different story. marimo eliminates this feeling through reactive execution. When you change a cell, marimo automatically runs all downstream cells that depend on it. This isn’t just convenience-it’s a fundamental guarantee that your notebook’s visual state matches its execution state. No more stale variables, no more mysterious bugs that disappear when you restart and run all cells.

The benefits compound when you’re iterating rapidly. Experimenting with different architectures, trying new feature combinations, or adjusting data augmentation strategies becomes fluid. You can trust that every change ripples through your pipeline correctly, without the mental overhead of tracking cell dependencies.

git is much clearer in marimo

Git and Jupyter notebooks have a troubled relationship. If you’re not careful, the JSON structure of .ipynb files creates diffs filled with execution counts, output metadata, and cell UUIDs. Reviewing a colleague’s changes becomes an exercise in finding the actual code changes among the noise. There are tools and workflows that help mitigate this, but maybe it’s time to work with Python notebooks that use a pure Python approach.

marimo notebooks are pure Python files. That means that diffs in git show exactly what changed in your analysis logic. Code reviews focus on the substance of your work, not the formatting artifacts of your notebook environment.

This isn’t just about cleaner git history. Better software engineering practices for ML development lead to less bugs. You can use the same code review processes, branching strategies, and collaboration workflows that work for traditional software. Pull requests become meaningful discussions about modeling approaches and data analysis techniques. Code reuse becomes natural when notebooks are just Python modules. Building shared libraries of preprocessing functions, model architectures, and evaluation metrics flows naturally from this approach.

Fewer ML bugs through better architecture

Hidden state can break your pipeline. These issues compound as notebooks grow larger and more complex. What starts as a simple exploration becomes a brittle stack of interdependent cells unless you know what you’re doing.

marimo doesn’t use traditional cells that can run in arbitrary order and instead uses a reactive execution model. This might sound like a small change but it eliminates entire categories of bugs. Since cells can be configured to automatically re-execute when their dependencies change, you can’t accidentally use stale data or inconsistent variable states. The execution order is determined by the actual data dependencies in your code, not the arbitrary order you happened to run cells.

This architectural difference shows up in subtle but important ways. When you’re debugging a model that’s not converging, you can trace the data flow through your notebook. When a variable is missing from the file, marimo will warn you about it immediately. When you’re comparing different preprocessing approaches, you know each variant is using the current version of your data loader. When you’re sharing results with stakeholders, you can trust that the visualizations reflect the current state of your analysis.

The error messages are clearer too. Circular dependencies are caught early and missing imports are immediately obvious.

SQL, dataframes and data-sources

Modern ML doesn’t just use .csv files anymore. Your training data lives might live Snowflake, your raw data in Apache Iceberg, and your real-time features come from Postgres. Traditional notebooks force you to juggle connection strings and query results across multiple cells, while marimo offers direct integration for most popular datasources.

Everything that marimo does is powered by Python under the hood, but marimo can talk SQL too. You can write SQL directly in notebook cells, with results automatically flowing into DataFrame outputs. The reactive execution ensures that when you modify a SQL query, all downstream analysis updates immediately. No more copying and pasting connection code or managing database credentials in every cell. This integration transforms how you explore data sources. Instead of switching between SQL clients and Python notebooks, you can iterate on queries and analysis in the same environment. Feature engineering becomes fluid when you mix and match widgets with our SQL transformations and immediately see the impact on your model training. Data quality investigations happen faster when you can drill down from aggregate statistics to raw records without context switching.

The benefits compound when working with multiple data sources. You can join streaming data with historical features, combine structured data with embeddings, and prototype complex feature pipelines without leaving your analysis environment. Authentication is handled once per session, and connection pooling ensures your queries run efficiently even when iterating rapidly.

The future of Python notebooks

Marimo represents more than incremental improvement—it’s a rethinking of what interactive computing should look like for serious ML development. By addressing the fundamental problems of traditional notebooks, marimo enables ML engineers to work with the same reliability and collaboration practices as other software disciplines.