Registry / data / dlt
library1.30.0pypypi✓ verified 26d ago

dlt is an open-source python-first scalable data loading library that does not require any backend to run. It simplifies data ingestion from various sources to analytical destinations, handling schema evolution, retries, and state management. dlt releases new versions frequently, approximately monthly, often including breaking changes.

pip install dlt
INSTALL
IMPORT
SIG · DLT
D
dlt
datapythonv1.30.0
Install
8.0s avg
Import
1792ms
Disk
77MB
Pass rate
10/ 10
Env Coverage10 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v1.30.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.95 runs
installs and imports cleanly · install 0.0s · import 1.856s · 72.5MB
glibc
py 3.103.95 runs
installs and imports cleanly · install 8.0s · import 1.728s · 73MB
77MB installed
● package 77MB
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

dlt
import dlt
pipeline
from dlt import pipeline
source
from dlt import source
resource
from dlt import resource

This quickstart demonstrates how to create a simple dlt pipeline to extract GitHub issues and load them into a DuckDB destination. Ensure you have `duckdb` installed (`pip install dlt[duckdb]`) and set a `GITHUB_TOKEN` environment variable if you hit rate limits.

import dlt import os from dlt.sources.helpers import requests # Define a dlt source using a decorator @dlt.source def github_issues_source(token): # Define a dlt resource within the source @dlt.resource(write_disposition="append") def issues(owner, repo): headers = {"Authorization": f"token {token}"} url = f"https://api.github.com/repos/{owner}/{repo}/issues" # Fetching a single page for demonstration response = requests.get(url, headers=headers, params={'per_page': 10}) response.raise_for_status() yield response.json() return issues # Instantiate and run the pipeline pipeline = dlt.pipeline( pipeline_name="github_pipeline", destination="duckdb", # Or "bigquery", "snowflake", etc. dataset_name="github_data" ) load_info = pipeline.run( github_issues_source(token=os.environ.get('GITHUB_TOKEN', ''))("dlt-hub", "dlt") ) # Print the outcome print(load_info)
dlt --version
Debug
Known issues
breakingPydantic v1 support was removed in dlt 1.22.0. The library now exclusively requires Pydantic v2.
fix
Upgrade Pydantic to version 2 (`pip install 'pydantic>=2'`). Review your code for any Pydantic v1 specific patterns or configurations that may need updating.
affects: >=1.22.0
breakingThe legacy Streamlit-based pipeline dashboard (`dlt pipeline show`) was removed in dlt 1.23.0.
fix
The `dlt pipeline show` command no longer functions. Users should adapt to using the new Marimo-based interactive widgets (introduced in 1.22.2) or use `dlt inspect` for command-line pipeline details.
affects: >=1.23.0
breakingCustom resource metrics within the trace object are now stored in a table format, altering their structure and location in dlt 1.24.0.
fix
If your code reads incremental metrics from dlt's trace object, you will need to update it to access the new table-based structure and location of these metrics.
affects: >=1.24.0
breakingThe `data_type` contract's semantic changed in dlt 1.22.0. It now applies to the full data type (including precision, nullability), not just variant columns.
fix
If you used `data_type: freeze` and expected to change properties like `nullable`, `precision`, or `scale` on existing columns, these will now be treated as breaking changes. Review your schema definitions and data type contracts.
affects: >=1.22.0
breakingdlt 1.23.0 introduced a new compact source configuration lookup path (`sources.<name>.<key>`). This changes config resolution logic.
fix
While `dlt` still supports the full `sources.<section>.<name>.<key>` path, the new compact lookup may cause unexpected configuration resolution or overrides if not carefully managed. Review your configuration files and ensure keys are resolved as intended.
affects: >=1.23.0
breakingDirectly calling a `DltSource` object (e.g., `source(args)`) is no longer supported. Sources must now be loaded via `dlt.pipeline` or iterated directly if they are iterable resources.
fix
Instead of `github_issues_source(token=...)(repo_owner, repo_name)`, you should initialize the source and then use it with `dlt.run` or select specific resources. For example, `pipeline = dlt.pipeline(pipeline_name='my_pipeline', destination='duckdb', dataset_name='github_data'); pipeline.run(github_issues_source(token=os.environ.get('GITHUB_TOKEN', '')).with_resources('issues'), write_disposition='merge')` or similar patterns depending on your exact use case.
affects: >=1.22.0
breakingThe `DltSource` object, typically returned by a source factory function, is no longer directly callable with positional arguments after initialization.
fix
Update source invocation. If your code uses a pattern like `my_source_factory(config_args)(execution_arg1, execution_arg2)`, you must now pass all execution-related arguments directly to the source factory as keyword arguments (e.g., `my_source_factory(execution_arg1='value1', execution_arg2='value2', **config_args)`). Review the specific source's documentation for its updated invocation signature.
affects: >=1.25.0
Errors
Common errors & fixes
ModuleNotFoundError: No module named 'dlt'
This error frequently occurs in Databricks environments where the open-source `dlt` library clashes with Databricks' own Delta Live Tables (DLT) internal module, which also uses `dlt` as an import name.
fix
In Databricks, if you intend to use the open-source `dlt` library, you need to use an init script to remove or rename the conflicting Databricks DLT module. A common fix involves running a shell script like `removedbdlt.sh` that unsets `PYTHONPATH` or moves the conflicting module. For interactive notebooks, you might also mock the `dlt` class to pass syntax checks. If you are *not* in Databricks, simply `pip install dlt`.
DLTImportException: Delta Live Tables module is not supported on Spark Connect clusters.
This error occurs in Databricks when attempting to use Databricks' internal Delta Live Tables (DLT) module within a Spark Connect cluster, as the DLT module is not designed for this environment.
fix
Delta Live Tables functionality in Databricks is meant to be run through the DLT pipeline interface, not directly in interactive notebooks or Spark Connect clusters. To resolve this, ensure your code is deployed and executed as a DLT pipeline within the Databricks environment, where the necessary runtime and dependencies are managed automatically.
ConfigFieldMissingException
This exception is raised when `dlt` cannot find a required configuration or secret value, often because it's missing from `config.toml`, `secrets.toml`, environment variables, or other configured providers, or because profile-scoped config files are silently ignored without a `.dlt/.workspace` marker.
fix
Ensure all required configuration fields are defined in your `.dlt/config.toml` or `.dlt/secrets.toml` files, or as environment variables. If using profile-specific configurations (e.g., `dev.config.toml`), create a `.dlt/.workspace` file in your project's root to enable profile loading.
ImportError: cannot import name 'try_get_deltatable' from 'deltalake.writer'
This error typically indicates a version incompatibility between the `dlt` library and the `deltalake` library, where `dlt` is trying to import a function from `deltalake.writer` that has been removed or renamed in a newer `deltalake` version (e.g., `deltalake` 1.0 breaking changes).
fix
Pin the version of `deltalake` to a compatible version with your `dlt` installation. For `dlt` versions that had issues with `deltalake` 1.0, pinning `deltalake` to `0.25.0` or an earlier compatible version often resolves the issue. Always check the `dlt` documentation or release notes for recommended dependency versions.
IncrementalCursorInvalidCoercion error
This error occurs during incremental loading when the data type of the `initial_value` provided for an incremental cursor does not match the actual data type of the corresponding field in your source data.
fix
Ensure that the `initial_value` for your incremental cursor has the exact same data type as the field in your source data that `dlt` is tracking for incremental loading. If type conversion is needed, apply a transformation (e.g., using `add_map`) to convert the field's type *before* incremental tracking.
Upgrade
Version history
1.30.0latest on PyPI · released Aug 11, 2026
Audit
Dependencies

No dependency data recorded yet.

Agent activity
32 hits · last 30 days
node
28
OpenAI (training)
1
Resources
dlt — pip install dlt · libregistry