Repository navigation
Analytics: Optimize N+1 query issue #1255
Description
Is your feature request related to a problem?
The Analytics API has an N+1 query issue with GET /api/v1/analytics/monthly/chart, resulting in excessive database load and slower response times as the number of LLM calls grows. This problem arises because each row triggers a separate query on model_config.
Describe the solution you'd like
- Optimize the API to fetch model pricing in a single query instead of multiple queries.
- Ensure that the solution scales effectively with increasing usage data.
Original issue
Describe the bug
GET /api/v1/analytics/monthly/chart (and /analytics/monthly) runs a separate SELECT ... FROM global.model_config query for every row returned by the main llm_call aggregation, to fetch that model's pricing. One request made ~98 repeated queries. Sentry flagged it as an N+1 query.
The number of queries grows with the number of (month × modality × provider × model) rows, so the API gets slower and puts more load on the database as usage data grows.
To Reproduce
- Use an organization/project with LLM calls across several models and months.
- Call
GET /api/v1/analytics/monthly/chart?metric=cost(any metric triggers it). - Open the request trace in Sentry.
- See one aggregation query on
llm_callfollowed by N repeatedmodel_configqueries.
Expected behavior
Model pricing should be fetched in a single query, no matter how many rows the aggregation returns.
Activity
[-]Analytics API: N+1 query on model_config when calculating cost[/-][+]Analytics: Optimize N+1 query issue[/+]github-actions commentedon Oct 14, 2026
🎉 This issue has been resolved in version 1.8.0-main.5 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