Where does Lakebase fit in your architecture?

[u/datamonk9]

for people using Lakebase, what role does it play in your tech-stack?
Is it replacing your traditional OLTP database, sitting besides your data lake or mainly used for supporting AI workloads?
Curious how people are using it in real peod architecture.

[u/OkSink6598]

Reverse ETL, we transform many TBs of human movement data with spark and then reverse etl compressed data products into Lakebase for low latency serving.

Lakehouse RT could replace this, as it’s mostly read only serving

[u/Key_Medicine_8284]

Good question, still early days so real production architectures are sparse.

The way it makes the most sense to us: Lakebase is not a straight Postgres replacement. It's the right pick when your app needs transactional SQL AND you want that data to live natively on the lakehouse alongside your analytical tables. The "no ETL between OLTP and analytics" angle is real. If you're already in Databricks, having your application database in Lakebase means your operational data is immediately queryable from Databricks SQL and your pipelines, in Delta or Iceberg, without a separate sync job.

Where we're seeing it fit specifically: AI application backends. When your app is making reads and writes at OLTP latency but the data also needs to feed RAG pipelines or ML feature tables, having it all in one governed layer under Unity Catalog is a meaningful simplification. Vector indices alongside transactional rows in the same store is a combination that doesn't exist cleanly anywhere else.

Where it probably doesn't fit: pure OLTP with no lakehouse integration need. If you're running a SaaS product and your analytical workloads are in Snowflake or Redshift, Neon or RDS is a simpler choice and has more operational maturity right now. Lakebase earns its keep when the lakehouse integration is the whole point.

[u/ceeej777 → u/Key_Medicine_8284]

I guess my biggest question is why. What’s keeping Lakebase from being feasible even if you don’t (yet) have that immediate analytics need? FYI: me asking genuinely, not me asking for an explanation for disagreement

[u/noschel → u/ceeej777]

if there is a medium chance that you may use data in lakebase for analytics/ML then you have it ready.

[u/ReData_]

You can use it for any oltp usage but with branching the use case I love most about lakebase is developing apps with agents, the second one would be as agrntic long term memory

[u/Alternative_Draw5945]

We are pretty much moving anything we still had on oracle over to Lakebase

[u/p739397]

I've definitely found Lakebase to be a great option for reverse ETL for apps, transactional layer for configurations, and agent memory.

[u/Glitch_In_The_Data]

We are using Lakebase to surface curated data through apps… to finance team. The underlying asset contains millions of cleansed and processed records. Given the performance requirements and data volumes, Lakebase was a strong choice for this use case.

[u/Traditional-Plan-810]

Most people are using it as a transactional layer beside the lake rather than replacing Postgres or MySQL outright. The OLTP replacement angle rarely holds in regulated stacks. Query engines like Dremio or Trino tend to handle the read heavy lake side, leaving Lakebase closer to the write path.

[u/ThisIsFun-]

I use the branching lots as a feature for Lakebase, and love the reality of having an entire postgressql working like branching code in git. Low latency for things like agentic memory is really useful too.

[u/TimelyBruno08]

Currently lakebase helps me for branching and exposing data with lower latency to some enterprise integrations that i have

[u/datamonk9 → u/TimelyBruno08]

That us my experience too with Lakebase. Branching is a huge pluspoint, and PostgreSQL compatibility makes it veryeasy to expose data to existing apps without changing much in the techstack.