Skip to main content

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

ducklake_cdc_client-0.7.1.tar.gz (50.1 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

ducklake_cdc_client-0.7.1-py3-none-any.whl (43.4 kB view details)

Uploaded Python 3

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

Hashes for ducklake_cdc_client-0.7.1.tar.gz
Algorithm Hash digest
SHA256 9490e5250af994d7e41374eab73bd74069479dc476baf06dbb720de9edd99a77
MD5 f28d672f0811096ccdcc2b3a2255c21d
BLAKE2b-256 1a2f3e08aca49e32fefae2b9abbdf032506b0c126d75c0be18d255b5c596186c

See more details on using hashes here.

File details

Details for the file ducklake_cdc_client-0.7.1-py3-none-any.whl.

File metadata

File hashes

Hashes for ducklake_cdc_client-0.7.1-py3-none-any.whl
Algorithm Hash digest
SHA256 9e0f35c8048157e979f0d68f5193d29a0c8715b455a4aa6efae1ba10859f955f
MD5 700c759c49ac3b1aba4664e319905939
BLAKE2b-256 3ebcc50d8e9383713e52b5667ff4b3a5588a268d6200fffc5a4f006cca5488b7

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page