Skip to content

ATLASSIAN 2026-05-14 Tier 3

Read original ↗

Atlassian — Optimisation Tools for Jira: Reducing Configuration Bloat and Enhancing Performance

Summary

Atlassian Engineering (Atlassian Blog, 2026-05-14) describes the Jira Cloud Optimisation Tools — a set of admin experiences, an async workflow-driven reporting framework, and bulk-remediation actions that help large Jira Cloud tenants stay under limits and guardrails introduced as Jira scales to "100k+ users and beyond." The underlying architectural problem is configuration bloat: custom fields, work types, screens, schemes, and workflows accumulate over time, slow core experiences (view, search), and push tenants past hard caps such as 700 fields per space, 150 work types per space, 20,000 field options per field, 50 issue security levels per space, and 50 grants per permission.

Three load-bearing architectural decisions are disclosed:

  • A pre-computation framework layered on Atlassian's internal workflow orchestration engine that runs async Initialise → Scan-steps → Finalise jobs whose scan-step workers must be thread-safe, idempotent, and order-agnostic so the orchestrator is free to parallelise and retry without coordination. The Finalise step aggregates per-batch state into a durable report that the UI can consume cheaply.
  • Polymorphic usage tables — instead of one dedicated Postgres table per entity type (which would create "millions of tables across production, plus indexes and internal database objects" in Jira's multi-tenant architecture), a small set of generic "polymorphic" tables stores pre-computed usage data for fields / options / roles / schemes etc. Paired with Memcached for short-lived multi-step intra-job sharing.
  • Utilisation-prioritised refresh — instead of recomputing every space on a fixed schedule ("an enormous volume of jobs which will result in huge load and stress on Jira APIs, Orchestrator, and the database"), reports are refreshed only for spaces near limits (≈70% utilisation). Low-utilisation spaces may see older data, but admins see the last pre-computation timestamp in the UI and can trigger ad-hoc refresh on demand.

The post also names a trust-without-rollback posture for remediation: bulk actions are "targeted and opinionated, based on pre-computed reports," every change is written to Jira's existing audit logs, and admins can "manually reverse or adjust configuration if needed." Assisted rollback exists today; guided in-product rollback is planned.

Key takeaways

  • Limits create a new problem; optimisation tools solve it. "These limits protect and improve core experiences (like view or search work items), but they also create a new problem: how do we help customers get under the limits without breaking their setups?" (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) This is the canonical motivation for pairing limits with optimisation tooling: a multi-tenant SaaS that introduces hard caps must also provide a path for affected tenants to bring their data shape back under the cap. See concepts/configuration-bloat for the underlying problem shape.
  • Two-phase tool model: report, then remediate. "For each supported entity type (today: fields and work types), every tool follows the same two phases: Reporting – find opportunities to bring a space's data shape back under limits and guardrails; Remediation – apply safe, auditable changes based on those findings." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) Reporting is async and per-space; remediation is on-demand bulk-action consuming the report; the report is the contract between the two phases.
  • Pre-computation framework owns workflow / batching / retries / observability; tools own domain decisions. "The pre-computation framework is the layer that makes this repeatable. It sits on top of our internal workflow orchestration engine, owns the workflow, task workers, batching, retries, and observability, and exposes a simple contract. Optimisation tools don't need to care about orchestrator details; they only plug in their logic." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) Canonical separation between platform layer (orchestration / batching / retries / observability) and tool layer (what "unused" means for fields vs work types vs schemes). See systems/atlassian-precomputation-framework for the framework page.
  • Three-phase workflow shape: Initialise → Scan-steps → Finalise. "Initialise – prepare for a new job at a given scope (for example, clear or seed intermediate state) while keeping work bounded in time. Scan-steps – the framework streams Jira entities (work items, screens, fields, and so on) in batches. Tool implementations must be thread-safe, idempotent, and order-agnostic, so the framework is free to parallelise and retry without coordination. Finalise – aggregate everything seen during scanning into a durable report that remediation flows and UIs can rely on." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) This is the canonical three-phase init-scan-finalise contract; the **idempotent + thread-safe
  • order-agnostic** trio is the load-bearing scan-step contract that makes parallelisation and retry safe without coordination.
  • Polymorphic usage tables solve multi-tenant DB-object explosion. "Naively adding one dedicated table per entity doesn't scale in Jira's multi-tenant architecture: a single new table becomes millions of tables across production, plus indexes and internal database objects." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) The mitigation: "For persistent pre-computation, we store data in the Jira relational database using a small set of generic tables (polymorphic 'usage' tables) instead of one table per entity type." This is the canonical polymorphic-usage-tables pattern, the multi-tenant cousin of catalog bloat — but acting at the application schema layer rather than the Postgres pg_class layer.
  • Tiered storage: Memcached for short-lived job-internal state; DB for persistent pre-computed reports. "For short-lived, multi-step sharing inside a job [we use] memcached. For persistent pre-computation, we store data in the Jira relational database using a small set of generic tables." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) See tiered state management: hot working set in cache, durable results in the relational DB, two-layer split chosen for cost / scale / performance balance.
  • Utilisation-prioritised refresh: recompute spaces near limits, not every space. "Recomputing them for every space, on a fixed schedule, is extremely expensive at Jira scale. Refreshing every space regularly would generate an enormous volume of jobs which will result in huge load and stress on Jira APIs, Orchestrator, and the database, without clear customer benefit. We deliberately optimise for smart, prioritised refreshes by recomputing reports only for spaces nearing limits (≈70% utilisation). Some low-utilisation spaces may see older data, but this lets us focus resources on spaces most likely to benefit from optimisation." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) Canonical prioritised refresh by utilisation threshold — accept staleness on irrelevant tenants to preserve compute budget for tenants who actually need it. The cost is acknowledged staleness: admins see "the last pre computation time for usage report" and can trigger "ad-hoc reporting jobs for specific spaces/schemes whenever they want fresh data."
  • Audit-log-mediated rollback: trust the existing audit trail; opinionated targeted actions; manual rollback today, guided rollback later. "Right now we focus on safety and transparency: actions are targeted and opinionated, based on pre-computed reports. All changes are logged in audit logs, so admins can see exactly what changed and manually reverse or adjust configuration if needed. We already have assisted rollback and over time, we plan to add guided, in-product rollback on top of this foundation." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) Canonical audit log as rollback substrate — instead of building snapshot / transaction-rollback infrastructure for destructive bulk changes, lean on the existing audit log and accept manual human-driven rollback as the v1 contract.
  • Outcome-numbers disclosed are aggregate-only. "Admins across organisations have removed tens of millions of unused fields and work types using these optimisation tools. Some customers have streamlined hundreds of thousands of fields and work types in a single day — a process that previously took weeks of manual effort." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat) Plus: "Optimisation tools enable vast majority of tenants to stay within the limits, including our largest enterprise customers."

