DataCoolie — Metadata-driven ETL Framework
Metadata-driven ETL framework that unifies execution engines (Spark, Polars, and more in the future), remains cloud-agnostic (Fabric, AWS, Databricks, and more in the future), and currently focuses on batch workloads with a roadmap to micro-batch and streaming.
What problem does it solve?
Data teams often prototype pipelines locally, then rewrite the same pipeline for Spark and again for each cloud runtime. That duplicates ETL code and makes operational behavior such as watermarks, schema hints, partitions, load strategies, and maintenance drift across environments.
DataCoolie solves this by separating pipeline intent from execution details. You define connections, dataflows, transforms, and operational controls as metadata, then run the same intent on Polars or Spark and on local, Fabric, Databricks, or AWS platforms.
Why it helps
- Metadata-driven — pipeline behavior lives in metadata instead of being re-implemented in each job.
- Right-sized compute — small and medium jobs can stay on lighter runtimes like Polars or local execution instead of paying Spark or cluster overhead too early.
- Portable — the same metadata can move to Spark and cloud platforms when workloads grow.
- Engine-unified — the same metadata runs on Spark and Polars; swap at runtime.
- Cloud-agnostic —
local,aws,fabric,databricksplatforms abstract file I/O and secrets. - Lakehouse-native — first-class Delta Lake and Apache Iceberg via
fmt="delta"/fmt="iceberg". - Operationally complete — watermarks, schema hints, partitions, load strategies, logging, and maintenance are built in.
- Extensible components — engines, platforms, sources, destinations, transformers, and secret resolvers use registries with Python entry-point discovery; built-ins are also registered in-process.
Start here
If you are evaluating DataCoolie for the first time, use this order:
- Install the smallest useful runtime:
pip install "datacoolie[polars,deltalake]" - Run the quick start below
- Then move to the docs for using your own input and building a multi-stage flow
If you already know your runtime will be Spark, swap the install to
pip install "datacoolie[spark,delta-spark]" and keep the same metadata pattern.
Installation
# Most common first install
pip install "datacoolie[polars,deltalake]"
# Spark-first local validation
pip install "datacoolie[spark,delta-spark]"
# Add stable hash_columns support to a Polars runtime
pip install "datacoolie[polars,deltalake,polars-hash]"
# Core only (mainly useful for extension work)
pip install datacoolie
# All engines
pip install datacoolie[all]
Quick Start
Install, then run two short scripts:
prepare_quickstart.pycreates a sample CSV andmetadata.json.run_quickstart.pyloads that metadata and runs the pipeline.
pip install "datacoolie[polars]"
Part 1 — Prepare sample data and metadata
# prepare_quickstart.py
import json
from pathlib import Path
root = Path("dc_quickstart")
(root / "input" / "orders").mkdir(parents=True, exist_ok=True)
(root / "output").mkdir(parents=True, exist_ok=True)
(root / "input/orders/orders.csv").write_text(
"order_id,customer_id,amount\n1,100,19.99\n2,100,42.50\n3,101,7.25\n"
)
metadata = {
"connections": [
{"name": "csv_in", "connection_type": "file", "format": "csv",
"configure": {"base_path": str(root / "input"),
"read_options": {"header": "true", "inferSchema": "true"}}},
{"name": "parquet_out", "connection_type": "file", "format": "parquet",
"configure": {"base_path": str(root / "output")}},
],
"dataflows": [
{"name": "orders_csv_to_parquet", "stage": "bronze2silver",
"processing_mode": "batch",
"source": {"connection_name": "csv_in", "table": "orders"},
"destination": {"connection_name": "parquet_out", "table": "orders",
"load_type": "full_load"},
"transform": {}},
],
}
metadata_path = root / "metadata.json"
metadata_path.write_text(json.dumps(metadata, indent=2))
print(f"Created {metadata_path}")
python prepare_quickstart.py
Part 2 — Run the pipeline
# run_quickstart.py
from pathlib import Path
from datacoolie.engines.polars_engine import PolarsEngine
from datacoolie.platforms.local_platform import LocalPlatform
from datacoolie.metadata.file_provider import FileProvider
from datacoolie.orchestration.driver import DataCoolieDriver
root = Path("dc_quickstart")
metadata_path = root / "metadata.json"
platform = LocalPlatform()
engine = PolarsEngine(platform=platform)
provider = FileProvider(config_path=str(metadata_path), platform=platform)
with DataCoolieDriver(engine=engine, metadata_provider=provider) as driver:
result = driver.run(stage="bronze2silver")
print(f"Completed: {result.succeeded}/{result.total}")
python run_quickstart.py
Swap PolarsEngine for SparkEngine(spark_session=spark, ...) or
LocalPlatform() for AWSPlatform / FabricPlatform /
DatabricksPlatform — the metadata stays
the same.
What to do next
- Use your own files while keeping the same runner pattern: https://datacoolie.github.io/datacoolie/getting-started/use-your-own-data/
- Build a multi-stage bronze→silver tutorial flow: https://datacoolie.github.io/datacoolie/getting-started/first-dataflow/
- Learn the metadata model field by field: https://datacoolie.github.io/datacoolie/how-to/metadata-guide/
AI-assisted project workflow
DataCoolie AI skills use {project_name}_dcws/ as the project control folder.
That workspace contains its own AGENTS.md, required source discovery evidence for a new project, one canonical
architecture when material design exists, durable metadata and runners, immutable generated builds,
runtime state, and approval or release evidence.
The canonical workflow contract lives at ai/AGENTS.md. It routes work by required outcome: mandatory new-project discovery, material design, build, conditional provisioning, and explicit release. Design, infrastructure mutation, and production release use separate exact-scope gates.
Testbed & scenarios
See usecase-sim/README.md for a ready-made integration
testbed that exercises every {polars,spark} × {file,database,api} × {local,aws}
combination, plus lakehouse maintenance and a Docker-compose backend stack.
License
AGPL-3.0-or-later — free and open source.
See CONTRIBUTING.md for contribution terms.
Release files for datacoolie 0.1.5
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| datacoolie-0.1.5.tar.gz | 230.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| datacoolie-0.1.5-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 502.5 kB
Release files / datacoolie-0.1.5.tar.gz
| Download URL | datacoolie-0.1.5.tar.gz |
|---|---|
| Size | 230.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3aa19b66f69814d4d7bf3d985dbdcbadbaeaf7ac275ab708acee1c9e78c438a2
|
|
BLAKE2b-256 checksum How to use checksums |
e8f526968b31b1cc9648d7f779ad608a798b6c5618d661a687de36649e082ae2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 15, 2026.
Transparency logRelease files / datacoolie-0.1.5-py3-none-any.whl
| Download URL | datacoolie-0.1.5-py3-none-any.whl |
|---|---|
| Size | 271.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c7b6809398eeacc6e00004a65befc6786108a1c9d8d60c255328503182436676
|
|
BLAKE2b-256 checksum How to use checksums |
bed944a3052ce9d7ae8628390b6b5791389e4775e0f2d24613de56d58c1718c7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 15, 2026.
Transparency log