How to choose a notebook or data app tool

This category covers two related but different jobs: notebooks, where you explore data and write code interactively, and data-app frameworks, where you turn a script into something a non-technical person can open and use. Some tools do both. Before comparing features, decide which job you are actually buying for — a tool tuned for exploratory analysis and a tool tuned for shipping a polished internal app optimize for different things, and the wrong choice shows up as friction six months in, not on day one.

The execution model is the real dividing line

• The Jupyter standard. Project Jupyter defines the open .ipynb notebook format and the interfaces (classic Notebook, JupyterLab) that read and write it, against a language kernel — Python via IPython most commonly, but also R, Julia, and others. It ships no cloud service itself; you run it locally, on a self-managed JupyterHub, or through a third-party host that implements the same format. Its ubiquity makes .ipynb the de facto interchange standard the rest of this category is measured against.
• Jupyter-compatible hosted notebooks. Google Colab, Kaggle Notebooks, Deepnote, and Datalore all speak the same .ipynb-derived format but add hosting and something distinctive: Colab adds free, non-guaranteed GPU/TPU access with zero setup; Kaggle adds a weekly GPU/TPU quota tied directly to its own datasets and competitions; Deepnote adds real-time multi-user collaboration and shared, reusable data connections built for teams rather than solo use; Datalore adds JetBrains-style code intelligence (completion, inspections, refactoring) plus an on-premises edition for organizations that need data residency.
• Reactive notebooks that rerun automatically. marimo stores itself as a plain, git-diffable .py file rather than JSON, and treats the notebook as a dependency graph: change a cell and every dependent cell reruns automatically, while marimo detects and blocks the stale, out-of-order execution that causes hidden bugs in traditional notebooks. Observable applies the same reactive idea to JavaScript, built around D3.js for web-native, interactive visualization rather than general-purpose data science scripting.
• Code-first publishing, not interactive exploration. Quarto and Evidence both start from plain-text source (Markdown plus code, or SQL plus Markdown) and compile it into a finished artifact — a paper, report, dashboard, or site — designed to be reviewed in a pull request and diffed like any other code, rather than edited live in a browser session.
• Scripts turned into apps, not notebooks at all. Streamlit, Dash, and Gradio take a Python script and produce an interactive web app. Streamlit reruns the whole script top to bottom on every input change, which is fast to write but can get unwieldy for complex, multi-page interfaces; Dash uses an explicit layout tree and declared callbacks, closer to a conventional web app, which suits complex or highly customized interfaces better; Gradio is scoped narrowly to wrapping a single function or model in an input/output UI, most often for demoing a machine-learning model.

Reproducibility is not automatic

Traditional Jupyter notebooks let you run cells out of order, leaving hidden state that the saved .ipynb file doesn't reflect — a notebook that "works" on your machine can fail the moment someone else reruns it top to bottom. marimo exists specifically to close that gap through its reactive execution model, and because a marimo notebook is a plain .py file it can also be run as a script or tested with standard Python tooling like pytest. Quarto and Evidence sidestep the problem differently, by making the artifact a rendered output of a full, top-to-bottom recompile rather than a saved interactive session. If reproducibility across a team is the actual pain point, weigh that more heavily than collaboration features.

Who is going to open the output

A notebook a data scientist explores alone has different requirements than a report a business stakeholder consumes. Deepnote and Datalore are built for teams working in the notebook together, with presence, comments, and shared connections. Quarto and Evidence are built to hand a finished, non-interactive-but-polished document to someone who will never see a code cell. Streamlit and Dash sit in between: the audience interacts with widgets and filters but never touches the underlying script. Match the tool to the reader, not to how you personally prefer to write code.

Hosting and compute

Google Colab, Kaggle Notebooks, and Deepnote run only in their own cloud — there is no self-hosted option for any of them. Project Jupyter, marimo, Quarto, Streamlit, Dash, and Gradio are all free to self-host, though several also offer an easier managed path — Streamlit Community Cloud and Streamlit in Snowflake, Hugging Face Spaces for Gradio. Posit Workbench is the outlier built specifically for centralized hosting: a commercial server that runs RStudio, Jupyter, and VS Code sessions for many data scientists on shared, IT-administered infrastructure with SSO/LDAP and per-session resource limits, typically deployed on-premises or in a customer's own cloud VPC rather than sold as public SaaS.

How pricing works

Free GPU/TPU-backed notebooks (Colab, Kaggle Notebooks) are funded as loss-leading or platform products rather than priced directly, with usage bounded by quotas instead of a bill. Team-oriented hosted notebooks (Deepnote, Datalore) price per editor or user with a free tier for small teams. The open-source, self-hostable tools (Jupyter, marimo, Quarto, Streamlit, Dash, Gradio) are free to run yourself; their commercial layers — Evidence Cloud, Dash Enterprise, Hugging Face Spaces' paid tiers, Streamlit in Snowflake — charge for managed hosting, scheduling, access control, or compute rather than for the core framework. Posit Workbench is licensed per user on negotiated enterprise contracts, typically bundled with Posit's other publishing products. No prices are reproduced here; check each tool's profile for current, dated figures.

A shortlist by situation

• Free GPU-backed notebooks for learning or prototyping, no local setup: Google Colab generally, or Kaggle Notebooks if you're already working with Kaggle datasets or competitions.
• A team that wants to collaborate on notebooks in real time with shared data connections: Deepnote.
• You want Jupyter with better refactoring and code intelligence, or need an on-premises option: Datalore.
• Reproducibility and hidden-state bugs are the actual problem: marimo.
• You need centrally administered, multi-user R/Python session infrastructure for a whole data-science team: Posit Workbench.
• You want git-versioned, SQL-and-Markdown reports reviewed like code, without a drag-and-drop BI tool: Evidence; for narrative documents, papers, or multi-format publishing, Quarto.
• You want to ship a data app quickly with pure Python: Streamlit for speed, Dash for a structured multi-page app, Gradio for a quick demo UI around a model.
• Building custom, web-native interactive graphics for a public audience: Observable.

Questions to ask in a trial

1. Does the tool run only in the vendor's cloud, or can we self-host if requirements change later?
2. What happens when a notebook is rerun top to bottom by someone else — does it reproduce the same result?
3. If this needs to be a shared team workspace, how are data connections and secrets shared without duplicating credentials per person?
4. What compute limits exist on the free or entry tier, and what do we actually need for our datasets?
5. If we outgrow the free/individual tier, what does the next tier cost per editor, and does it include the collaboration or scheduling features we actually need?

Common mistakes

• Picking a solo-exploration notebook for a job that is really about publishing a report to non-technical stakeholders, then hand-building a presentation layer on top of it.
• Assuming a Jupyter-compatible tool guarantees reproducibility — the format is compatible; the hidden-state problem is not solved by any of Colab, Kaggle, Deepnote, or Datalore.
• Standardizing on a free-tier cloud notebook for production workloads and discovering the compute quotas were never meant for that.
• Building a Streamlit or Dash app for outside customers without checking the deployment story — both are easiest to ship internally; customer-facing deployment usually means self-hosting or a paid managed tier.

See Google Colab vs Jupyter, Jupyter vs marimo, and Dash vs Streamlit, or browse every tool in this category.