Hello  !

I had something similar and at that time I understood that it is an initialization issue and not a reconciliation performance issue.

Why ? because lakebridge reconciliation should eventually execute spark actions when it fetches schemas or data and writes reconciliation metadata. The flow runs TriggerReconService.trigger_recon(...) from the notebook and Lakebridge stores reconciliation output in its metadata catalog or schema after the run.

Check the package :

import databricks.labs.lakebridge as lb
print(lb.__version__)

The latest PyPI version currently shown is 0.12.2, released Feb 26, 2026. https://pypi.org/project/databricks-labs-lakebridge and this is relevant because recent releases improved reconciliation exception handling and logging and even serverless compatibility. https://github.com/databrickslabs/remorph/releases

I had to enable debug logging before calling trigger_recon() and test basic spark and workspace client separately and I found that it was hanging(so here the issue is not lakebridge reconciliation)

Lakebridge requires permissions to create or use reconciliation metadata objects such as USE CATALOG, CREATE SCHEMA and if using an existing schema, volume permissions.

What I discovered at that time that lakebridge uses UC volumes for intermediate persistence on serverless clusters and the volume must exist with write permissions.