Jira Custom Fields: The Hidden Performance Cost Nobody Warns You About
Custom fields are the easiest thing to add in Jira and one of the most expensive. Here is why your instance slows down as the field count grows, and what to do about it.
Custom fields are the first thing a new Jira admin reaches for. A team needs a new piece of data, you create a custom field, and everyone gets on with their day. It is trivially easy, and that is the problem.
Every Jira instance we have reviewed that is slow, and where the slowness is not obviously caused by something else, has a custom field problem. The field count has crept up over years, nobody has ever deleted anything, and every new field adds a small, invisible tax to almost every operation in the system.
Here is what is actually going on.
Why Custom Fields Are Expensive
In Jira's data model, each custom field added to an issue is a row in a separate table. When an issue is queried, every applicable custom field value needs to be joined and retrieved. When an issue is indexed, every custom field value contributes to the index.
This means that the cost of a custom field is not just the storage of its data. It is multiplied across:
- Every issue view, because the fields need to be rendered
- Every issue search, because JQL queries need to evaluate field values
- Every index rebuild, because Lucene needs to re-index every field for every issue
- Every board load, because the board logic touches custom fields
- Every plugin that enumerates fields, which is more plugins than you think
Atlassian's own performance guidance is explicit about this: custom field count is one of the factors that most directly correlates with Jira performance degradation. They recommend keeping the total number of custom fields under 200 where possible. We regularly see instances with two thousand.
The Specific Things That Go Slow
Index rebuilds are the most visible symptom. An index rebuild on a large instance with thousands of custom fields can take hours, and during that time the instance is degraded. Teams with many custom fields often avoid rebuilding the index even when they should, which leads to the secondary problem of stale index data and bad search results.
JQL query performance is the next. Queries that filter on custom fields, particularly text or user-picker fields, get slower as the total field count grows. "Why are my filter dashboards slow?" is almost always a custom field problem.
Board load times. Boards are effectively JQL queries dressed up with presentation logic. A board that filters and swimlanes by custom fields will feel noticeably laggy as the field count grows, even if the board's specific JQL is simple.
REST API responses. An issue fetched via the API includes all its custom field values by default. If your instance has thousands of fields and your API consumer is naive about which fields it asks for, responses get large and slow for no good reason.
The "Same Field Three Times" Problem
The second major symptom of a mature Jira instance is duplication. You find three fields that all capture the same concept — "Team", "Squad", and "Group" — created by different people at different times for different projects.
Each of these gets used on some issues and not others. JQL queries that should match all of them only match one. Reports miss data. Over time, the "wrong" version gets used more than the "right" version because it is higher up in the picker.
This is not a technical problem, it is a governance problem, but it manifests as a technical one because the fix usually involves merging fields, which in Jira is genuinely difficult and almost always requires scripting or a third-party app.
What to Actually Do
Audit what you have. ScriptRunner and other marketplace apps provide custom field usage reports. The stock Jira admin has this too, though less prominently — the "Custom Fields" admin page shows usage counts. Sort by issues-using-field, descending. The fields at the bottom, with low or zero usage, are your first targets.
Delete, do not hide. Hiding a custom field from a screen does not remove it from the data model or the index. It just hides it from users. If a field is unused, deleting it is the only way to reclaim the performance cost.
Prefer context-specific fields. When you do need a new field, scope it to the projects and issue types that actually need it. A "Team" field that exists on every issue type in every project is much more expensive than one that exists only in the two projects that need it.
Consolidate before creating. Before you create a new field, search for existing fields that capture something similar. Renaming an existing field is almost always cheaper, to the instance and to the users, than adding another one.
Review regularly. Custom field audits should be quarterly, not "when we realise it has got out of hand". Small, regular cleanups are sustainable. A single heroic cleanup after five years of accumulation is a project that nobody wants to own.
The Specific Fields That Cause the Most Pain
Some field types are more expensive than others, and worth knowing about:
- Multi-select user pickers are among the most expensive fields because they join through the user table for every value.
- Cascading select fields are more expensive than simple select fields because they add extra indexed terms.
- Text fields with heavy indexing can bloat the index significantly if they contain large amounts of text.
- Fields that are actively filtered on in many boards and JQL queries contribute more to query time than fields that are only displayed.
If you have to keep a small number of high-cost fields, that is fine. What hurts is having thousands of them, most of which nobody is actively using.
The Honest Trade-off
Custom fields are how you make Jira fit your team, and making Jira fit your team is the entire point of using it. We are not suggesting austerity for its own sake.
What we are suggesting is that adding a custom field should feel slightly more weighty than it currently does. Each one is a commitment, and the commitment compounds across every user interaction in your instance, forever, until someone has the authority to clean it up.
A small instance with a hundred well-curated fields will outperform a large instance with two thousand fields it has forgotten about, and that performance difference is something your users feel every single day.
For more on the Atlassian platform itself, see our comparison of Forge vs Connect and our earlier write-up on scaling plugins on the Marketplace.
Inherited a Jira instance that has slowed to a crawl and nobody is sure why? Get in touch — custom field audits are part of our Atlassian development work.