Databricks Lakebase Migration Tools
Databricks moves data between its own two halves. Everything outside is on you.
There is no native path into Lakebase from a MySQL, SQL Server, Oracle or PostgreSQL server you run. DBConvert is one, and it runs both ways.
What Databricks Moves for You, and What It Doesn't
Both native paths stay inside Databricks.
| Route |  Native Databricks path |
 DBConvert |
|---|---|---|
| Lakehouse Delta → Lakebase | Synced tables. Databricks recommends running only read queries against them in Postgres. | Databricks handles it. |
| Lakebase → Lakehouse Delta | Lakehouse Sync, in Public Preview. Lands as lb_<table>_history in Unity Catalog. |
Databricks handles it. |
| MySQL, SQL Server, Oracle or your own PostgreSQL → Lakebase | None. | Yes, with scheduled sync afterwards. |
| Lakebase → a database you run yourself | None. | Yes, the same converter runs both ways. |
Databricks moves data between the lakehouse and Lakebase. It does not move data between Lakebase and anything outside Databricks. Lakebase is Databricks' managed PostgreSQL and answers the standard protocol on port 5432, so a converter that already handles Postgres reaches it - and that is the whole job DBConvert does here.
Start your Lakebase migration
Pick the engine on the other side - each converter runs both ways, into Lakebase or back out. Free trial, Windows.
Lakebase Blocks Logical Replication. Triggers Still Work.
Which decides how you keep a Lakebase database in sync with anything else.
You cannot stream Lakebase changes anywhere but Databricks
Databricks blocks the publication that PostgreSQL logical replication depends on. Tools that read the replication log - Debezium, Fivetran, DBConvert Streams and the rest - have nothing to read.
CREATE PUBLICATION ...
ERROR: Feature not supported by Databricks (SQLSTATE 0A000)
The Databricks docs put it as: replicating data to or from a Lakebase database using native Postgres logical replication "is not yet available". Databricks reads the write-ahead log itself - its Lakehouse Sync feed streams Lakebase changes into Unity Catalog Delta tables - but that pipe has exactly one destination, and it is not a database you run.
Trigger-based sync works instead
DBConvert watches the tables themselves. Trigger-based synchronization puts INSERT, UPDATE and DELETE triggers on the tables you sync and writes every change to a history table, then reads that history on the next run.
It never touches the replication log, so the block does not apply. All it needs is permission to create tables and triggers, and Lakebase gives you both.
We confirmed it on a live Lakebase database: triggers fire normally on insert, update and delete.
Not Databricks' "Triggered" mode. Synced tables run in Snapshot, Triggered or Continuous mode - there the word describes when a refresh starts, and it only ever moves lakehouse Delta data into Lakebase. DBConvert's triggers are Postgres INSERT, UPDATE and DELETE triggers on your own tables, and they work between Lakebase and MySQL, SQL Server, Oracle or PostgreSQL.
Both observations above were measured against a live Lakebase instance, not taken from documentation. A validated end-to-end synchronization run against Lakebase is in progress; if you are planning one, tell us about your setup and we will confirm against it.
Lakebase Connection Parameters
Standard PostgreSQL fields. Take the values from the Connect dialog in your Databricks workspace.
| Field | Value |
|---|---|
| Host | ep-name-id.database.region.cloud.databricks.com |
| Port | 5432 |
| Database | databricks_postgres on a new project |
| User | A native Postgres role, not your Databricks identity |
| SSL | Required. Unencrypted connections are refused |
Step-by-step setup, including the exact Databricks screens, is in Connect Databricks Lakebase. In the Connect dialog, set Role to your password role before copying the string. Left on your Databricks identity it produces an OAuth string, and connecting with it fails on SQLSTATE 28P01.
Common Lakebase Scenarios
Seed an application database
Move an existing MySQL, SQL Server or Oracle database into Lakebase so the application that will run next to the lakehouse starts with real data.
Take data back out
Export Lakebase tables into PostgreSQL you run yourself, for an environment outside Databricks or to leave the platform.
Keep two systems aligned
Run scheduled synchronization between Lakebase and a production database when a one-time copy is not enough and the replication log is unavailable.
Ready to Move Data In or Out of Lakebase?
Browse every PostgreSQL pair, or read how scheduled synchronization works.