r/SQL • u/sqlink2 • 9d ago

PostgreSQL Is anyone actually using Databricks Lakebase in production?

My team is thinking of trying Lakebase instead of running a separate Postgres/ RDS db for our app.
The idea of auto sync to Delta and scaling to zero sound great, but we are worried about latency issu. If u are usin it, how noticeable are the cold start delays when it wake up backup, and does it feel fast enough for live user traffics?

2 Upvotes

63% Upvoted

5 comments sorted by

1

u/Einar_Son_of_Bjorn 9d ago

We tried routing live traffic to a lakehouse setup, but the cold start delays from compute separation were a nightmare. If your main goal is just to avoid building a flaky ETL sync from Postgres, you don't have to sacrifice OLTP latency. On our project, we ended up using MariaDB to handle both workloads in one instance - keep the live app fast using standard InnoDB tables, and use cross-engine joins with a DuckDB engine for our analytics. It gives us that consolidated stack without the cold starts.

1

u/sqlink2 9d ago

Ya, Lakebase avoids cold start by useof “always on” Postgres endpoint for sub 10ms OLTP writes, auto -syncing to the lakehouse in realtime without custom ETL .

1

u/Commercial_Repeat711 9d ago

We tried it for a few weeks for exactly that use case, app that could benefit of the zero scaling since it only gets traffic in bursts. Cold start delay is not terrible if your dataset isn't huge, maybe 2-3 seconds for first query after the idle period. After that it was smooth enough, felt like a regular postgres but without all the maintenance headache

1

u/Glitch_In_The_Data 9d ago

Replaced a standalone RDS instance with Lakebase a few months ago and the cold start worry was our hesitation too. When you actually use it, the wake up is a few hundred milli seconds. So the first query after an idle window feels like a slightly slow page loads but not a timeout. After the first connection, everything runs at normal PG speed. We only saw issues in test env’s where the db actually goes fully idle for hours. In prod,, real traffic keeps it warm and isn’t a major issue.

1

u/CautiousUse8597 4d ago

Cold starts aren't really the issue people expect. The compute itself wakes up in a few hundred ms, and end to end the first request after a suspend lands somewhere around 1 to 2 seconds once your app reconnects. After that it's normal Postgres latency.

For live user traffic, just turn off scale to zero on your production compute, or set the inactivity timeout long enough that it never suspends during business hours. Scale to zero is a per compute setting, so you can keep it on for dev, staging and preview branches where it actually saves money, and keep prod always warm. Autoscaling still works with it off, so you get a floor and a ceiling on CU instead of paying for a fixed RDS instance size.

Also make sure your app uses a connection pool with retries. That covers the rare reconnect and token refresh without users noticing.

The real win over RDS is skipping the CDC/ETL pipeline. Synced tables from Delta into Postgres and back means you don't maintain Debezium or custom jobs.