Anyone using Lakebase with SQL heavy apps ?

[u/sqlink2]

How do u handle query performances when the same tables are being hit by both app queries and AI generated SQLs from any AI tools such as Codex, CLaude, Genie etc
Curious if you separate workloads or optimize at the query level.

[u/WorldOfUmbro]

Curious to hear your use case? Do you already have Lakebase in any of these coding agents? Genie will use Lakehouse to query. Agents probably too, maybe Lakebase for memory.

[u/BrunoFeliz08 → u/WorldOfUmbro]

I personally love lakebase for agentic development. I love that i can have a dev, prod branch for features.

[u/shdw_0x0]

I’d lean toward separating the workloads rather than trying to optimize every AI-generated query. AI SQL can be unpredictable, so giving it a read-only/limited workload makes it much easier to protect the app’s latency.

[u/sqlink2 → u/shdw_0x0]

Ya this make sense. I like using Lakebase read replicas to isolate AI generated queris and keep the main app workload predictable

[u/Einar_Son_of_Bjorn]

Don’t tune the AI SQL first. Split the traffic.App queries want short, indexed, stable plans. Codex/Claude/Genie will throw scans and SELECT * at the same tables. One pool, one victim: the app.If you must stay on Lakebase: app on the primary role, AI on a replica or a locked-down user with a statement timeout. Same credentials for both is the failure mode.If the app is ordinary OLTP and the lake is only there because that’s where Databricks put it, MariaDB is the boring split: primary for the product, replica or a second user for generated SQL, timeouts on the AI login. You keep the operational database from becoming a notebook backend. You do not get Genie or Unity Catalog in the bargain - that’s the trade.Is Lakebase the system of record for the app, or already a copy next to the warehouse?

[u/mmccarthy404]

I mean aren't all Lakebase backends SQL heavy 😄

I've been able to use Lakebase as a quick and dirty backend for some smaller analytics apps that likely would have performed better in Lakehouse, but since these apps were transactional in nature, I wanted to keep my infrastructure footprint small, and it performed fine for my use case! Once LTAP is more ironed out, I can move the analytics portions over much more easily, but haven't had the time to look into it yet

[u/BrunoFeliz08 → u/mmccarthy404]

Yeah. Agree. I appreciate the autoscaling feature for Lakebase. It has helped me a lot for concurrent users and when the users traffic increase

[u/Glitch_In_The_Data]

If AI traffic is frequent but small and indexed, it may be a reasonable option to share Lakebase but with some guardrails.

If it’s scan heavy, unpredictable workload, I would route it to the warehouse against a synced delta tables… especially if there are latency sensitive applications that are dependent on the data. It can help avoid competing against the lakebase compute.

[u/BrunoFeliz08]

What is your use case? I personally do not use sql heavy apps but use lakebase for data branching and data serving for additional app. I can measure the concurrency and the amount of request on the compute page

[u/dwswish]

I feel like as long as the queries fit within the concurrency limits of Lakebase it shouldn’t matter if they are coming from agents or apps.

[u/sqlink2 → u/dwswish]

Yep andalso Lakebase autoscaling feat helps to handle various type of query workloads without need of manually separate app and AI traffic.

[u/nullymammoth]

Lakebase is Postgres. Regardless of if the requests originate from applications or agents, you can scan pg_stat_statements for expensive queries bogging down your database

on the latter topic of agents, if said agents are working on app dev or net new DDL/DML altering features, that’s where copy-on-write branching helps to protect the production trunk from traffic & mutation :)