At what point do custom fields become a performance or maintenance problem?

Question

Hello everyone, I've seen Jira instances ranging from fewer than 100 custom fields to several thousand. I understand that excessive custom fields can affect administration and potentially impact indexing and search performance, but I'm curious about practical experience. Have you reached a point where custom fields became a noticeable problem?How do you decide whether a new custom field is justified?Do you have governance policies for approving new fields? I'd appreciate hearing how different organizations manage this.

Kai Krause · Accepted Answer

Hi,

Official Jira Cloud guardrails (already in effect since March 2026):* Max 700 fields per project — once a project hits this, you can't add more without cleanup
* Max 10,000 options per select-list field (rising to 20,000 in September 2026)

These aren't "soft" recommendations anymore — they're hard platform limits Atlassian is enforcing site-wide to protect performance for everyone, not just you

Im my Opinion and experience with dc and cloud :
As much as necessary, as little as possible.

How I decide for me

* Does an existing field already cover this?
* Can this be achieved with a native feature instead?
* Is this needed globally, or just for one project?

"Goverance" that worked for me

* Single and simple  intake process
* Naming conventions
* Quarterly field audit: Jira Cloud now shows field usage stats natively (admin → Issues → Custom fields → usage column)
* Context review before approval

BR

Kai

Viswanathan Ramachandran · Accepted Answer

hi @AGASTYA SHARMA

It's a common pain point. We all know that uncontrolled custom field growth can create challenges around administration, user experience, reporting consistency, and potentially indexing/search performance

I echo @Kai Krause

In my experience, custom fields usually become a problem when they are not governed rather than because of a specific number.

For larger Jira instance(s) the real issue came from:

* duplicate fields created for the same purpose
* too many globally scoped fields
* unused legacy fields increasing administration overhead
* complex screens making the user experience poor
* reporting becoming inconsistent because different teams captured similar data differently

When evaluating a new custom field, I usually ask:

* Is this information required for a business process, workflow, reporting, or compliance need?
* Can an existing field be reused or configured with a different context?
* Is this better handled through another native Jira capability?

For governance, I recommend having:

* a clear naming convention
* approval before creating new fields
* periodic reviews to identify unused or duplicate fields

The goal is not to minimise the number of fields, but to ensure every field has a purpose, ownership, and lifecycle.

Arkadiusz Wroblewski · Accepted Answer

Hello @AGASTYA SHARMA

While Jira Cloud hits a hard wall at 700 fields per space, you really want to step in much earlier around the 75% mark (~525 fields) when Atlassian’s Site Optimizer starts flagging warnings.

Long before the system itself slows down, field bloat will wreck your user experience with duplicate concepts, cluttered screens, and a web of untraceable reporting or automation dependencies.

Before you say yes to a new field, challenge it: does something similar already exist, and does this data absolutely need to be queried or integrated? 👍🤔🔍🤝

If not, use Jira Forms, components, or labels. Instance health means keeping global contexts tight, monitoring counts per space, and aggressively cleaning up old data, not a single site-wide total. Every approved field needs a clear purpose, owner, and exit strategy.

Cheers,

Arek 🤠