Move data in and out of Lakebase
Lakebase offers several ways to move data, each suited to a different destination and goal. Use this page to choose the right one.
Compare the methods
Method | Direction | Destination | Use it when |
|---|---|---|---|
In and out | A Postgres database | You migrate an existing Postgres database into Lakebase, replicate between Lakebase databases in different regions, or stream changes to an external Postgres database. | |
Out | A Unity Catalog managed Delta table | You want Lakebase changes in the lakehouse for analytics, ETL, or audit. | |
In | A Lakebase Postgres table | You want to serve lakehouse data from Postgres for low-latency reads. | |
Within Lakebase | A read-only compute | You want to scale read traffic without copying data. | |
In and out | A Postgres database | You do a one-time copy or a backup, and downtime during the copy is acceptable. |
For cross-region resiliency rather than data movement, use disaster recovery, which replicates a project's data to a secondary workspace in another region at the storage layer.
A note on the word "replication"
Several Lakebase features use the word replication for different mechanisms. Do not confuse them:
- Logical replication copies row-level changes between Postgres databases.
- Read replicas serve reads from the same storage as the primary compute. They do not copy data.
- Disaster recovery copies a project's data to another region at the storage layer.
Next steps
- Migrate into Lakebase: Replicate an existing Postgres database into Lakebase. See Replicate data into Lakebase.
- Store changes in the lakehouse: Capture Lakebase changes as Delta. See Lakebase Change Data Feed.
- Serve lakehouse data: Sync Unity Catalog tables into Postgres. See Serve lakehouse data with synced tables.