> As to being slow. I only had this issue once with a small dev shop self hosting in a closet. At a large enterprise with over 10,000 engineers using Jira, not including the non-engineers using it, it was always lightning fast for the self hosted version.

Contra-point: I use Jira for <1,000 users, it's hosted on a single instance (128G mem 64vCPUs), with a seperate database server and it takes 30s to load my backlog. (And I'm not exaggerating, truly, each page load takes 1-30 seconds, direct ticket views to to kanban board).

I looked at running multiple servers, but it seems like our license doesn't allow that. Which is another issue with Jira, it's licensed on the server level.

Check your database integrity, you probably have some bad indexes in there. Which brings me to the major point about why atlassian products suck.. you have no support if you are not within a current version. If you were like a shop I was once at, where you can’t upgrade every 3 weeks then develop a DB inconsistency that prevents future upgrades but don’t have the manpower to address it so then you end up 2 years behind and the inconsistency is now 5000 objects in the past that requires deep massaging. Atlassian support is still MIA, and I’m not talking about where the Heat play at. You find an obscure thread that mentions data loss so you balk at the idea and go another 6 months into upgrade debt when you hit a show stopper. Jira won’t start because of that inconsistency that is now 7200 objects in arrears. You go back to that forum post and attempt the steps. You have to manually repair the inconsistencies. 3 hours later jira starts but now calls are rolling in about missing links. You spend the next week addressing the known issues then let it fall to the back burner.

Nope. Fuck jira. Let’s not talk about the hell that is Confluence. If you must use it then don’t self host it, let them deal with managing their garbage product.

AFAIK there is no support if you are ahead either, newer postgres versions are officially not supported..

FWIW, in my experience a big factor of this is poor configuration, especially around permissions/ACLs getting out of control. That and deranged addons.

Something is seriously hosed with your configuration if it takes up to 30 seconds to load an issue, especially on your specs which can probably support 5000+ users. Multiple servers won't fix your problem...probably should have support eyeball your configuration.

Those all seem like valid points. Especially about $$. I am wondering if JIRA can't handle the equivalent of a monorepo, with one giant project. Was that the situation?

Also, I don't intend to defend JIRA from a cost or infrastructure perspective, just as a tool.

If you are shopping around for a ticketing system might I offer this generic minimum spec sheet: * Items should all have a unique identifier that can be used in the developers workflow * Any item should be able to be a sub-item of another item. * It should be fast enough to not waste development time (time spent in tool).

If your ticketing/work/bug system doesn't allow those (and I believe GitHub issues might not), then you are doing your team a disservice.

The reason I usually turn to JIRA, is that somehow it manages to be everything to everyone. I was managing a small team at a startup, and the developers only looked at the detail view and the kanban view. Almost any "update" to JIRA happened via including a ticket number in a git commit, branch, etc. However, the QA team, had some crazy pipeline that happened after the engineers deemed it done, and those two workflows didn't affect each other, and worked seamlessly. Product, had an entirely different workflow before engineers even saw a ticket. Then after grooming, and sprint planning, the team set a goal of how which tickets would be done and in what order. Engineers would go back to their desk, and just use JIRA for viewing the details and commenting on things usually for product/design. Also, if I wanted to cut a release of something (at the time we did weekly deploys, even though master was always considered deployable at any time), and I could click a button in JIRA to make a release that automatically knew what had changed from git. All of those tickets got updated to `released` automatically from the deploy.

You may not need JIRA. But a lot of engineers have put a lot of hours into a marvel of software that does way too many things. Its an amazing tool. But you may not need a multi-tool such as JIRA. You might just need a hammer.

(Lastly out of curiosity, have you contacted their support about optimizing your performance? I am curious before I choose self-hosting in the future.)

Switch to Phabricator which is open source and you won't look back. JIRA truly is a crappy product designed to sell to managers who they wine and dine in order to sell, not based on how good or fast it is.

Wow. Phabricator has really evolved since the last time I looked at it. I will consider it for my next team.

As per wine and dine: 1. I have never interacted with a human being from Atlassian ever. 2. I don't think this is as effective for selling software anymore. This has been replaced by user conferences. Most people who can buy things that involve being wined and dined have can expense a nice meal when traveling for work. Many times a sales person may wine and dine you so they can wine and dine themselves.

Except there's no sales people there to wine & dine you...it's actually the complete opposite.

We have cloud JIRA (Attlasian hosted) and it is awfully slow. And it is always changing the interface so I have to click around that laggy interface every time to find what I need.

JIRA Cloud generally feels slow. I was trying to defend the software tool itself.

In the same time most often users will as to add new features to “already clunky” system. It will always make me wonder - where is logic? Yes it ca be super custom designed but in 95% it’s over engendered.