Hi @gokkul,

There are a few different patterns here depending on which direction you need data to flow. Let me break them down.

READING DELTA/UC DATA FROM LAKEBASE (UC to Postgres)

Synced tables are the primary mechanism for this. They automatically synchronize data from a Unity Catalog table into your Lakebase Postgres database, giving you low-latency reads via standard Postgres queries.

You can create a synced table using the Python SDK, the Databricks CLI, or the REST API. Here is a Python SDK example:

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.database import SyncedDatabaseTable, SyncedTableSpec

w = WorkspaceClient()
synced_table = w.database.create_synced_database_table(
  SyncedDatabaseTable(
      name="database_catalog.schema.synced_table",
      spec=SyncedTableSpec(
          source_table_full_name="source_catalog.source_schema.source_table",
          primary_key_columns=["id"],
          scheduling_policy=SyncedTableSchedulingPolicy.TRIGGERED
      )
  )
)

Three sync modes are available:
- Snapshot: one-time full copy, can be refreshed manually or on a schedule. Best when more than 10% of the source table changes between refreshes.
- Triggered: incremental changes synced on demand. Good balance of freshness and cost.
- Continuous: real-time incremental updates for lowest latency.

For Triggered or Continuous mode, the source Unity Catalog table must have Change Data Feed enabled.

As you noted, synced tables are intended to be read-only on the Postgres side. While it is technically possible to write to them, Databricks strongly recommends running only read queries on synced tables to protect data integrity with the source. Modifications can interfere with the synchronization pipeline.

Documentation: https://docs.databricks.com/aws/en/oltp/instances/sync-data/sync-table

WRITING DATA IN LAKEBASE THAT ORIGINATES FROM DELTA

If you need a writable copy of the data in Lakebase Postgres, the recommended approach is to create a regular Postgres table from the synced table:

CREATE TABLE my_writable_copy AS SELECT * FROM synced_table;

This gives you a standard Postgres table that you can read from and write to freely, independent of the sync pipeline. The trade-off is that this table will not automatically stay in sync with the UC source, so you would need to manage refreshes yourself if the source data changes.

QUERYING LAKEBASE DATA FROM DATABRICKS (Postgres to Delta)

You have two options here:

1. Register your Lakebase database in Unity Catalog. This creates a read-only catalog representation of your Postgres database, letting you run federated queries from Databricks notebooks or SQL warehouses against your Lakebase data. This is built into Lakebase, no separate connection setup needed.

 Documentation: https://docs.databricks.com/aws/en/oltp/instances/register-uc

2. Lakehouse Federation for PostgreSQL. You can also set up any external PostgreSQL database (including Lakebase) as a foreign catalog in Unity Catalog. This enables federated queries from Databricks, though it is read-only and does not support joins or window functions in the pushdown.

 Documentation: https://docs.databricks.com/aws/en/query-federation/postgresql

CAN YOU BRING A POSTGRESQL DATABASE INTO UC AS A FOREIGN CATALOG?

Yes. Both approaches above accomplish this. If your Lakebase database is already provisioned, registering it in Unity Catalog (option 1 above) is the simplest path. For external PostgreSQL databases outside of Lakebase, Lakehouse Federation (option 2) is the way to go.

SUMMARY

- UC Delta to Lakebase Postgres: use synced tables (read-only on Postgres side) or CREATE TABLE AS SELECT for a writable copy.
- Lakebase Postgres to UC/Delta: register your Lakebase DB in Unity Catalog for federated queries, or use Lakehouse Federation.
- Foreign catalog: yes, both registration and federation create a catalog in Unity Catalog that represents your Postgres database.

The main Lakebase documentation hub is here: https://docs.databricks.com/aws/en/oltp

Hope this helps clarify the options available.

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

If this answer resolves your question, could you mark it as "Accept as Solution"? That helps other users quickly find the correct fix.