Cloud Parts

Apache Zeppelin

A self-hosted web notebook where each paragraph runs through an interpreter: Spark, Flink, JDBC, Python and more. Maintained, but behind Jupyter and Databricks in reach.

Type
Open source
License
Apache 2.0
Facts checked
6 October 2026

What it is

A Zeppelin server is a Java web application: you open notes in the browser, and each note is a list of paragraphs that start with an interpreter name such as %spark.sql, %flink, %jdbc or %python. The server doesn’t run your code itself. Each interpreter group (for example Spark, which bundles Scala, PySpark, IPySpark, SparkR and Spark SQL) runs in its own JVM process and talks to the server over Thrift; binding modes decide whether all users share one interpreter process or get one per user or per note. Results come back as text, HTML or tables that the notebook draws as charts without extra code, and notes can run on a built-in cron schedule or be created and run through a REST API.

Zeppelin is free under Apache 2.0 and you host it yourself; the official image is apache/zeppelin. It is not retired: 0.12.0 (January 2025) introduced a new UI, 0.12.1 followed in June 2026, and commits land almost daily. But the project reports only moderate activity, its interpreters trail the engines (support for Spark 4.1 and 4.2 is still an open ticket), and JDK 17 support is planned for 0.13.0. In the cloud it lives on mostly inside other products: Amazon EMR installs Zeppelin 0.11.1, and Studio notebooks in Amazon Managed Service for Apache Flink are powered by it.

Why teams pick it

  • One notebook mixes engines: a Spark SQL paragraph, a Flink streaming query and a JDBC query against PostgreSQL can sit side by side
  • Built-in charts and dynamic forms turn SQL results into simple dashboards without writing plotting code
  • Interpreters run in separate processes per user or per note, with Shiro authentication and note permissions for shared servers
  • Can also run Jupyter kernels through its Jupyter interpreter, and exposes a REST API for creating and running notes

Watch out for

  • Insecure by default: anonymous access is allowed until you configure Shiro, and the April 2026 board report mentions outstanding security issues under investigation
  • Interpreters lag their engines: Spark 4.1 and 4.2 support is still open, the Flink interpreter needs Flink 1.15 or later, and JDK 17 support is planned for 0.13.0
  • Outside the Spark and Flink niche, Jupyter is the broader tool: its kernels cover dozens of languages, which Zeppelin itself reaches only by bridging to Jupyter kernels
  • Mostly self-run: you deploy, upgrade and secure the server and each interpreter; AWS embeds it in EMR and Managed Service for Apache Flink, at older versions (EMR 7.14 ships 0.11.1)
  • Several interpreters were removed in 0.11 (Beam, Scio, ksqlDB, Kotlin, Lens), so old notes can stop working after an upgrade

Alternatives

What all query engines have in common →
Amazon AthenaAWSAWS’s serverless SQL engine for data in S3: no cluster to run, and on-demand queries cost $5 per TB scanned.Apache Arrow AceroExperimentalOpen sourceThe streaming execution engine inside Arrow’s C++ library: you hand it an exact plan of nodes (scan, filter, project, aggregate, join, sort) and it streams Arrow record batches through them, with no SQL parser or optimizer of its own.Apache CalciteOpen sourceA Java framework with everything a database needs to understand a query (SQL parser, validator, relational algebra and a rule-based, cost-based optimizer) but no storage of its own, which Hive, Flink, Druid, Dremio, Beam and many other systems embed as their SQL front end and planner.Apache DataFusionOpen sourceA query engine library in Rust, built on Arrow, that other projects embed and extend to build their own databases and data tools.+1 Apache DataFusion CometApache HadoopOpen sourceThe project that made big-data clusters normal: a distributed file system (HDFS), a cluster scheduler (YARN) and the MapReduce engine.Apache HiveOpen sourceThe first SQL engine for Hadoop, and the source of the Hive Metastore, the table catalog that Trino, Spark, Impala and Flink still read.Apache ImpalaOpen sourceAn MPP SQL engine in C++ for interactive queries over Hive tables on HDFS, Kudu, Iceberg and object storage; built and mainly sold by Cloudera.Apache PigDormantOpen sourceA step-by-step scripting language, Pig Latin, that compiles to MapReduce, Tez or Spark jobs on Hadoop. Still released, but the project calls itself dormant.Apache SparkOpen sourceThe general-purpose distributed engine for large batch jobs, streaming and machine learning, in Python, SQL, Scala, Java or R.chDBOpen sourceThe ClickHouse engine packaged as a library: run ClickHouse SQL inside a Python, Go, Rust or Node.js program, with no server.Cloudflare Basin SQLRenamedCommercialCloudflare’s serverless, distributed SQL engine for Apache Iceberg tables in Basin Catalog on R2, called R2 SQL until it became generally available on 1 October 2026, billed by the data it scans.DuckDBOpen sourceAn in-process analytical SQL database: a library with no server that queries Parquet, CSV, Iceberg and S3 directly.GizmoSQLOpen sourceA database server that wraps DuckDB (or SQLite) and serves it to many clients over Arrow Flight SQL, with TLS and authentication.GlareDBDormantOpen sourceA small, embeddable SQL engine in Rust for querying Parquet and CSV files locally, over HTTP or in S3 and GCS, from a CLI, Python or the browser. It began as a DataFusion-based federated query service and was rewritten in 2025 on its own engine, and it has had no release since June 2025.HotdataCommercialA managed SQL engine for AI agents, built in Rust on Apache DataFusion and Arrow: each agent gets short-lived “instant databases” to load data into, then runs read-only SQL, vector, full-text and geospatial queries over an HTTP API or CLI.IbisOpen sourceA Python dataframe API that compiles to SQL, so the same code runs on DuckDB on a laptop and on BigQuery, Snowflake, PostgreSQL or more than 20 other engines.PolarsOpen sourceA DataFrame library with a Rust query engine underneath: you write Python (or Rust, SQL, Node.js, R) and it plans, optimises and runs the query on every core, streaming data bigger than memory.Presto (PrestoDB)Open sourceFacebook’s distributed SQL engine, now governed by the Linux Foundation, moving its workers from Java to C++ on Velox. Trino is its 2019 fork.RayforceOpen sourceA small embeddable engine in pure C that runs columnar analytics, graph traversals and recursive Datalog queries in one optimised plan.Spice.ai OSSOpen sourceA single-binary SQL engine in Rust, built on DataFusion and Arrow, that federates queries across databases, warehouses and lakes, keeps hot datasets in a local accelerated copy, and adds search and LLM APIs on top.TrinoOpen sourceA distributed SQL engine that queries data where it lives, from Iceberg tables on S3 to a live PostgreSQL database, in one query.VeloxOpen sourceMeta’s open-source C++ execution engine library: it takes an already-optimized query plan and runs it with vectorized operators, and it is the engine inside Presto’s C++ workers (Prestissimo) and Apache Gluten’s native Spark.

