Skip to content
Notifications
Clear all

Anyone else find Helicone's SQL editor slow on large datasets?

3 Posts
3 Users
0 Reactions
1 Views
(@grafana_guy_night)
Reputable Member
Joined: 4 months ago
Posts: 157
Topic starter   [#22407]

Hey everyone,

I've been using Helicone for a few weeks to track LLM costs and latency. Love the concept! But I'm hitting a snag.

When I try to write a custom SQL query against our request logs (we have a few million rows now), the editor feels really sluggish. Typing lags, and running a simple `COUNT` can take 10+ seconds. My query isn't even that complex:

```sql
SELECT model, COUNT(*) as request_count
FROM request
WHERE created_at > NOW() - INTERVAL '7 days'
GROUP BY model;
```

Is this normal for larger datasets, or is my setup maybe the issue? I'm on their default cloud plan. Wondering if anyone else has tips or if I should be summarizing data differently first.

Thanks!



   
Quote
(@chrisk)
Estimable Member
Joined: 2 weeks ago
Posts: 118
 

That's a typical scaling wall. I'd check if your `created_at` column has an index, because without one that WHERE clause forces a full table scan on millions of rows. Even with an index, a `COUNT(*)` on a 7-day range might still be heavy if your date filter selects a large portion of the table.

You could test with a narrower window first:
```sql
SELECT model, COUNT(*) as request_count
FROM request
WHERE created_at > NOW() - INTERVAL '1 day'
GROUP BY model;
```
If that's fast, then the issue is primarily data volume. For regular reporting, you're right to consider pre-aggregation. I run a daily materialized view for key metrics and query that instead of the raw logs.



   
ReplyQuote
(@integration_tinkerer)
Estimable Member
Joined: 4 months ago
Posts: 117
 

Yeah, the materialized view approach is solid for recurring reports. I've done something similar with a nightly cron job that dumps aggregated counts (by model, status code, user) into a separate reporting table. Queries against that are instant.

One caveat - if you need to drill down into specific anomalous requests, you still need the raw logs. So we keep the detailed data but treat it as a "cold" archive for forensic queries only.



   
ReplyQuote