Skip to main content
collectionsSource-backed

Notebook Analytics Workbench

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.

by MkDev11·added 2026-06-04·
Bundle:6 items
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://docs.marimo.io/getting_started/, https://github.com/JSONbored/awesome-claude/blob/main/content/collections/notebook-analytics-workbench.mdx
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.
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.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

65 minutes

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup. Includes a review or approval gate.

0/5 ready
Install & runtime2Network & hosting2Review & approval165 minutes

Safety & privacy surface

Safety & privacy surface

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.

Schema details

Install type
copy
Troubleshooting
No
Collection metadata
Items
6 entries
Estimated setup
65 minutes
Difficulty
intermediate
Installation order
marimoduckdbpolarshugging-face-datasetsgreat-expectationsstreamlit
Full copyable content
## 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"}

Source and references

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.

Source citations

Add this badge to your README

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.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/collections/notebook-analytics-workbench.svg)](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).

Field

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.

Open dossier

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.

Open dossier

Apache-2.0 GX Core Python library for data quality Expectations, validation definitions, checkpoints, Data Docs, metadata stores, and pipeline quality checks.

Open dossier

MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
SubmitterDiffersMkDev11oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandMarimo logoMarimoGreat Expectations logoGreat ExpectationsDuckDB logoDuckDB
Categorycollectionstoolstoolstools
SourceSource-backedSource-backedSource-backedSource-backed
AuthorMkDev11Marimo TeamGreat ExpectationsDuckDB Foundation
Added2026-06-042026-06-042026-06-042026-06-04
Platforms
Harness
Source repo
Safety notesNotebooks, 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 notesNotebook 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.
Install
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.