Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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 |
|---|---|---|---|
| Logical replication | In and out | A Postgres database | You migrate an existing Postgres database into Lakebase, replicate between Lakebase databases, or stream changes to an external Postgres database. |
| Change Data Feed | Out | A Unity Catalog managed Delta table | You want Lakebase changes in the lakehouse for analytics, ETL, or audit. |
| Synced tables | In | A Lakebase Postgres table | You want to serve lakehouse data from Postgres for low-latency reads. |
| Read replicas | Within Lakebase | A read-only compute | You want to scale read traffic without copying data. |
| pg_dump and pg_restore | In and out | A Postgres database | You do a one-time copy or a backup, and downtime during the copy is acceptable. |
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.