Lakebase CDF — destination Delta table not created after successful UI setup (Free Edition)

[ChiaMingHu]

Summary:
We configured Lakebase CDF to stream changes from a native Postgres table (public.query_logs) into Unity Catalog, but the destination Delta table never appears despite completing all documented prerequisites.

Steps taken

1. Created query_logs in Lakebase and confirmed rows are written successfully (application INSERTs work).
2. Ran ALTER TABLE query_logs REPLICA IDENTITY FULL; and verified replica identity.
Enabled Lakebase CDF in the branch UI: source schema public, destination UC catalog/schema configured, target table name lb_query_logs_history.
3. UI shows CDF as started; we waited for initial snapshot / streaming.
4. Verified from Databricks: spark.table("<catalog>.default.lb_query_logs_history") fails — table not found in Catalog Explorer.

Expected: A UC-managed Delta table (e.g. lb_query_logs_history) with CDF metadata columns (_pg_change_type, _timestamp, etc.) reflecting inserts into query_logs.

Actual: No destination Delta table in UC. Querying Lakebase wal2delta.tables also shows no usable destination. Source table continues to receive writes normally.

Questions:

Is this a known Free Edition limitation, or a bug?
Any required diagnostics or support steps we should run?

Thank you.😊😊

 

 

[anagilla]

Most likely this is a Free Edition storage limitation rather than a bug, and your Postgres-side setup sounds correct. Lakebase CDF writes its destination as a Unity Catalog managed Delta table, and the Lakebase CDF docs list catalogs backed by default storage as unsupported destinations. Free Edition workspaces run on default storage (custom workspace storage locations are unsupported), so the destination table creation cannot complete there, which matches what you see: setup goes through, but wal2delta.tables never gets a destination.

To confirm and move forward:

1. Check the destination catalog's storage location in Catalog Explorer (catalog > Details). If the path contains unitystorage, it is default storage, and that catalog cannot be a CDF destination today.

2. While you are in there, verify the other requirements: the source table lives in the databricks_postgres database, and your identity has USE CATALOG, USE SCHEMA, and CREATE TABLE on the destination catalog and schema.

3. To see CDF working end to end, run the same setup in a workspace whose destination catalog is backed by your own cloud storage (an external-location-backed catalog on a standard or trial workspace). Everything you did on the Postgres side (REPLICA IDENTITY FULL, rows present before enabling) carries over as is.