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

[AGASTYA ANOOP SHARMA]

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 solution]

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 solution]

hi @AGASTYA ANOOP 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 solution]

Hello @AGASTYA ANOOP 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 🤠