fix: add missing indexes for top CPU-consuming queries

[CAFxX]

Summary

• Two of the top 5 queries by CPU usage on our database are doing full table scans due to missing indexes.
• LiteLLM_VerificationToken(key_alias): The virtual keys listing query filters on team_id and sorts by key_alias ASC. The team_id index exists but there's no index to support the ORDER BY, forcing a sort on every request.
• LiteLLM_SpendLogs(user, startTime): The spend summary query filters on user = $1 AND startTime BETWEEN $2 AND $3 and groups by multiple columns. There's a startTime index but no composite index with user as the leading column, so Postgres can't efficiently seek to the right user's rows.
• Includes the Prisma migration file.

Test plan

• Schema changes are consistent across all three schema.prisma copies
• Migration SQL matches the schema index definitions
• Verify indexes are created on deploy via \di in psql

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Mar 10, 2026 3:13pm

[greptile-apps]

Greptile Summary

This PR adds two database indexes to optimize CPU-consuming queries:

• LiteLLM_SpendLogs(user, startTime) — A well-designed composite index that efficiently supports the spend summary query pattern (WHERE user = $X AND startTime BETWEEN Y AND Z GROUP BY ...). PostgreSQL can seek to the right user and scan in startTime order without additional sorting.
• LiteLLM_VerificationToken(key_alias) — A single-column index supporting key listing queries sorted by key_alias ASC. While the PR description mentions team_id filtering, the actual query has a complex WHERE clause with multiple conditions; a single-column index on the ORDER BY column is appropriate for this pattern.

The migration correctly uses CREATE INDEX CONCURRENTLY with defensive DROP INDEX ... IF EXISTS statements to avoid table locks during index creation. The -- SkipTransactionBlock directive is properly set for Prisma compatibility. Both indexes are consistent across all three schema.prisma files.

Confidence Score: 5/5

• This PR is safe to merge. It adds only indexes (no data migrations), uses production-safe CONCURRENTLY syntax with defensive drops, and maintains consistency across all schema files.
• Both indexes are correctly designed for their actual query patterns: the composite (user, startTime) index efficiently supports spend queries with equality and range filters; the single-column key_alias index supports sorting in the complex key listing query. The migration uses CONCURRENTLY to avoid table locks and includes defensive DROP statements for reliability. No data integrity or backward compatibility risks.
• No files require special attention

_{Last reviewed commit: 069ade2}