How it fits with other technologies

Start Zeppelin with a local Spark, then create and run a note over the REST API · bash

docker run -d -u $(id -u) -p 8080:8080 --name zeppelin \
  -v /usr/lib/spark-3.5.1:/opt/spark -e SPARK_HOME=/opt/spark \
  -v "$PWD/notebook:/notebook" -e ZEPPELIN_NOTEBOOK_DIR=/notebook \
  apache/zeppelin:0.12.1

# a note with two paragraphs: build a view in Scala, chart it with Spark SQL
cat > note.json <<'EOF'
{ "name": "orders/daily",
  "paragraphs": [
    { "title": "load", "text": "%spark\nspark.range(1, 1000).selectExpr(\"id % 7 AS weekday\", \"id AS amount\").createOrReplaceTempView(\"orders\")" },
    { "title": "chart", "text": "%spark.sql\nSELECT weekday, sum(amount) AS total FROM orders GROUP BY weekday ORDER BY weekday" }
  ] }
EOF

NOTE=$(curl -s -X POST localhost:8080/api/notebook -d @note.json | jq -r .body)
curl -s -X POST localhost:8080/api/notebook/job/$NOTE     # run all paragraphs
open "http://localhost:8080/#/notebook/$NOTE"               # see the bar chart

Zeppelin, Jupyter or Databricks notebooks?#

All three put code, results and notes in one page. They differ in who runs them and how many languages and engines one notebook can mix.

Apache ZeppelinJupyter (JupyterLab, JupyterHub)Databricks notebooks
Licence and hostingApache 2.0, self-hostedBSD-3-Clause, self-hostedProprietary, part of the Databricks platform
LanguagesPer paragraph, through interpreters: Spark (Scala, Python, R, SQL), Flink, JDBC, Python and moreOne kernel per notebook; kernels exist for dozens of languagesPython, SQL, Scala and R
Where code runsInterpreter processes next to the server, or on Spark and Flink clustersA kernel process per notebook (IPython by default), on a laptop or a serverDatabricks compute in your workspace
Many usersOne server with Shiro login and note permissionsJupyterHub gives each user their own serverReal-time coauthoring and automatic versioning
ChartsBuilt in for SQL resultsThrough plotting libraries in the kernelBuilt-in visualizations
  • Pick Zeppelin for a self-hosted notebook that mixes Spark, Flink and SQL in one page, or when EMR or Managed Flink already provide one. Pick Jupyter for one-language notebooks, especially Python, and use Databricks notebooks if your data and compute are on Databricks.

See it in a real stack

No architecture uses Apache Zeppelin yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2026

By 2013 teams had several SQL engines over Hadoop, such as Hive, Presto and Shark, but no friendly open-source tool to explore data with them and see the results as charts. Zeppelin began at NFLabs in Korea as a GUI for those SQL-over-Hadoop systems, open source from its start in September 2013; Lee Moon Soo was among its core developers.

It soon became clear that data scientists wanted more than SQL: a web notebook where they could share interactive sessions on a cluster. Zeppelin added full Apache Spark support and a collaborative, notebook-style interface with pluggable interpreters for other systems. Developers from NFLabs and Between proposed it to Apache, and it entered the Incubator in December 2014.

Zeppelin became a top-level Apache project in May 2016. It found its niche where Spark, Flink and SQL meet: Amazon EMR ships it, and AWS built its Flink Studio notebooks on it.

Why it’s built this way

Pluggable interpreters instead of one language
Zeppelin started as a front end for several SQL-on-Hadoop engines. An abstract interpreter API let it add Spark, Flink and JDBC sources without changing the notebook.
Interpreters in separate JVM processes
Each engine needs its own libraries and resources. Running each interpreter group in its own JVM, talking to the server over Thrift, keeps engines apart from the web server and lets one setting serve shared, per-user or per-note sessions.
Charts built into the notebook
The goal was data exploration and visualization for analysts. Rendering SQL results as tables and charts by default saved writing plotting code for every query.

Timeline

  1. 2013

    Zeppelin open-sourced at NFLabs in September as a GUI for SQL on Hadoop

  2. 2014

    Enters the Apache Incubator in December

  3. 2015

    First Apache release, 0.5.0-incubating, in July

  4. 2016

    Becomes a top-level Apache project in May

  5. 2025

    Zeppelin 0.12.0 introduces a new UI

  6. 2026

    Zeppelin 0.12.1 released in June

Sources20 · facts checked 6 October 2026

Improve this page on GitHub