Atlassian should publish clear data sizing limits for all products

[James Campbell]

Hello Atlassian community.  This is my first post.

I am looking at solutions for task data capture for a 100 person team across 30 task categories.  The intention is to capture simple task data for a period of one year and develop reports/data insights.  If the solution works, we might scale it to 1000 users in the future.

As a solutions developer it is my responsibility to understand the limits of a product before I recommend it to my organization.  If it suddenly stops working due to some hidden limit, that will reflect back on my due diligence, disrupt operations, inconvenience the user base.

I have done persistent searches for Jira Server and Jira Work Management and have not found what I need.  Happy to consider links if I have missed something or tried the wrong keywords.

I recommend that the following data should be published for all Atlassian products (using Jira on prem server as an example here):

• max number of concurrent users per Jira instance
• max number of projects per Jira instance
• max data size for Jira instance
• max number of concurrent users per Jira project
• max data size for a Jira project before it stops accepting new data
• ** max number of issues per Jira project before it stops accepting new issues - this is very important for appropriate data sizing for large teams.
• max number of issue types in an issue type scheme
• max number of tag types in a tag list
• ... and so on, for every product that Atlassian produces including Jira Datacenter, Jira Cloud, Jira Work Management, Trello.  

Personally I don't understand how anyone could make supportable product decisions without this information.  I recommend that Atlassian address this lack of information as soon as possible.  I also found some threads where it seemed that even Atlassian support staff did not know these limits.

Thank you all.  Please provide info if you have it for Jira on prem server.

Greetings from Toronto Canada.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

There's a reason they have not published this data - it's not actually useful or answerable.

Taking your examples from Jira:

1. max number of concurrent users per Jira instance
   1. Depends on your hardware, network and where you want to draw the line at "how slow it is to make it unusable
2. max number of projects per Jira instance
   1. What's the largest number your database can store?
3. max data size for Jira instance
   1. The size of your storage of the database and attachments
4. max number of concurrent users per Jira project
   1. See 1 (and the project is irrelevant)
5. max data size for a Jira project before it stops accepting new data
   1. see 3
6. ** max number of issues per Jira project before it stops accepting new issues - this is very important for appropriate data sizing for large teams.
   1. see 4
7. max number of issue types in an issue type scheme
   1. see 2
8. max number of tag types in a tag list
   1. see 2

And so on.  There is no way these questions can be answered, you're asking for the wrong thing.

[James Campbell]

Hi Nic, thanks very much for your perspective.  Saw your quick stats and 78624 is LOT of posts :-)

I think that your comments are more about performance while my original intent was to clarify hard limits that may or not have been imposed by Atlassian.  Have a second read of my post with this in mind if you have a moment.

The intention is to avoid any hidden hard limits that lead to situations like "No further issues can be added to this Project. Contact your JIRA Administrator".  If the number of issues is truly unlimited, that's great - but it should be stated in the reference documentation.

Same goes for max number of issues types in an issue type scheme.  Same goes for maximum concurrent users.  If there are no hidden limits and it's all about server spec that is great - but it should be communicated by Atlassian so we can recommend products with confidence.  

regards

James

[James Campbell]

One more thought Nic.  May I ask how you know it to be true that the number of Issues in a Jira Project is limited only by server spec/realistic performance?  Same for concurrent users in a Jira Project?  Etc...  Maybe you work for Atlassian?

[Nic Brough -Adaptavist-]

Have a think through what you are asking about here - why would anyone code a hard limit when they don't need to?  I mean, yes, you should document that if you do it, but why bother doing it?  Of what possible use is it in an issue tracker / documentation system / source-code repository / test coverage tool / etc?

How do I know?  I've worked with Atlassian systems for 19 years, and read the code.

No, I've never worked for Atlassian directly, but I have been working for one of their partners for 9 years and I've worked with them a number of times when they've asked.

[Nic Brough -Adaptavist-]

Sorry, I forgot to add the short answer.

For all of the questions, except the one about active users imposing so much load that it starts to slow down, the answer is "more than you will find your people complain that the system is too unwieldy to use"

[James Campbell]

It is quite common for software developers to test their products and impose limits.  I will always look for these limits because I don't like avoidable surprises when my solution goes to prod.  It reflects badly on me, interrupts the users and can cause business disruption.

Key Atlassian competitors are publicly advertising limits, but with Jira I have to go on a forum and get lucky to find a code-level SME.  This is unusual given Atlassian's broad consumer base.  This is key product information and it only takes a small effort to communicate effectively.

Search:

"monday.com data size limits"
"asana data size limits"
"Microsoft Planner data size limits"

Plenty of published info for all of these.  No avoidable surprises in prod.  I'm not saying any of these are better or worse than Jira, just that they have published their product limits.  Why can't Atlassian do the same, even if to confirm that there are no established limits, push the product till it grinds to a halt, etc..

[Nic Brough -Adaptavist-]

Those searches do not give you the answers to the questions you have posed here, because all of those systems are "limited" in the same way Atlassian ones are - the answers vary depending on what you're running them on.

I think we need to go back to looking at why you're asking the questions in the way that you are.  Do you actually know what the real question is? 

You've said "I don't want surprises when butting up against limits" - that's not a problem, the answer is, as I said already, "the limits are more than you will find your people complain that the system is too unwieldy to use" (which goes for the other systems you've mentioned as well, in most cases)

[Andrew Laden]

Look at Guardrails

https://community.atlassian.com/t5/Data-Center-articles/Announcing-Jira-and-Confluence-DC-Guardrails/ba-p/2066034