dlt vs dltHub: the five ecosystem layers dltHub adds

Your team already uses dlt?

You did the smart thing. Your team builds its pipelines on dlt - plain Python in your repo, no vendor owning your ingestion, no meter counting your rows.

But ingestion is one element of a production data platform. To run dlt in production, you had to build and operate the other parts yourself:

• Somewhere to run the pipelines. Cron on a VM, a GitHub Action, or "I guess we install an orchestrator" - an ops surface your team now owns that has nothing to do with your data.
• A deployment process. Invented, implemented, and taught to everyone - and in many organisations, a bottleneck.
• Secrets and access. A .env here, a vault there, and a convention in a README that new hires learn the hard way.
• Alerting and log-reading. Whatever someone remembered to wire. Detection is often a stakeholder noticing a stale dashboard; tracking down the breakage is specialist work done under pressure.
• The dlt expertise itself. One or two people know the library well; everyone else waits for them, and when a release changes something, you find out in a broken run.
• Everything after loading. Exploration, transformation, dashboards - stitched from separate tools, with context lost at every handover.

Each is paid in senior-engineer hours, buried in payroll.

Martin Seifert, data engineering lead at a Swiss nonprofit, runs 25 production pipelines into Snowflake, 155 million rows in a seven-day window: "Wherever else I tried running dlt, I had to build observability on top. If I wanted to see if my pipelines ran, I had to build a custom thing on top of that."

dltHub is that custom thing on top, built once.

The five layers you're missing

dlt is how a single developer builds pipelines; dltHub is how a team runs them together, agentically.

Human judgment, decisions, and responsibility stay core. What gets replaced is the operating system of tools and knowledge you currently maintain around the pipelines.

The five layers:

1. The AI harness: replaces the team's learning curve and the deployment process.

The harness equips whatever coding agent you already use (Claude Code, Codex, Cursor) with skills we write and sync with every dlt release. When we change the library, we update the skills so there’s no separate maintenance. Everyone uses a best-practice process without even being aware - like not giving the LLM your credentials. For deployment, you just ask the agent which will test and deploy for you.

2. The context catalog: replaces the alerting you wired and the context you paste.

Every run writes schemas, lineage, run state, and data-quality results into one place that humans and agents both read. Failures are loud and structured. The agent triages them against the actual state of production, not a reconstruction of it, tests a fix, and waits for your confirmation before deploying. Watch the 3-minute maintenance video for the workflow.

3. Transformation: replaces the stitched-together layer after loading. dlthub transformations are database agnostic, dlt native resources enabling patterns like running pipelines across technologies at any step (enables agent native decentralised architectures).

4. Orchestration: replaces schedulers, crons. Schedules, follow-up chains, dependencies, freshness gates, refresh cascades: defined in code, deployed with the workspace, no orchestrator to install and babysit.

5. Managed infra: replaces the ops surface, and serves the results. Serverless sandboxes billed on compute time: the same usage model as the clouds (AWS, GCP) or products like Snowflake and Databricks. Secrets and access profiles replace the README convention. At the serving end: marimo and Streamlit apps, chat-BI, API access.

What you're actually buying

The library part you already trust: dlt is observed to be 99.83% reliable in the wild, and a back-of-envelope calculation puts the TCO per pipeline on dlthub in the $100/year range. The platform makes the remaining fraction cheap to handle. Anyone on the team who can judge outcomes can confirm a fix, not just the one person who knows the library.

You pay for runtime minutes — never for rows, schema changes, re-syncs, backfills, or seats.

To be clear about what you're buying: not infrastructure. Your team could assemble all of the above itself, and dlt stays free and complete either way. What dltHub sells is the assembled outcome and the operation underneath it — and your code stays portable the whole time.

You already run one layer. The other five are why you still have busy work left.

Try it today:

• Try dltHub free for 2 weeks: ask your agent “Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub”
• Want your whole setup moved and organised in one go? Book a call with us, we'll help.