About SQ license validity with k8s and CloudNativePG

Hello SonarSource Support Team,
We plan to upgrade the license status from SonarQube CE to Enterprise Edition in Kubernetes using the official Helm chart.
Our PostgreSQL database is managed by the CloudNativePG (CNPG) operator in K8s as multiple replicas of a single cluster.
Current architecture:

  • SonarQube deployed via official Helm chart

  • PostgreSQL deployed via CloudNativePG operator

  • SonarQube connects to PostgreSQL using a stable Kubernetes Service DNS name

CNPG may perform failover, pod rescheduling, rolling updates, or primary switchovers internally
We would like to understand which scenarios can invalidate the SonarQube license in this environment.
Specifically:

  1. Will the icense remain valid if:
  • PostgreSQL pods are recreated

  • CNPG performs automatic failover

  • the primary PostgreSQL instance changes

  • K8s nodes change

  • PostgreSQL pod IP addresses change

  1. Is the license tied only to the JDBC connection string / database identity, or can internal PostgreSQL topology changes also affect it?

  2. If the k8s Service DNS name and JDBC URL remain unchanged, can we safely:

  • upgrade CNPG

  • restart PostgreSQL pods

  • perform rolling updates

  • migrate PostgreSQL storage volumes

  1. Are there any known limitations or best practices for running SonarQube Enterprise Edition with CloudNativePG in K8s?

  2. Would restoring the same PostgreSQL data into a newly created CNPG cluster with a different K8s Service name invalidate the license?

We want to ensure that routine K8s and CNPG operations will not unexpectedly invalidate the license in production.
Thank you in advance for clarification.

Hi @grim and welcome to the community! We list some license-invalidating scenarios in our docs. Those actions change your instance’s server ID, which is made up of a combination of your JDBC URL and a random value stored in the DB schema.

Out of the cases you mentioned, only this one would affect the server ID:

  1. Would restoring the same PostgreSQL data into a newly created CNPG cluster with a different K8s Service name invalidate the license?

Different k8s service name > different JDBC string seen by SonarQube > different server ID > license problems.

How to deal with it? Well, because you will be a new customer (acquiring a license for the 1st time), you will likely get one of our new online-activated licenses. In this case, you should first unset the license, then perform the license-invalidating action, and then set the license again. If you were to have one of the “old” licenses, then you would first perform the license-invalidating action, then contact your sales rep to obtain a new license based on your new server ID.

It looks pretty convenient, thanks for the clarification!