Last update: 10/26/2020
We regularly help our customers plan and implement on-premises and cloud High Availability (HA) solutions in close networks (air-gapped) or cloud / hybrid, and for a variety of tools – e.g. Atlassian Bitbucket, GitLab, Jira, Artifactory, SonarQube, GitHub and more.
We are often asked “which HA solution is better in the scope of code management and software configuration management – GitLab or Bitbucket?”
In fact, the subject of HA itself is a complex subject, for several reasons:
- There could be many ways of implementing HA
- The solution depends on the needs of each customer (is it for the purpose of load balancing only? Or to avoid denial of service?
- It depends on how many single points of failure the customer is willing to absorb (if at all)
- It also depends on the budget (the more “high” availability it requires, the more budget needed)
And sometimes customers say they want HA but in practice they mean Disaster Recovery (DR) at all …
To answer this in a simple way, I will prove the following claim:
Given Bitbucket’s HA solution (“Data Center”) as explained here, and given GitLab’s HA solution as explained here, GitLab, using the Omnibus package, can provide HA (for redundancy and high availability) for all components to achieve horizontal HA for the entire solution, while Bitbucket cannot provide redundancy for all components.
- In Bitbucket, the code itself, as git repos, sits on a shared NFS (as shown in the diagram in the link above). If there is a failure in NFS or loss of information – everything will be lost.
In GitLab, starting with version 13.0 (released in May 2020) you can build a Gitaly Cluster, so there are several copies of the git repo and there is not a single point of failure (detailed explanation in the article we wrote then – here).Besides, running git on NFS usually will have performance issues (a known problem).
- As each session’s information is stored on Bitbucket’s application server, sessions may be lost when switching over to another server (failover). This means the sessions will be lost and all users will have to login again, while some of the information will be completely lost (this is explicitly mentioned in the Atlassian article above).
GitLab uses Redis in HA configuration so such a situation will not happen.
- Atlassian’s standard solution provides a shared DB – which is a single point of failure.
GitLab’s Omnibus package supports database HA so it can be implemented more easily.
- GitLab HA can multiply each component for scaling up (as explained in the diagram above)
- Both products provide an active / active HA solution (although with significant differences as stated above)
- GitLab is often used as a CI/CD tool (in addition to being an SCM tool), and the HA solution actually provides full coverage for CI/CD aspects as well (such as high availability of running pipelines and deployment).
Bitbucket on-prem, by contrast, does not include a CI/CD solution – so there is another significant advantage to GitLab here: in setting up an HA solution it is possible to “kill 2 birds with one stone”.
- There is a tendency to confuse HA solutions with DR solutions. Bitbucket’s Smart Mirroring explained here is not an HA solution. It gives a partial DR solution of repos replication but without the metadata that comes with them.
In GitLab, a more complete DR solution can be implemented with the help of “GitLab Geo“, which also gives DR information around the repo such as user accounts, issues, merge requests, groups, project data and more.
- The above article should not be construed as sweeping advice for all types of customers and users.
There may be differences from customer to customer (contact us to receive our warranty-backed individual recommendations).
As Atlassian’s latest plan is to deprecate Bitbucket Server versions (including Jira Server) and focus on cloud solutions, and since the Bitbucket Data Center version ultimately relies on the Server version (as written here: “Bitbucket Data Center and Bitbucket Server are in fact the same build of Bitbucket”), the future of the Data Center version is uncertain, and we don’t know what the company will do with it in the future.
P.S Customers have also asked which solution would be cheaper in terms of licensing costs and prices (and TCO). I will not answer this here because vendors change prices very often. We will be happy to answer this for you in detail when you contact us.