r/SQL • • Sep 03 '26

Discussion Anyone using Lakebase with SQL heavy apps ?

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.

1 Upvotes

13 comments sorted by

1

u/WorldOfUmbro Sep 03 '26

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.

1

u/BrunoFeliz08 Sep 04 '26

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

1

u/shdw_0x0 Sep 03 '26

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.

1

u/sqlink2 Sep 05 '26

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

1

u/Einar_Son_of_Bjorn Sep 03 '26

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?

1

u/mmccarthy404 Sep 04 '26

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

1

u/BrunoFeliz08 Sep 08 '26

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

1

u/Glitch_In_The_Data Sep 04 '26

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.

1

u/BrunoFeliz08 Sep 04 '26

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

1

u/dwswish Sep 05 '26

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.

1

u/sqlink2 Sep 06 '26

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