Greetings @gokkul , I did some digging and here is what I found. 

Writing between Lakebase Postgres and UC Delta

You can’t write from Lakebase Postgres into a UC Delta table through a synced table. Synced tables are intentionally read-only on the Postgres side. They’re managed by a Databricks pipeline and exist to provide a low-latency mirror of a UC table for reads and joins in Postgres. If data needs correction, the guidance is to fix it in the source UC Delta table and let the sync pipeline propagate the change.

If the goal is to move or copy data from UC Delta into Lakebase Postgres, the supported approach is to create a synced table. You can choose Snapshot, Triggered, or Continuous mode depending on freshness requirements, with Continuous syncing at a minimum 15-second interval.

If you need a writable copy inside Lakebase, the common pattern is to treat the synced table as a source and then create your own Postgres table from it, for example using a CREATE TABLE AS SELECT. This preserves the managed sync as a clean, authoritative mirror while giving you a mutable table for application writes. In practice, this usually becomes a two-table pattern: a read-only synced table plus a writable application table, with merge or reconciliation logic handled in views or downstream queries.

If you’d rather avoid managed sync altogether, you can always fall back to a custom ETL approach. Read UC Delta in Databricks and write into Lakebase Postgres using standard Postgres connectivity, such as Spark JDBC, with your own job orchestration.

For the reverse direction, pushing operational changes from Postgres into UC Delta, the recommended product path is Lakeflow Connect for Postgres to Delta. This is currently in Private Preview as a forward ETL capability and is the intended, supported way to continuously replicate Postgres tables into Delta when available.

Using synced tables and writing considerations

A synced table is created and maintained by a managed pipeline. It’s fully queryable using standard Postgres tools and works well for joins with other Postgres tables at query time. While superuser roles could technically write to these tables, Databricks strongly recommends against it. Writing directly to synced tables risks divergence and interference with the pipeline. The clean model is to treat the UC source as authoritative and let the sync do its job.

Bringing PostgreSQL into Unity Catalog as a foreign catalog

Yes, this is supported through Lakehouse Federation. You can create a connection to an external PostgreSQL database using JDBC credentials and then define a foreign catalog in Unity Catalog. This mirrors the external database into UC, applies UC governance, and pushes queries down to Postgres. By design, these federated databases are read-only.

Lakehouse Federation is read-only for external sources like PostgreSQL. The only writable exception is an internal federated Hive metastore scenario. JDBC-based external databases remain read-only.

If you’re specifically working with Lakebase Postgres, you can also register a Lakebase database in Unity Catalog as a read-only catalog. This allows browsing in Catalog Explorer and running governed, read-only queries via SQL warehouses, while all data modification continues to happen directly in Lakebase/Postgres.

Practical patterns that tend to work well

For UC Delta to Lakebase Postgres, typically for application serving:

Create a synced table, choosing Snapshot, Triggered, or Continuous based on freshness needs.

If writes are required in Lakebase, copy from the synced table into your own Postgres table and write there, keeping the synced table as the authoritative mirror from UC.

For Lakebase Postgres to UC Delta:

Use Lakeflow Connect for Postgres to Delta when it’s available to you. That’s the productized path.

Until then, a Databricks job that reads from Postgres and writes to Delta using Spark connectors is the practical alternative.

For external PostgreSQL as a foreign catalog in UC:

Create a connection, define a foreign catalog, grant SELECT privileges, and run read-only federated queries under Unity Catalog governance.

Hope this helps clarify the boundaries and the “happy paths” across these options. Cheers, Louis