Python client helpers for the ducklake-cdc DuckDB extension
Project description
ducklake-cdc-client
Python client helpers for the ducklake_cdc DuckDB community extension.
The package gives you two layers:
CDCClient: a direct Python wrapper over the extension's SQL table functions.DMLConsumer/DDLConsumer: durable consumers that yield batches and commit only after your code has processed them.
Install
pip install ducklake-cdc-client
The package uses ducklake-client for DuckLake
connections. CDCClient installs and loads the DuckDB community extension on first use:
INSTALL ducklake_cdc FROM community;
LOAD ducklake_cdc;
Batch iteration
from ducklake_client import DiskStorage, DuckDBCatalog, DuckLake
from ducklake_cdc_client import DMLConsumer
with DuckLake(
catalog=DuckDBCatalog("metadata.ducklake"),
storage=DiskStorage("data"),
) as lake:
with DMLConsumer(
lake,
"orders-consumer",
table="main.orders",
mode="changes",
) as consumer:
for batch in consumer.batches(infinite=False):
for change in batch:
print(change.to_dict())
batch.commit()
batch.commit() advances the durable consumer cursor. If processing raises before that call,
the same batch can be read again on the next run.
For one schema-independent cursor over every table in the catalogue, omit the table identity and use tick mode:
with DMLConsumer(
lake,
"catalogue-dml",
mode="ticks",
) as consumer:
for batch in consumer.batches(infinite=True):
for tick in batch:
publish_to_nats(tick.table_ids, tick.snapshot_id)
batch.commit()
This cursor follows newly created tables and continues across DDL boundaries.
Downstream systems can fan out by table_ids.
Connections, retries, and restart safety
Each high-level consumer uses one dedicated DuckDB connection for create/read/listen,
heartbeats, and commit. This is required because the extension's lease belongs to the
connection that acquired it. By default the client derives and owns that connection. If you
pass connection= or client=, dedicate its connection to that one consumer: do not run
unrelated queries on it, because cancellation calls connection.interrupt().
Known SQLite lock bursts, every observed H-022 deadlock spelling (thread::join failed,
resource deadlock would occur, and resource deadlock avoided), and typed lease contention
errors use the default bounded retry policy. Retry is not a recovery boundary for a poisoned
DuckDB handle. After retries are exhausted, discard the consumer and its connection, open a new
consumer instance, and resume the same durable consumer name. Call prewarm() on every handle
immediately after loading the extension and before other catalog activity.
Lease failures are catchable as LeaseContentionError or LeaseTimeoutError; both inherit
RetryableCDCError. A process supervisor should back off and reopen on a fresh dedicated
connection. Reopening with on_exists="use" resumes from the last committed snapshot, so only
commit after sink processing succeeds.
Graceful shutdown is bounded:
consumer.close(timeout=5.0, cancel=True, release=True)
cancel=True interrupts an active listen/read and that caller receives
ConsumerCancelledError. cancel=False waits without interrupting. Either mode raises
ConsumerCloseTimeoutError if the deadline expires. release=True calls the owner-token-
conditional cdc_consumer_release, so a stale close cannot clear a successor connection's
lease. Use release=False only when an external supervisor owns lease cleanup. The
unconditional cdc_consumer_force_release remains an operator recovery command. Abrupt process
death cannot run close(): the next process must wait for lease expiry or use
lease_policy="takeover" only after it knows the previous holder is dead.
cdc_consumer_release requires ducklake_cdc >= 0.5.4. With an older extension, high-level
close safely closes its owned connection and relies on lease expiry; it never falls back to
unconditional force release. Upgrade the extension to make graceful release immediate.
Cancellation ends the current run and is never retried in place. A lease timeout is marked retryable for supervisors but likewise does not repeat its entire wait internally; reopen after backoff instead.
Sink-driven usage
If you prefer a push style, pass sinks and let consumer.run() deliver and commit for you.
from ducklake_client import DiskStorage, DuckDBCatalog, DuckLake
from ducklake_cdc_client import DMLConsumer, StdoutSink
with DuckLake(
catalog=DuckDBCatalog("metadata.ducklake"),
storage=DiskStorage("data"),
) as lake:
with DMLConsumer(
lake,
"orders-consumer",
table="main.orders",
mode="changes",
sinks=[StdoutSink()],
) as consumer:
consumer.run(infinite=False)
CDCApp.stats() includes generic operation activity for each worker:
current_operation, operation_started_at, and
last_operation_completed_at. Supervisors can use those timestamps to
apply deployment-specific stall policy without putting timeout policy in
the client.
Demo
Run the local demo:
uv run python demo.py
The demo creates a local DuckLake catalog under .demo/, inserts one row into main.orders,
prints the emitted CDC change batch, and commits it.
Test with a local extension build
The extension binary must match the Python package's DuckDB version exactly. This checkout pins
DuckDB 1.5.4. After building the sibling extension repo, copy its unsigned macOS/arm64 binary
into this repo's ignored local-artifact directory:
mkdir -p .local/extensions/v1.5.4/osx_arm64
cp ../ducklake-cdc-extension/build/release/extension/ducklake_cdc/ducklake_cdc.duckdb_extension \
.local/extensions/v1.5.4/osx_arm64/
export DUCKLAKE_CDC_EXTENSION="$PWD/.local/extensions/v1.5.4/osx_arm64/ducklake_cdc.duckdb_extension"
Allow unsigned extensions when DuckDB opens, load the binary before constructing the consumer, and let the client skip its normal community-repository install:
import os
from ducklake_client import DiskStorage, DuckDBCatalog, DuckDBConfig, DuckLake
from ducklake_cdc_client import CDCClient, DMLConsumer
with DuckLake(
catalog=DuckDBCatalog("metadata.ducklake"),
storage=DiskStorage("data"),
duckdb=DuckDBConfig(config={"allow_unsigned_extensions": True}),
) as lake:
lake.connection.execute(f"LOAD '{os.environ['DUCKLAKE_CDC_EXTENSION']}'")
client = CDCClient(lake, install_extension=False)
with DMLConsumer(
lake,
"orders-consumer",
table="main.orders",
mode="changes",
client=client,
) as consumer:
print(consumer.client.version())
This binary is platform-specific (osx_arm64) and unsigned; rebuild it for another DuckDB
version or platform instead of reusing it.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file ducklake_cdc_client-0.7.1.tar.gz.
File metadata
- Download URL: ducklake_cdc_client-0.7.1.tar.gz
- Upload date:
- Size: 50.1 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.1.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
9490e5250af994d7e41374eab73bd74069479dc476baf06dbb720de9edd99a77
|
|
| MD5 |
f28d672f0811096ccdcc2b3a2255c21d
|
|
| BLAKE2b-256 |
1a2f3e08aca49e32fefae2b9abbdf032506b0c126d75c0be18d255b5c596186c
|
File details
Details for the file ducklake_cdc_client-0.7.1-py3-none-any.whl.
File metadata
- Download URL: ducklake_cdc_client-0.7.1-py3-none-any.whl
- Upload date:
- Size: 43.4 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.1.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
9e0f35c8048157e979f0d68f5193d29a0c8715b455a4aa6efae1ba10859f955f
|
|
| MD5 |
700c759c49ac3b1aba4664e319905939
|
|
| BLAKE2b-256 |
3ebcc50d8e9383713e52b5667ff4b3a5588a268d6200fffc5a4f006cca5488b7
|