OpenSearch requires dedicated infrastructure within a standard Jira Data Center setup. Knowing how to deploy OpenSearch for your indexing requirements will help you plan and streamline operations tailored to your business needs.

On this page:

• Hardware recommendations
• OpenSearch and Jira
• Considerations for OpenSearch deployments
• Testing approach
• Performance testing: results and analysis
• Ready to make the switch?

Hardware recommendations

Our recommendations are based on extensive performance testing. They’ll help you plan a suitable environment or assess your current instance based on content volume and traffic. Note that increasing application nodes doesn’t always improve performance and might have the opposite effect.

To get the most from these insights:

• Determine your instance size profile.

• Review the recommendations below.

• Monitor your instance for bottlenecks.

OpenSearch and Jira

The table below outlines a typical setup for Jira with OpenSearch, including pricing, filesystem, and database details. Pricing doesn’t include shared home or application load balancer costs. By using OpenSearch instead of Lucene, you’ll be able to reduce the number of required Jira nodes and use cheaper hardware while maintaining similar performance. 

Explanation:

¹Prices as of 13 November 2025 based on US East (Ohio). See Amazon's OpenSearch pricing guide and Amazon EC2 On-Demand Pricing.

Considerations for OpenSearch deployments

• Performance depends on factors like third-party apps, data, traffic, concurrency, customizations, and instance type. Your results might vary.

• We recommend a minimum of three data nodes for OpenSearch. If you have three dedicated master nodes in Amazon OpenSearch Service, keep at least two data nodes for replication. More on dedicated master nodes

• Review the test details below to help you choose between best-performing and most cost-effective options.

For more details, refer to the AWS documentation on Sizing Amazon OpenSearch Service domains.

Testing approach

All tests were run in AWS environments using standard AWS components, making it easy to replicate our recommended configurations. We used PostgreSQL with default Amazon Relational Database Service (AWS RDS) settings and dedicated AWS infrastructure on the same subnet to minimize network latency. Read more about AWS components

Benchmarking notes:

• The dataset included all Jira issue types.

• No apps were installed on test instances; results reflect core Jira only. When designing your infrastructure, account for the performance impact of apps you want to install.

Dataset

The following table shows the dataset we used on our performance tests for Jira.

The following table shows the index sizes from our test environment. If you know the size of your current Lucene index, you can estimate your OpenSearch index size by multiplying it by approximately 4. For example, a 14 GB Lucene index per node resulted in a 61.7 GB OpenSearch index (cluster-wide, excluding replicas). You can use this ratio as a starting point, then refer to the Amazon documentation to plan your OpenSearch cluster: Sizing Amazon OpenSearch Service domains.

Performance testing: results and analysis

End-user performance

Our benchmarking results show that OpenSearch delivers a 38% improvement in overall performance compared to a Lucene-based instance, based on the 95th percentile (P95) of response times. This means that 95% of all measured response times are faster than this value, so it’s a good indicator of how the system performs under heavy load. The tests included a mix of operations, with 75% reads and 25% writes.

Full reindexing performance

We manually triggered a full reindex and found that OpenSearch completed the process faster than Lucene. However, the real benefit of OpenSearch is that you don’t need to reindex as often. Because updates are quickly shared across all nodes (by default, every second), OpenSearch keeps your data consistent and reduces the need for full site reindexes.

Explanation:

¹Run on a single node of Jira on c5.9xlarge.

Resource usage: Lucene vs OpenSearch

Our internal benchmarks show that OpenSearch reduces memory consumption and garbage collection overhead and also significantly lowers thread contention and eliminates input and output (I/O) anomalies seen with Lucene.

Explanations:

¹Socket input/output anomalies are unexpected delays or interruptions when Jira nodes communicate over the network. Even a single slow read or write can cause noticeable lags for users, especially during high-traffic periods. In our tests, Lucene experienced a significant delay (over four seconds to read just five bytes), which can lead to slow page loads, timeouts, or degraded user experience.

²Thread contention occurs when multiple processes compete for the same resources, causing some operations to be blocked or delayed. High thread contention means Jira spends more time waiting and less time serving users, which can result in sluggish boards, slow issue views, and longer response times.

OpenSearch significantly reduces both socket input/output anomalies and thread contention. In our benchmarks, OpenSearch showed no anomalies and reduced blocked thread duration from 70 minutes (Lucene) to just 2 seconds. This means your Jira instance will be more stable, responsive, and able to handle heavy workloads without performance bottlenecks.

Ready to make the switch?

OpenSearch is designed to help your Jira instance grow, perform, and stay reliable — no matter how large your team or your data becomes. If you’re ready to take advantage of faster search, easier scaling, and a more resilient platform, consider enabling OpenSearch for your Jira Data Center instance.

Configure OpenSearch for Jira