Description
Databricks Lakebase and Amazon RDS for PostgreSQL side by side, on the same app, the same data and the same Postgres version: creating a database, scaling, branching, recovery, Unity Catalog, and a live migration from RDS to Lakebase with logical replication.
⏰ Chapters
00:00 - Lakebase vs Amazon RDS Explained: Two Architectures
01:00 - Create a Database: Lakebase in 13 Seconds vs RDS in 9m 39s
02:50 - Traffic Spike: Lakebase Autoscaling vs Resizing RDS
04:12 - Scale to Zero vs Stopping an RDS Instance
05:18 - Branching vs Point-in-Time Restore into a New RDS Instance
06:58 - Recovering from a Bad UPDATE and High Availability
08:12 - Query Lakebase from Unity Catalog and Sync Data Back
10:23 - Migrate from RDS with Postgres Logical Replication
12:07 - Cutover in 27 Seconds and Which One to Choose
⚖️ How the two architectures differ
Both are managed Postgres. RDS runs each database on a fixed-size instance with its own disk, so compute and storage are sized together up front and billed around the clock. Lakebase separates them: serverless compute that follows the load down to zero, and shared storage where a new branch points to the same data instead of copying it. Lakebase is registered in Unity Catalog, so its tables sit next to the rest of your lakehouse data, and synced tables bring lakehouse results back into Postgres.
🛠️ What you'll see in the demo
Using a coffee shop database with 25,000 customers and 1 million orders on PostgreSQL 17.11, in us-west-2:
• A provisioning race: Lakebase answered its first query in 13 seconds, RDS in 9 minutes 39 seconds
• A 48-client spike on Lakebase with zero failed queries, vs an RDS resize that left the database unreachable for about 2 minutes
• Scale to zero on a Lakebase dev project vs stopping and starting an RDS instance
• A branch with all 1 million orders ready in 8 seconds, vs a 12-minute point-in-time restore into a new RDS instance
• Recovering from an UPDATE without a WHERE clause by restoring to the minute before it
• Querying live Lakebase orders from a SQL warehouse through Unity Catalog, and a synced table that brings a lakehouse change back to the app in 16 seconds
• A live migration: a publication on RDS, the schema copied with pg_dump, a subscription on Lakebase that copied 1 million orders in 18 seconds, and a cutover with writes paused for about 27 seconds
Whether you're evaluating managed Postgres for a new app, running RDS today and paying for idle capacity, or planning a migration, this comparison shows where Lakebase and RDS differ and how to move a live database with only seconds of downtime.
🔗 Resources
📘 Lakebase documentation: https://docs.databricks.com/aws/en/oltp/
🔁 Lakebase logical replication: https://docs.databricks.com/aws/en/oltp/projects/logical-replication
🗂️ Register Lakebase in Unity Catalog: https://docs.databricks.com/aws/en/oltp/projects/register-uc
🚀 Databricks Lakebase: https://www.databricks.com/product/lakebase
🤝 Stay connected
Website: https://databricks.com
Twitter: https://x.com/databricks/
LinkedIn: https://www.linkedin.com/company/databricks/
Instagram: https://www.instagram.com/databricksinc/
Facebook: https://www.facebook.com/databricksinc/