Running JIRA with an unsupported database

[Karl-Koenig Koenigsson]

I'd like to try running JIRA with a database that is not among those supported by Atlassian - how can I configure JIRA to use the JDBC driver from that RDMS instead of the ones that come pre-installed?

[Vickey Palzor Lepcha]

Using an unsupported database would lead to confusion I would say. Issues you would face and have no idea why it happens.

[Karl-König_Königsson]

My reason for this is that my company is Mimer, i.e., we build and sell a SQL database server software. In keeping up with the old "eat your own dog food" adage it is rather important for us to use our own software.

But I see your point, of course, and I am fully aware of the ramifications. Still, I would like to try to get Jira to work with our own software so as to be able to properly evaluate if it will be worth the extra work to use ours instead of the officially supported ones.

My thinking is that it either works or it doesn't. There is usually no in-between. And if I have my backups in order I could always fall back on one of the other, were we to run into problems later.

[Vickey Palzor Lepcha]

ok - so the whole intent is different here. You'd want to explore possibilities rather than run your enterprise on it for the moment.

[Karl-König_Königsson]

Well… :-)

Both, actually. If it works, all the better!

[somethingblue]

Hi Karl,

It would depend on the database you're using.  You would need to refer to the documentation for that db to determine how to configure the jdbc path and then you can use the JIRA application configuration tool to make the changes to your instance.

Cheers,

Branden

[Karl-König Königsson]

The database in question is Mimer SQL (http://mimer.com/) and it comes with a JDBC driver.

I have used the configuration tool before, but is that not something I typically use to tweak an existing installation? What I am trying to say is that I want to install JIRA with Mimer SQL as database backend but from from what I recall from the installation procedure one has to pick one of the kosher ones, right?

That means that I would install it with HSQL, for instance, but to then go from HSQL to an empty Mimer SQL (or any other database for that) can not be trivial.

[Andy Heinzer]

You don't have to use the Jira config tool to setup Jira, but it tends to be easier if you do.

In theory you could edit the dbconfig.xml file in the $JIRAHOME directory in order to setup Jira to use this database.  The problem here is that we don't have any idea of exactly what the parameters should be for a database of this type. 

If you look at all the supported database examples listed on: Connecting Jira application to a database you will notice that each of these has a sample dbconfig.xml that is specific to that database type.    If you are really determined to use this database, I would study these to see if you can work backwards to figure out all the parameters needed to connect to this database.

However I don't think this is going to work.   Jira is coded with specific methods and instructions for each of the supported database types: oracle, MS SQL, postgres, and MySQL.  Each of these have differences in regards to data types, sequences, transactions, table creation, field types, field lengths, foreign key constraints, and so on.

There are some users out there using unsupported databases like MariaDB or Percona.  These are unsupported too, but they tend to have an edge over this Mimer SQL because they are derivatives of MySQL.  Even these can still have problems what would leave these instances broken, but there are users still able to make Jira work with this database type.   In the case of Mimer, I don't even know how to begin to make this work.   It feels like this is not a derivative of any of the existing supported database versions, so this might be entirely new ground for Jira to try to use this kind of database.

[Karl-König_Königsson]

No, Mimer SQL is not a derivative - it has been around for 30+ years.

From what I gathered is Jira heading the Hibernate way and that means, at least to me, that the time of database specific queries and solutions should be gone. On the other hand have I also gathered that Jira is not fully there, hence there might be some hiccups.

So, Andrew, given that you are Atlassian I take careful note of your words. As I stated in another reply, this is just a matter of pride. I will not spend an insane amount of time trying to get this to work. Still, is is worth a try, you'll agree.

[Ajinkya Paradkar]

@Andy Heinzer  Just noticed this thread while searching for a solution to migrate our Oracle 11g to Postgres 11.2 Database and along with that Jira Version from 6.4.13 to 8.20.

However we are having some difficulties when moving to version 7 and 8 with the behavior scripts and Jira Licensing as we run on Jira Core License.

Due to the time crunch of moving to Postgres , we are planning to run Jira 6.4.13 on Postgres 11.2 database. I understand that it is unsupported but if the testing goes well on UAT environment , is it safe to move ahead on production ?

Looking forward to your response.

Thanks,

Ajinkya

[Andy Heinzer]

In theory, it is possible.  But from my own experience supporting customers trying to make similar upgrade jumps, there are many pitfalls. For example, there is a required upgrade version if you have Jira Service Management (formerly Jira Service Desk) data in your 6.4.x version.  You have to upgrade Jira to a version between 7.0.0 and 7.1.x so that you can then install the corresponding Jira Service Desk module (3.0.0 - 3.1.x) in order to upgrade those tables.  It can only be done in those versions.  If you skip that version upgrade there is no supported way to upgrade that data.

But even if you don't have (and never installed) JSD/JSM, making such an upgrade jump requires many upgrade tasks to be completed.  When these upgradetasks are written, they are not tested against unsupported SQL databases.  So Atlassian would not guarantee that your data integrity would be maintained because you were running on an unsupported database.  I understand that there might be a time crunch and you would like to complete this as quick as possible.  But those supported versions of database versions were the only ones we tested again at the time of these version releases.

In short, I don't recommend trying to use unsupported databases.