Systems extracted

  • systems/jira — Atlassian's project / issue tracking product; the host system that introduced the limits and that consumes the optimisation tools. Page extended for Jira Cloud multi-tenant scaling content.
  • systems/atlassian-jira-optimisation-tools — the set of admin experiences plus backend workflows that compute usage reports and apply bulk remediation. First canonical wiki naming.
  • systems/atlassian-jira-site-optimiser — the admin-facing dashboard surface that surfaces configuration issues across spaces. First canonical wiki naming.
  • systems/atlassian-precomputation-framework — the Initialise / Scan-steps / Finalise batch-reporting platform layered on Atlassian's internal workflow orchestration engine. First canonical wiki naming.

Concepts extracted

  • concepts/configuration-bloat — the failure mode the tools exist to fix: configuration entities (fields / work types / schemes / workflows / screens) accumulate over time, slow read paths, push tenants past limits. First canonical wiki home.
  • concepts/polymorphic-usage-tables-multi-tenant — the application-layer structural decision to use generic tables with a (tenant, entity-type, entity-id) key shape rather than one dedicated table per entity type, to avoid creating "millions of tables across production" in Jira's multi-tenant architecture. First canonical wiki home.
  • concepts/utilization-prioritised-refresh-strategy — refresh only the subset of tenants / scopes that meet a utilisation threshold (≈70% of cap), accept acknowledged staleness elsewhere, expose the staleness in the UI plus an ad-hoc-refresh escape hatch. First canonical wiki home.
  • concepts/idempotent-thread-safe-scan-step — the load-bearing scan-step worker contract for orchestrator-led batch processing: outputs must depend only on inputs (no hidden state), workers must be safe to run concurrently on disjoint batches, and order-of-batch-arrival must not affect the final report. First canonical wiki home.
  • concepts/catalog-bloat-multi-tenant — extended: Jira's polymorphic-usage-tables decision is the application-layer cousin of Postgres catalog bloat, with the same root failure-shape (per-entity-type DB objects × many tenants = unsustainable object count) but the mitigation lives at a different altitude.
  • concepts/tenant-isolation — Jira Cloud's tenant unit is the space (Atlassian's renamed project); the optimisation tools' compute and storage costs all scale per-space.

