A source-backed collection for reproducible data analysis and notebook work: Marimo notebooks, DuckDB analytical SQL, Polars DataFrames, Hugging Face Datasets loading, Great Expectations quality checks, and Streamlit sharing.
Notebooks, data loaders, SQL queries, DataFrame transforms, validation checkpoints, and Streamlit apps execute project code; run them in an isolated environment with bounded file and network access., DuckDB and Polars can process large local files quickly but can still exhaust memory, disk, or CPU when joins, scans, and exports are unbounded., Hugging Face Datasets can download or stream external datasets; review licenses, revisions, dataset cards, scripts, and cache behavior before using them in production analysis., Streamlit apps can expose data, credentials, and Python side effects through a browser interface, so review authentication, secrets, query limits, and deployment settings before sharing.
Privacy notes
Notebook outputs, DuckDB databases, DataFrame exports, dataset caches, validation reports, Streamlit state, charts, and screenshots can retain sensitive rows after source files are deleted., Dataset names, access patterns, package downloads, Hub requests, Streamlit telemetry, and remote data connectors can disclose project interests or data sources to external services., Great Expectations Data Docs, validation failures, sampled examples, and dashboard filters can expose row values, column names, business metrics, and data-quality issues.
Author
MkDev11
Submitted by
MkDev11
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
4 safety and 3 privacy notes across 4 risk areas. Review closely: credentials & tokens, network access.
4 areas
SafetyNetwork accessNotebooks, data loaders, SQL queries, DataFrame transforms, validation checkpoints, and Streamlit apps execute project code; run them in an isolated environment with bounded file and network access.
SafetyLocal filesDuckDB and Polars can process large local files quickly but can still exhaust memory, disk, or CPU when joins, scans, and exports are unbounded.
SafetyNetwork accessHugging Face Datasets can download or stream external datasets; review licenses, revisions, dataset cards, scripts, and cache behavior before using them in production analysis.
SafetyCredentials & tokensStreamlit apps can expose data, credentials, and Python side effects through a browser interface, so review authentication, secrets, query limits, and deployment settings before sharing.
PrivacyLocal filesNotebook outputs, DuckDB databases, DataFrame exports, dataset caches, validation reports, Streamlit state, charts, and screenshots can retain sensitive rows after source files are deleted.
PrivacyNetwork accessDataset names, access patterns, package downloads, Hub requests, Streamlit telemetry, and remote data connectors can disclose project interests or data sources to external services.
PrivacyTelemetryGreat Expectations Data Docs, validation failures, sampled examples, and dashboard filters can expose row values, column names, business metrics, and data-quality issues.
Safety notes
Notebooks, data loaders, SQL queries, DataFrame transforms, validation checkpoints, and Streamlit apps execute project code; run them in an isolated environment with bounded file and network access.
DuckDB and Polars can process large local files quickly but can still exhaust memory, disk, or CPU when joins, scans, and exports are unbounded.
Hugging Face Datasets can download or stream external datasets; review licenses, revisions, dataset cards, scripts, and cache behavior before using them in production analysis.
Streamlit apps can expose data, credentials, and Python side effects through a browser interface, so review authentication, secrets, query limits, and deployment settings before sharing.
Privacy notes
Notebook outputs, DuckDB databases, DataFrame exports, dataset caches, validation reports, Streamlit state, charts, and screenshots can retain sensitive rows after source files are deleted.
Dataset names, access patterns, package downloads, Hub requests, Streamlit telemetry, and remote data connectors can disclose project interests or data sources to external services.
Great Expectations Data Docs, validation failures, sampled examples, and dashboard filters can expose row values, column names, business metrics, and data-quality issues.
Prerequisites
Python environment with pinned notebook, data, and visualization dependencies for the project.
Data source inventory covering local files, database exports, Parquet/CSV/JSON files, Hub datasets, and any licensed or private datasets.
Column dictionary, data-quality expectations, join keys, time windows, and output review rules before analysis results are shared.
Storage and retention plan for notebook outputs, DuckDB files, cached datasets, Great Expectations Data Docs, Streamlit app state, and exported charts.
Agreement on which data can be queried locally, downloaded from external hubs, embedded into notebooks, or published in dashboards.
## What this collection sets up
This collection is a practical notebook analytics workbench: write analysis in
reviewable notebooks, query local files without standing up a warehouse,
transform tabular data efficiently, load approved datasets, validate important
columns, and share reviewed results as lightweight apps.
It is not a privacy-first research workflow and it is not a full data
engineering platform. The focus is the analyst loop from raw files or approved
datasets to reproducible notebook, validated result, and shareable report.
## Layers
### 1. Notebook and local query layer
- **marimo** keeps Python notebooks in a git-friendly source format and supports
notebook, script, app, SQL, and reactive execution workflows.
- **duckdb** gives notebooks and scripts an embedded analytical SQL engine for
local files, Parquet, CSV, joins, and single-file analysis.
- **polars** provides a fast DataFrame engine for filtering, joins,
transformations, lazy execution, streaming, and export preparation.
### 2. Dataset intake and quality checks
- **hugging-face-datasets** loads, streams, inspects, and preprocesses Hub or
local datasets with cache and split/configuration controls.
- **great-expectations** records data-quality expectations, validation
definitions, checkpoints, and Data Docs before outputs are trusted.
### 3. Sharing reviewed analysis
- **streamlit** turns reviewed scripts into interactive data apps, dashboards,
reports, and analytical interfaces when a notebook needs a human-facing view.
## Suggested order
Start with Marimo so analysis lives in reviewable source. Add DuckDB for local
SQL against files and Polars for DataFrame transformations. Load external or
large datasets only after their source, license, schema, and cache behavior are
approved. Add Great Expectations checks around key columns and metrics before
sharing results. Use Streamlit last, after the analysis is stable and the data
exposure rules are clear.
## Analysis checklist
- [ ] {"task": "Sources are inventoried", "description": "Files, datasets, licenses, revisions, credentials, and cache paths are known"}
- [ ] {"task": "Notebook is reproducible", "description": "Dependencies, paths, parameters, and execution order are clear enough for review"}
- [ ] {"task": "Queries are bounded", "description": "Large scans, joins, exports, and remote downloads have limits and expected sizes"}
- [ ] {"task": "Data quality is checked", "description": "Important columns, row counts, nulls, ranges, and joins have validation expectations"}
- [ ] {"task": "Outputs are reviewed", "description": "Charts, CSVs, notebooks, Data Docs, and apps are checked before sharing"}
- [ ] {"task": "Retention is explicit", "description": "Caches, DuckDB files, Streamlit state, screenshots, and exports have cleanup rules"}
## Source and references
- Marimo getting started: https://docs.marimo.io/getting_started/
- DuckDB clients overview: https://duckdb.org/docs/stable/clients/overview
- Polars getting started: https://docs.pola.rs/user-guide/getting-started/
- Hugging Face Datasets documentation: https://huggingface.co/docs/datasets/index
- Great Expectations introduction: https://docs.greatexpectations.io/docs/core/introduction/
- Streamlit get started: https://docs.streamlit.io/get-started
## Duplicate check
Checked existing collections, tools, skills, commands, hooks, guides, open PRs,
closed PRs, and issue history for `notebook-analytics-workbench`, data analysis
notebook workflow, Marimo, DuckDB, Polars, Hugging Face Datasets, Great
Expectations, Streamlit, analytics workbench, and notebook dashboards.
`privacy-first-research-workflow` uses Marimo, DuckDB, and Polars inside a
privacy/redaction/research workflow. `data-engineering-suite` focuses on ETL,
databases, cloud services, and pipeline infrastructure. This entry is narrower:
it covers the analyst notebook loop from data intake to local query,
transformation, quality checks, and reviewed sharing.
## Disclosure
Editorial collection. No paid placement or affiliate link is used.
About this resource
What this collection sets up
This collection is a practical notebook analytics workbench: write analysis in
reviewable notebooks, query local files without standing up a warehouse,
transform tabular data efficiently, load approved datasets, validate important
columns, and share reviewed results as lightweight apps.
It is not a privacy-first research workflow and it is not a full data
engineering platform. The focus is the analyst loop from raw files or approved
datasets to reproducible notebook, validated result, and shareable report.
Layers
1. Notebook and local query layer
marimo keeps Python notebooks in a git-friendly source format and supports
notebook, script, app, SQL, and reactive execution workflows.
duckdb gives notebooks and scripts an embedded analytical SQL engine for
local files, Parquet, CSV, joins, and single-file analysis.
polars provides a fast DataFrame engine for filtering, joins,
transformations, lazy execution, streaming, and export preparation.
2. Dataset intake and quality checks
hugging-face-datasets loads, streams, inspects, and preprocesses Hub or
local datasets with cache and split/configuration controls.
great-expectations records data-quality expectations, validation
definitions, checkpoints, and Data Docs before outputs are trusted.
3. Sharing reviewed analysis
streamlit turns reviewed scripts into interactive data apps, dashboards,
reports, and analytical interfaces when a notebook needs a human-facing view.
Suggested order
Start with Marimo so analysis lives in reviewable source. Add DuckDB for local
SQL against files and Polars for DataFrame transformations. Load external or
large datasets only after their source, license, schema, and cache behavior are
approved. Add Great Expectations checks around key columns and metrics before
sharing results. Use Streamlit last, after the analysis is stable and the data
exposure rules are clear.
Analysis checklist
{"task": "Sources are inventoried", "description": "Files, datasets, licenses, revisions, credentials, and cache paths are known"}
{"task": "Notebook is reproducible", "description": "Dependencies, paths, parameters, and execution order are clear enough for review"}
{"task": "Queries are bounded", "description": "Large scans, joins, exports, and remote downloads have limits and expected sizes"}
{"task": "Data quality is checked", "description": "Important columns, row counts, nulls, ranges, and joins have validation expectations"}
{"task": "Outputs are reviewed", "description": "Charts, CSVs, notebooks, Data Docs, and apps are checked before sharing"}
{"task": "Retention is explicit", "description": "Caches, DuckDB files, Streamlit state, screenshots, and exports have cleanup rules"}
Checked existing collections, tools, skills, commands, hooks, guides, open PRs,
closed PRs, and issue history for notebook-analytics-workbench, data analysis
notebook workflow, Marimo, DuckDB, Polars, Hugging Face Datasets, Great
Expectations, Streamlit, analytics workbench, and notebook dashboards.
privacy-first-research-workflow uses Marimo, DuckDB, and Polars inside a
privacy/redaction/research workflow. data-engineering-suite focuses on ETL,
databases, cloud services, and pipeline infrastructure. This entry is narrower:
it covers the analyst notebook loop from data intake to local query,
transformation, quality checks, and reviewed sharing.
Disclosure
Editorial collection. No paid placement or affiliate link is used.
Show that Notebook Analytics Workbench is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/collections/notebook-analytics-workbench)
How it compares
Notebook Analytics Workbench side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
1 trust signal differ across this comparison (Submitter).
A source-backed collection for reproducible data analysis and notebook work: Marimo notebooks, DuckDB analytical SQL, Polars DataFrames, Hugging Face Datasets loading, Great Expectations quality checks, and Streamlit sharing.
Apache-2.0 reactive Python notebook stored as pure Python for reproducible experiments, SQL-backed data workflows, script execution, app deployment, and AI-assisted editing.
Apache-2.0 GX Core Python library for data quality Expectations, validation definitions, checkpoints, Data Docs, metadata stores, and pipeline quality checks.
MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows.
✓Notebooks, data loaders, SQL queries, DataFrame transforms, validation checkpoints, and Streamlit apps execute project code; run them in an isolated environment with bounded file and network access.
DuckDB and Polars can process large local files quickly but can still exhaust memory, disk, or CPU when joins, scans, and exports are unbounded.
Hugging Face Datasets can download or stream external datasets; review licenses, revisions, dataset cards, scripts, and cache behavior before using them in production analysis.
Streamlit apps can expose data, credentials, and Python side effects through a browser interface, so review authentication, secrets, query limits, and deployment settings before sharing.
✓Marimo notebooks execute Python and SQL, can write files, query databases, call APIs, access object storage, install packages, and start web servers, so notebooks should be treated as trusted project code.
Reactive execution automatically tracks variable dependencies and can run downstream cells after upstream changes; expensive, destructive, or side-effectful cells need lazy runtime, disabled cells, startup autorun, and manual-run policies.
The docs note that Marimo tracks variable definitions and references statically, not arbitrary mutations across cells, so mutable shared state should be designed carefully to avoid misleading results.
App mode uses `marimo run` to serve notebooks as web apps with code hidden by default, but public deployments still need authentication, authorization, rate limiting, reverse proxy policy, and traceback disclosure review.
Disabling token protection, passing access tokens in URLs, or exposing edit servers can give unauthorized users access to notebook execution and should be avoided outside controlled environments.
SQL cells can interpolate Python values, query local files and remote databases, and use engines or extensions such as DuckDB, so SQL strings, credentials, object paths, and output destinations should be reviewed before automation.
Built-in AI and copilot features may inspect notebook code, prompts, tool context, and referenced variable values; provider selection, API keys, local model behavior, and cost controls should be configured deliberately.
Package-management features can serialize requirements and auto-install dependencies into notebook-specific environments, so teams should pin, review, and scan packages before sharing or deploying notebooks.
✓GX Core validations can query databases, scan files, evaluate DataFrames, and compute metrics over real datasets, so production runs should use scoped credentials, tested queries, and bounded resources.
Checkpoints can trigger Actions such as updating Data Docs, sending notifications, or running custom logic based on Validation Results; notification endpoints and custom Actions should be reviewed before automation.
Data Docs generate static human-readable documentation from Expectations, Validation Results, and metadata, so hosted sites and generated folders need access controls before they include sensitive details.
Result formats and unexpected-row retrieval can expose row-level failures or sample values; teams should tune result verbosity before publishing results to logs, tickets, chat, or docs sites.
Custom Expectations, custom Actions, SQL-based custom Expectations, and orchestration integrations run team-provided code or queries and should be treated as trusted project code.
GX Core compatibility depends on Python, data source, integration, and optional dependency support, so upgrades should be tested against the compatibility reference and existing validation suites.
✓DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases.
Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations.
Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path.
Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it.
Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations.
Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state.
Privacy notes
✓Notebook outputs, DuckDB databases, DataFrame exports, dataset caches, validation reports, Streamlit state, charts, and screenshots can retain sensitive rows after source files are deleted.
Dataset names, access patterns, package downloads, Hub requests, Streamlit telemetry, and remote data connectors can disclose project interests or data sources to external services.
Great Expectations Data Docs, validation failures, sampled examples, and dashboard filters can expose row values, column names, business metrics, and data-quality issues.
✓Marimo workflows can process notebook source code, cell outputs, variable values, DataFrames, SQL queries, schemas, database rows, object-store paths, generated apps, CLI arguments, logs, and exported artifacts.
User configuration can store runtime, server, completion, and AI-provider settings, while app configuration can live inside notebook files; secrets should stay in environment variables or secret stores rather than committed notebooks.
AI-assisted editing can send prompts, notebook context, code, schemas, and referenced in-memory values to configured hosted providers, or to local model services when those are selected.
Database and remote-storage workflows can expose connection strings, credentials, table names, bucket names, object keys, query text, sample rows, and download paths to notebooks, logs, cloud services, and deployed apps.
Token login, query-parameter access tokens, Basic auth headers, reverse-proxy headers, and server logs should be handled as sensitive operational data.
✓GX Core workflows can process source data, schemas, table names, file paths, SQL queries, Batch metadata, Expectation Suites, Validation Results, Checkpoints, Actions, Data Docs, and generated stores.
The credentials docs say tokens and connection strings should be stored securely outside version control, using environment variables, uncommitted config files, or supported secrets managers.
File Data Context Stores can persist Expectation Suites, Validation Definitions, Checkpoints, Validation Results, and Suite Parameters in project folders or configured backends.
Data Docs are static web pages generated from Expectations, Validation Results, and metadata; publishing them can disclose validation outcomes, column names, dataset structure, and failing examples.
GX Core tracks analytics events by default, including feature usage, operating system, and Python version, and the docs describe disabling collection with `GX_ANALYTICS_ENABLED` or `analytics_enabled`.
✓DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets.
The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history.
Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL.
On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration.
HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring.
Prerequisites
Python environment with pinned notebook, data, and visualization dependencies for the project.
Data source inventory covering local files, database exports, Parquet/CSV/JSON files, Hub datasets, and any licensed or private datasets.
Column dictionary, data-quality expectations, join keys, time windows, and output review rules before analysis results are shared.
Storage and retention plan for notebook outputs, DuckDB files, cached datasets, Great Expectations Data Docs, Streamlit app state, and exported charts.
Python environment and package-management plan for the selected notebook, app, script, SQL, visualization, and optional AI features.
Notebook execution model for reactive dependency graphs, deterministic cell ordering, lazy or stale runtime behavior, disabled cells, startup autorun, and side-effectful cells.
Data access plan for local files, DataFrames, SQL cells, databases, warehouses, cloud object storage, remote filesystems, environment variables, and credentials.
Deployment and access-control plan for edit servers, read-only apps, token or password protection, reverse proxies, ASGI middleware, public sharing, rate limits, and error reporting.
Supported Python environment for GX Core, currently Python 3.10 through 3.13, with deployment expectations that do not assume official Windows support.
Data Context choice, project layout, version control policy, and environment-specific configuration for development, CI, staging, and production validation workflows.
Data Source and Data Asset plan for SQL databases, filesystem data, pandas DataFrames, Spark DataFrames, supported cloud storage, Batch Definitions, and runtime parameters.
Expectation Suites, Validation Definitions, Checkpoints, Actions, Data Docs, Stores, result formats, and alerting rules designed around the data quality questions the team actually needs answered.
DuckDB distribution and client choice for the workflow, such as the CLI, Python, R, Java, Node.js, C or C++ APIs, Rust, ODBC, JDBC, or WebAssembly.
Data access plan for local DuckDB files, in-memory databases, CSV, Parquet, JSON, Arrow, pandas, R data frames, lakehouse formats, HTTP sources, S3-compatible storage, and mounted working directories.
Version, extension, and file-format compatibility policy for shared notebooks, CI jobs, production scripts, persisted database files, and generated analytical artifacts.
Resource controls for memory, threads, temporary directories, maximum temporary directory size, checkpointing, write-ahead logs, and long-running analytical queries.