Atlassian products are all support a range of databases. Our essential policy is that the choice of database is yours to make, and we will provide support as best we can.

Naturally though, not all databases are made equal, and we are much better able to support some databases than others. It is thus in everyone's interest for you choose a good one. This page describes our preferences, based on our own experience and problem reports from customers.

This is not an unbiased impersonal review. Please do not feel offended if your favourite database is trashed here, or unduly worried about Atlassian's support. We fully realise that in many situations the choice of database is not up to the JIRA deployer. If you spot inaccuracies or misrepresentations, or are willing to share your experiences, do please let us know in the comments.

Considerations

In this review, we consider:

• Problems relating to Atlassian products
• Setup and administration difficulty
• Popularity (popular databases are better tested)

Here is a chart of what our customers are using, from the sample that submit support requests:

1. The Best

PostgreSQL (JIRA docs)

The world would be a happy place if everyone just used PostgreSQL. It does everything right - defaults to Unicode, is perfectly fast, has an adequate and (as far as we can tell) bug-free JDBC driver. It has been around for ages and is stable and popular. We use PostgreSQL in production for all our webapps and websites.

Furthermore, basic administration is absolutely straightforward. After installing PostgreSQL from scratch on Linux, here is how you create a user and database for JIRA:

jsmith@teacup:~$ sudo su - postgres
postgres@teacup:~$ createuser -P jsmith
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
postgres@teacup:~$ logout
jsmith@teacup:~$ createdb jiradb_37
CREATE DATABASE
jsmith@teacup:~$

The PostgreSQL command-line tool, psql is nicer than MySQL's in various small ways (tab completion of any command; a pager for long results; ctrl-c on a hanging query doesn't exit psql).

MySQL 5.x (JIRA docs)

MySQL 5 is another fast and problem-free database that would make an excellent choice for a webapp. Version 5 solves the Unicode problems present in 4.0. MySQL 4.1 also fixes the Unicode problems, but lacks supports modern SQL (subselects) which is nice to have on occasion. The commercial company behind MySQL provides commercial support, and does a good job of maintaining the JDBC driver.

The Worst

Sybase ASE (JIRA docs)

It appears that Sybase once hired a crack team of sales reps, and deployed them with the mission of converting the world's financial institutions to Sybase. Sybase is used by just 0.6% of our userbase, but these are almost exclusively large investment banks for whom our products are sometimes mission-critical. This is unfortunate, given Sybase's problems.

Sybase does not support multiversion concurrency control, so is prone to deadlocks. Sybase's inability to perform some basic SQL operations means the Charting Plugin will not work. Sybase is quirky, being case-sensitive, and requiring special configuration to allow NULLs.

Sybase's worst feature is its JDBC driver, jConnect. It cannot handled strings over 16k, meaning that workflows (stored as large strings in the database) will corrupt themselves beyond a certain size, then requiring SQL hackery to fix. There is no known workaround except to use the jTDS driver.

Oracle

The vast majority of database-related JIRA problem reports we receive involve Oracle. It works when set up and configured properly, but this is not trivial.

For what is probably the world's biggest database vendor, Oracle is curiously inept at producing working JDBC drivers. It is essential to use the very latest driver (10.1.0.5), since every release prior to it has had critical problems (see our docs).

Oracle requires a special SetBigStringTryClob flag to be set in the appserver configuration before it will store CLOB text over 4000 characters. In some application servers, notably Oracle's own OC4J, the SetBigStringTryClob property isn't passed through, and we've had to write a wrapper JDBC driver.

For what it's worth, Oracle is also legendarily difficult to install. To be fair, Oracle never intended it to be installed by non-DBAs, but this mindset where the database is only to be touched by the priesthood of DBAs is easily forgotten in a world of free and easy to install databases.

The Rest

SQL Server 2005 (JIRA docs)

SQL Server 2005 does not appear to give our users much trouble. However, Microsoft's own JDBC driver is notoriously buggy (see JRA-5760, JRA-6872, JRA-8443, JRA-5054), and so we recommend the jTDS driver instead.

2005 is the first version to support MVCC, reducing the possibility of database lock problems during bulk updates - a problem we have had reports of in earlier releases.

DB2 (JIRA docs)

For a database that has been around since the dawn of time, DB2 is quite unobjectionable and reasonably easy to use. Databases need to be explicitly created as UTF-8 if you need that (see Known Issues for DB2), and there are reports of CLOB problems that may affect those with large workflows or comments. DB2 does not support multiversion concurrency control so is theoretically prone to deadlocks.