Patterns extracted

  • patterns/asynchronous-precomputed-report-batch-framework — Initialise / Scan-steps / Finalise as a reusable workflow-orchestrated batch-reporting platform; tools plug per-domain logic into a stable framework contract. First canonical wiki home.
  • patterns/polymorphic-usage-tables-for-multi-tenant-scale — small set of generic tables keyed by (tenant, entity-type, entity-id) instead of one table per entity type, to keep total DB-object count bounded as the number of tenants × entity types grows. First canonical wiki home.
  • patterns/prioritised-refresh-by-utilisation-threshold — recompute reports only for tenants near the limit (≈70% utilisation); accept staleness elsewhere; expose the staleness timestamp + on-demand-refresh escape hatch. First canonical wiki home.
  • patterns/tiered-state-management-memcache-plus-db — short-lived multi-step intra-job state in Memcached; persistent pre-computed reports in the relational DB. First canonical wiki home.
  • patterns/audit-log-as-rollback-substrate — for destructive bulk operations on configuration data: keep actions targeted and opinionated based on pre-computed reports, write every change to the existing audit log, lean on the audit log as the manual-rollback substrate rather than building snapshot / transaction-rollback. First canonical wiki home.

Operational numbers

The post is an architecture retrospective with a small set of quantitative claims. None are operational throughput / latency numbers; all are limits, structural cost claims, or aggregate outcome claims.

Limits and guardrails (per space):

  • Up to 700 custom fields per space.
  • Up to 150 work types (formerly issue types) per space.
  • Up to 20,000 field options per field.
  • Up to 50 issue security levels per space.
  • Up to 50 grants per permission.
  • Plus "limits around versions, workflows, components and priorities."

Scale claims:

  • Targeted operating envelope: "100k+ users and beyond" per tenant.
  • Pre-computed usage data per entity type per tenant: "up to ~1M records per entity type, per tenant."
  • Refresh threshold: "≈70% utilisation" triggers recomputation.

Outcome aggregate claims:

  • "Admins across organisations have removed tens of millions of unused fields and work types" using the tools.
  • "Some customers have streamlined hundreds of thousands of fields and work types in a single day — a process that previously took weeks of manual effort."
  • "Optimisation tools enable vast majority of tenants to stay within the limits, including our largest enterprise customers."

No p50/p99 latency, no per-space refresh-job runtime, no Memcached hit-rate, no polymorphic-table row count or query latency, no per-space DB-object footprint comparison (per-entity-type table fanout vs polymorphic) is disclosed. The architectural framing is mechanism-first, numbers-second.

Caveats

  • Polymorphic-table query patterns are not disclosed. "Still allows efficient, indexed queries over usage data" is asserted but the index strategy (composite index on (tenant, entity-type, entity-id)? per-tenant partitioning? per-entity-type partial indexes?) is not specified. At "~1M records per entity type, per tenant" with multiple entity types, the polymorphic table can grow to a large composite size; how query-pruning preserves "efficient, indexed queries" is left implicit.
  • Workflow orchestration engine identity is not disclosed. The framework sits "on top of our internal workflow orchestration engine" but the engine itself is not named. Atlassian-internal precedent in the wiki includes Fireworks (Firecracker-µVM orchestrator on Kubernetes, AI-agent execution substrate) and Bitbucket Pipelines (CI orchestrator), but neither is the obvious match for "async reporting jobs that scan Jira data." A third internal orchestrator is implied; not publicly named in this post.
  • Refresh-prioritisation threshold is heuristic. The ≈70% utilisation threshold is given as a chosen operating point, not justified by measurement. The trade between staleness-window for low-utilisation tenants vs compute- cost-saving is not characterised.
  • Audit-log-as-rollback v1 contract has unmeasured failure-modes. "Manually reverse or adjust configuration if needed" is the documented escape hatch; the post does not characterise how often manual rollback is invoked, what proportion of bulk actions are reversed, or what the median time-to-rollback is. "We already have assisted rollback" is mentioned without architecture disclosure; "guided, in-product rollback" is future work.
  • Multi-tenant compute-isolation between spaces during remediation is not addressed. A single tenant "streamlined hundreds of thousands of fields and work types in a single day" implies very high write throughput; whether this remediation traffic is isolated from other tenants on the shared Jira workflow orchestrator + database is not disclosed.

Source

Last updated · 542 distilled / 1,571 read