Helm upgrade 2025.4.2 --> 2026.2.0 (Enterprise)

SonarQube Server / Community Build
,
1

Hi everyone,

We are preparing to upgrade our SonarQube Enterprise Edition instance running on GKE (managed via ArgoCD). Since the 2026.x Helm charts completely remove the embedded PostgreSQL dependency, and our current embedded DB is PostgreSQL 12, we need to decouple the database and upgrade the major version simultaneously.

I’d love to get the community’s and maintainers’ eyes on our migration strategy to see if we missed any Enterprise or Postgres-specific “gotchas.”

Current State:

  • Edition: Enterprise Edition

  • Chart: 2025.4.2

  • Database: Embedded PostgreSQL 12 (Bitnami subchart, postgresql.enabled: true)

Target State:

  • Edition: Enterprise Edition

  • Chart: 2026.1.0 (or 2026.2.0)

  • Database: Standalone PostgreSQL 17.4 (postgresql.enabled: false)

Our Migration Strategy:

We’ve successfully tested the data pipe in a dry run, but here is our exact runbook for the maintenance window. We are using ArgoCD, so our strategy relies on temporarily disabling sync pruning to create a zero-risk rollback path.

  1. Pre-Req: Deploy a new, empty Standalone PostgreSQL 17.4 instance in the same namespace.

  2. Freeze: Scale the current sonarqube-sonarqube StatefulSet to 0.

  3. The Data Pipe: Stream the data directly from the old PG 12 pod to the new PG 17 pod via the internal GKE network: pg_dump -U sonarUser -d sonarDB --clean | psql -U sonarUser -d sonarDB

  4. Optimize: Run ANALYZE VERBOSE; on the new PG 17 database.

  5. GitOps Rollout: * Update our ArgoCD values to chart: 2026.1.0.

    • Set postgresql.enabled: false.

    • Map the new standalone DB using the jdbcOverwrite block.

    • Crucial Step: We disable prune: true and selfHeal: true in ArgoCD. This allows us to deploy the new 2026 app pod while intentionally leaving the old PG 12 database running untouched in the background.

  6. Trigger Upgrade: Navigate to https://<our-url>/setup to trigger the database migration and Elasticsearch re-index.

  7. The Safety Net: If the 2026 instance fails to start or plugins crash, we simply revert our Git commit to the 2025.4 values. ArgoCD will redeploy the old app pod, it will reconnect to the untouched PG 12 database, and we experience zero data loss.

My Questions for the Community/SonarSource:

  1. PG 12 to PG 17: Are there any known issues, missing extensions, or collation mismatches we should watch out for when piping SonarQube Enterprise data directly from Postgres 12 to Postgres 17?

  2. Elasticsearch Re-index: For a ~55GB database on the Enterprise Edition, roughly how long should we expect the background re-indexing to take after hitting /setup on the new chart?

  3. Helm Chart Gotchas: Aside from dropping the postgresql block and keeping initSysctl: false (due to GKE Autopilot limits), are there any other configs might cause the 2026.x startup to fail?

2

Hi,

I’m not qualified to comment on the details of your Helm strategy (I would have said “make a backup of the old DB and restore it in Postgres 17.4” :sweat_smile:), but I do need to make two points.

First, you can’t get there from here. You cannot successfully migrate from 2025.4.* directly to 2026.2. You must first go through 2026.1, the next LTA. So unfortunately, you’re looking at 2 migrations, although I believe you shouldn’t have to reindex twice, assuming your index is persisted.

Second, it looks like you plan to move the DB and then immediately start the (first!) upgrade. I would take a pause in between there to point your 2025.4.2 instance at the migrated DB and make sure everything comes up like it should.

Then shut down 2025.4.2 and spin up 2026.2.0 and start the DB migration.

Your safety net still works in this scenario, there’s just the extra step of pointing the old instance back at the old DB.

On the timing, it’s going to be entirely dependent on the amount of data and (I think) the resources available to the process. I know you’ve provided the size of the dataset, but unfortunately, I don’t have a formula to plug that into. But with 55G I wouldn’t plan to get this done with the developers are at lunch.

 
Ann

4

Hi,

I asked my colleagues for duration estimate. I was told you should run it on a test instance if you really want to know :sweat_smile: but at a guess <1h. (I still wouldn’t count on getting it done over lunch, though.)

 
HTH,
Ann