Migration from bitnami, or potentially keeping it?

SonarQube Server / Community Build
1

I’ve inhereited a SonarQube Server enviornment that needs upgraded from 10.8.1 > 2025.1 > 2025.2. Currently this is diployed via Helm and uses the deprecated Bitnami Postgre deploy. This also means that my Postgre database engine isn’t a supported version either.

1.) Why was this deprecated? My immediate desire is to just deploy my own Postgre instance in K8s but I’m not sure if this is just repeating the same ‘problem’ in a different way?

2.) Is there any technical documentation on what is reccomended as far as minimum ram/cpu/storage for the SQL host? Currently the Bitnami deploy has been running without issue in this smaller enviornment.

  1. Is it possible to backup the configuration in SonarQube Server and deploy this to a new instance. I may migrate from Postgre > MSSQL and instead of copying the database over, just bringing config/settings would be ideal. Is there any reccomendations specifically for one over the other? I already have MSSQL deployed elsewhere, hence the desire.

  2. If I wanted to keep the bitnami deploy, has anyone here done that? I’d just want to change what version of Postgre is deployed, has that been done?

Thanks,

Ben

2

Hi Ben,

Welcome to the community!

To be honest, Sonar was a little late to the Helm party, and in the interim, Bitnami stepped into the breach with their own chart.

Eventually we stepped up and started maintaining our own chart. And we… prefer to do things slightly differently.

So as long as you’re using a supported version of a supported DB engine, you should be fine.

Here’s what we’ve got.

Largely, the DB is your backup. There are a few configurations that live outside it. Generally, I would characterize them as bootstrap configs.

 
HTH,
Ann

3

Hi Ann,

Thank you very much!

Appreciate the thorough response, this is a massive help.

I’m still learning plenty about SQ Server and wrapping my head around it, but while I do that just one more question.

I’m hopeful to just move to MS-SQL as mentioned, and understand that most of the configurations live in whatever database is configured. The only thing my client has mentioned needing are some configuration changes they’ve implemented to exclude specific scans as they would report on issues tehy are unable to resolve.

Doesn’t sound too complicated, and worst case scenario we recreate those from scratch. Would I be right in assuming that is something that would live in the DB, and not something easily exported / imported from one instance to another? Outside of just copying the DB to a new Postgre enviornment, that is.

Thanks,

Ben

4

Hi Ben,

As with all the best things, the answer to that is “it depends”. :joy:

It sounds like we’re talking about analysis configurations, which we advise people to “lock in” via UI (i.e. DB) configuration. But there are a whole lot of people who prefer to do this in the project by twiddling the analysis parameters.

So you’ll have to learn more about these configurations & how/where they were made.

 
HTH,
Ann