License and License Keys

A license key is always required for the operator to work.

The only exception is when you run the operator with Community PostgreSQL: in this case, if the license key is unset, a cluster will be started with the default trial license - which automatically expires after 30 days.

Company level license keys

A license key allows you to create an unlimited number of PostgreSQL clusters in your installation.

The license key needs to be available in a Secret in the same namespace where the operator is deployed (ConfigMap is also available, but not recommended for a license key).

Operator configuration

For more information, please refer to the "Operator configuration" section.

Once the company level license is installed, the validity of the license key can be checked inside the cluster status.

kubectl get cluster cluster_example -o yaml
[...]
status:
  [...]
  licenseStatus:
    licenseExpiration: "2021-11-06T09:36:02Z"
    licenseStatus: Trial
    valid: true
    isImplicit: false
    isTrial: true
[...]

Kubernetes installations via YAML manifest

When the operator is installed in Kubernetes using the YAML manifest, it is deployed by default in the postgresql-operator-system namespace.

Given the namespace name, and the license key, you can create the config map with the following command:

kubectl create configmap -n [NAMESPACE_NAME_HERE] \
    postgresql-operator-controller-manager-config \
    --from-literal=EDB_LICENSE_KEY=[LICENSE_KEY_HERE]

Operator pods will need to be recreated to apply the new configuration. You can use the following command:

kubectl rollout restart deployment -n [NAMESPACE_NAME_HERE] \
    postgresql-operator-controller-manager

OpenShift and Kubernetes installations with OLM

When instead OLM is used (i.e. on OpenShift or on Kubernetes from OperatorHub), you can choose to install the operator in a single namespace or to make it available in all namespaces. The second option is the default one, and the operator will be installed in openshift-operators on OpenShift and operators on OperatorHub.

You can add a given license key to an entire cluster, by creating a secret in the desired namespace (openshift-operators, operators, or the selected one) with the following command:

kubectl create secret generic -n [NAMESPACE_NAME_HERE] \
    postgresql-operator-controller-manager-config \
    --from-literal=EDB_LICENSE_KEY=[LICENSE_KEY_HERE]

You'll need to delete the current operator pods. New pods will be automatically recreated and will use the secret:

kubectl delete pods -n [NAMESPACE_NAME_HERE] \
  -l app.kubernetes.io/name=cloud-native-postgresql

Cluster level license keys

Each Cluster resource has a licenseKey parameter in its definition. You can find the expiration date, as well as more information about the license, in the cluster status:

kubectl get cluster cluster_example -o yaml
[...]
status:
  [...]
  licenseStatus:
    licenseExpiration: "2021-11-06T09:36:02Z"
    licenseStatus: Trial
    valid: true
    isImplicit: false
    isTrial: true
[...]

A cluster license key can be updated with a new one at any moment, to extend the expiration date or move the cluster to a production license.

License key secret at cluster level

Each Cluster resource can also have a licenseKeySecret parameter, which contains the name and key of a secret. That secret contains the license key provided by EnterpriseDB.

This field will take precedence over licenseKey: it will be refreshed when you change the secret, in order to extend the expiration date, or switching from a trial license to a production license.

Cloud Native PostgreSQL is distributed under the EnterpriseDB Limited Usage License Agreement, available at enterprisedb.com/limited-use-license.

Cloud Native PostgreSQL: Copyright (C) 2019-2021 EnterpriseDB.

What happens when a license expires

After the license expiration, the operator will cease any reconciliation attempt on the cluster, effectively stopping to manage its status. This also includes any self-healing and high availability capabilities, such as automated failover and switchovers.

The pods and the data will still be available.