Scaling Jira to ~6M Versions
Atlassian reduced Jira Search’s version-resolution time from 18 seconds to 92 milliseconds by splitting queries into project-scoped and unscoped paths and optimizing PostgreSQL lookups.
Jira Search previously loaded millions of software release versions into memory to resolve queries, a process that became unworkable as customers scaled to nearly 6 million versions. The system filtered these versions in memory before executing each query, causing P99 resolution times to reach around 18 seconds for the largest deployments. This approach strained application resources and introduced latency that disrupted user workflows relying on version-based searches.
The bottleneck centered on version functions in JQL, such as earliestUnreleasedVersion(), which required scanning all versions to identify the correct one. For customers with 6 million versions, this step could generate lists of over 100,000 version IDs before the query even reached the database. The in-memory filtering method failed to scale, leading to timeouts and memory exhaustion during peak usage periods.
Engineers identified that over 80% of version-function queries included a project clause, which narrowed the search space dramatically. By splitting resolution into project-scoped and unscoped paths, the team reduced the data processed per query from millions of rows to a few hundred. This change cut memory consumption from approximately 3 GB to 250 KB for version data and lowered P99 resolution time to 92 milliseconds.
For project-unscoped queries, the team implemented chunked PostgreSQL lookups to avoid full table scans caused by long IN lists. Batches were sized to ensure the database used the indexed version_id column, reducing fetch times from over 30 seconds to under 700 milliseconds. The solution balanced batch size to prevent excessive parallel calls while maintaining indexed lookups.