SGShardedCluster

This field can only be set on creation.

All those defaults can be overwritten by setting the correspoinding fields.

Available profiles are:

• production:

  Prevents two Pods from running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to false by default). Sets both limits and requests using SGInstanceProfile for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to false by default). Sets requests using the referenced SGInstanceProfile for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to false by default).

• testing:

  Allows two Pods to running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to true by default). Sets both limits and requests using SGInstanceProfile for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to false by default). Sets requests using the referenced SGInstanceProfile for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to false by default).

• development:

  Allows two Pods from running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to true by default). Unset both limits and requests for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to true by default). Unsets requests for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to true by default).

Changing this field may require a restart.

Changing this section is allowed to fix issues or to change the replication source.

Removing this section convert the sharded cluster in a normal sharded cluster where the standby leader of each SGCluster is converted into a primary instance.

The main replication group is implicit and contains the total number of instances less the sum of all instances in other replication groups.

The total number of instances is always specified by .spec.instances.

The workers are a group of StackGres clusters where the partitioned data chunks are stored.

When referring to the cluster in the descriptions below it applies to any worker’s StackGres cluster.

Available technologies are:

• citus
• ddp
• shardingsphere

Citus

Citus is a PostgreSQL extension that transforms Postgres into a distributed database—so you can achieve high performance at any scale.

See also https://github.com/citusdata/citus

DDP

DDP (Distributed Data Partitioning) allows you to distribute data across different physical nodes to improve the query performance of high data volumes, taking advantage of distinct nodes’ resources. Using the entry point named coordinator in charge of sending/distributing the queries to different nodes named workers.

ShardingSphere

Apache ShardingSphere is an ecosystem to transform any database into a distributed database system, and enhance it with sharding, elastic scaling, encryption features & more.

StackGres implementation of ShardingSphere as a sharding technology uses the ShardingSphere Proxy as an entry point to distribute SQL traffic among the workers.

This implementation requires the ShardingSphere Operator to be installed and will create a ComputeNode

When referring to the cluster in the descriptions below it applies to any worker’s StackGres cluster.

If sharding type is shardingsphere then, instead of an SGCluster a ComputeNode will be created.

See also https://shardingsphere.apache.org/oncloud/current/en/user-manual/cn-sn-operator/#computenode

If sharding type is shardingsphere then this section will apply to the ComputeNode.

Vertical Pod Autoscaling will use cpu and memory usage as the metric to control the upscale or downscale of the Pod requests and limits resources. Vertical Pod Autoscaling requires the Vertical Pod Autoscaler operator to be installed in the Kubernetes cluster.

When this name is specified it will be used as the coordinator SGCluster name.

This field can only be set on creation.

If sharding type is shardingsphere then this section will be applied to the first cluster worker. In this case the database postgres will also provide a foreign server called shardingsphere and the superuser user mappings that will allow running DistQL queries using command like the following:

SELECT * FROM dblink('shardingsphere', 'SHOW STORAGE UNITS')
  AS _(name text, type text, host text, port int, db text,
    connection_timeout_milliseconds int, idle_timeout_milliseconds int,
    max_lifetime_milliseconds int, max_pool_size int, min_pool_size int,
    read_only boolean, other_attributes text);

See https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/distsql

If sharding type is shardingsphere then this section is applied to the ComputeNode.

The SGCluster name will be created using the name template and the index (starting at 0) as a suffix. For instance with a clusterNameTemplate set to myworker the first SGCluster name will be myworker0.

By default the query router cluster name template is <cluster name>-router.

This field can only be set on creation.

Query routers are special workers that do not store sharded table data. Like the coordinator, query routers are StackGres clusters responsible for coordinating access to the workers but do not coordinate data storage. The instances created as query routers allow horizontal scaling of the entrypoints for read/write operations without overloading the workers that store the sharded table data.

Query router StackGres clusters inherit the same characteristics as the coordinator in their spec, with the exception of the instances which is fixed to one and the managedSql that requires an override to be set. This is because a query router, like the coordinator, is not meant to store data and is architecturally more similar to a coordinator than to a worker. Their values can still be overridden via .spec.workers.overrides. See also field queryRouterIndexOffset.

This parameter can only be set if .spec.type is citus.

The main replication group is implicit and contains the total number of instances less the sum of all instances in other replication groups.

The total number of instances is always specified by .spec.instances.

If sharding type is shardingsphere then this section is ignored.

A SGInstanceProfile defines CPU and memory limits. Must exist before creating a cluster.

When no profile is set, a default (1 core, 2 GiB RAM) one is used.

Changing this field may require a restart.

If sharding type is shardingsphere then this section is ignored.

The name used in this section will be prefixed with the string custom- so that when referencing them in the .spec.containers section of SGInstanceProfile the name used has to be prepended with the same prefix.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

The name used in this section will be prefixed with the string custom- so that when referencing them in the .spec.containers section of SGInstanceProfile the name used has to be prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

The name used in this section will be prefixed with the string custom- so that when referencing them in the customInitContainers or customContainers sections the name used has to be prepended with the same prefix.

Only the following volume types are allowed: configMap, downwardAPI, emptyDir, gitRepo, glusterfs, hostPath, nfs, projected and secret

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#volume-v1-core

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

Changing this field may require a restart.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

It includes any additional parameters necessary to perform the update for the indicated strategy.

If sharding type is shardingsphere then this field is ignored.

NOTE: This is an alpha feature.

When multiple PostgreSQL clusters share the same local storage device on a Kubernetes node, a single cluster running a heavy workload (for example large COPY, aggressive VACUUM, or an unoptimized query) can saturate the device’s I/O bandwidth and degrade performance for every other cluster on that node. StackGres provides this mechanism to prevent this class of noisy-neighbor problem. The mechanism operates at the cgroup + block-device layer, not at the PVC abstraction. Since each pod has its own cgroup, limits are enforced independently across pods even when they share the same physical device — this is the core of the noisy-neighbor protection. However, if multiple volumes within the same pod share the same backing device, their limits target a single entry in that pod’s cgroup and cannot be enforced independently of each other.

This feature works on top of existing CSI drivers such as TopoLVM or OpenEBS LocalPV. The primary target is on-premises deployments where multiple StackGres clusters share local NVMe storage on the same node.

IMPORTANT: Setting any of the value above will require to create an init container named setup-io-limits in each SGCluster’s Pods running as root with only the CHOWN cabability set. Also both the setup-io-limits init container and the cluster-controller container will require to mount the host path /sys/fs/cgroup in order to be able to set owner of and write to the io.max file that will allows to set the io limits. For this reason this feature must be enabled globally by the operator administrator by adding the io-limits feature gate under .spec.featureGates of the SGConfig. Setting any of the value above without the io-limits feature gate enabled will be rejected.

If sharding type is shardingsphere then this field is ignored.

See https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/

Changing this field may require a restart.

Changing this field may require a restart.

When false (the default) and disableResourcesRequestsSplitFromTotal is not set or set to false and the sum of the CPU or memory of all the containers except patroni is equal to or higher than the total specified in SGInstanceProfile.spec.requests.cpu or SGInstanceProfile.spec.requests.memory then the patroni container resources will be set to 0.

This field depends on the DynamicResourceAllocation feature gate.

This field is immutable. It can only be set for containers.

This field depends on the DynamicResourceAllocation feature gate.

This field is immutable. It can only be set for containers.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#nodeaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podantiaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#toleration-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#topologyspreadconstraint-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#nodeaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podantiaffinity-v1-core

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#toleration-v1-core

• InPlace: update will be performed on the existing instances.

• ReducedImpact: before an update is performed on the existing instances a new instance if created to reduce the impact on read-only replicas.
  

Alternatively to this configuration you may specify the following annotations:

• stackgres.io/rollout=always: Same behavior as Always.
• stackgres.io/rollout=schedule: Same behavior as Schedule.
• stackgres.io/rollout=never: Same behavior as Never (even if type has a different value).

Unless Never (or the annotation stackgres.io/rollout=never) is specified an SGDbOps of type restart, securityUpgrade or minorVersionUpgrade targeting the SGCluster will trigger an update of the Pods.

The update of the Pods will be performed only if Pods are pending any change. Changes in the configuration may not require restarting the Pod and, in such cases, only the Postgres instance will be restarted.

Possible values are:

• vertical: only vertical Pod autoscaling will be enabled (default)
• none: all autoscaling will be disabled
  

If sharding type is shardingsphere then this section is ignored.

If not set, a default configuration will be used. Disabling connection pooling altogether is possible if the disableConnectionPooling property of the pods object is set to true.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

This section is required when sharding type is shardingsphere otherwise is ignored.

The following configuration fields will be ignored:

• synchronous_mode
• synchronous_mode_strict
• postgresql
• standby_cluster

If sharding type is shardingsphere then this section is ignored.

The following configuration fields will be ignored:

• name
• namespace
• log
• bootstrap
• citus
• postgresql # with the exception of postgresql.callbacks, postgresql.pre_promote, postgresql.before_stop and postgresql.pg_ctl_timeout
• restapi
• ctl
• watchdog
• tags

If sharding type is shardingsphere then this section is ignored.

This field can only be set on creation.

Changing this field may require a restart.

Check pgbouncer configuration for more information about supported parameters.

Check pgbouncer configuration for more information about supported parameters

Check pgbouncer configuration for more information about supported parameters.

Changing this field may require a restart.

The queries defined here will overwrite those created by the operator.

WARNING: Changing this may beak some of the functionality that depend on the query overwritten.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• server-lists
  

You may configure a global value under operator configuration section SGConfig.spec.shardingSphere.serviceAccount.

• Standalone
• Cluster

When Standalone only 1 coordinator instance may be set.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• proxy-frontend-database-protocol-type
• proxy-default-port
  

• Memory
• ZooKeeper
• Etcd

When mode.type is standalone then repository.type must be memory. When mode.type is cluster then repository.type could be any of zooKeeper or etcd.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• server-lists
  

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#authentication-configuration

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#authorization-configuration

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#database_permitted

• async (default)
• sync
• strict-sync
• sync-all
• strict-sync-all

async

When in asynchronous mode the cluster is allowed to lose some committed transactions. When the primary server fails or becomes unavailable for any other reason a sufficiently healthy standby will automatically be promoted to primary. Any transactions that have not been replicated to that standby remain in a “forked timeline” on the primary, and are effectively unrecoverable (the data is still there, but recovering it requires a manual recovery effort by data recovery specialists).

sync

When in synchronous mode a standby will not be promoted unless it is certain that the standby contains all transactions that may have returned a successful commit status to client (clients can change the behavior per transaction using PostgreSQL’s synchronous_commit setting. Transactions with synchronous_commit values of off and local may be lost on fail over, but will not be blocked by replication delays). This means that the system may be unavailable for writes even though some servers are available. System administrators can still use manual failover commands to promote a standby even if it results in transaction loss.

Synchronous mode does not guarantee multi node durability of commits under all circumstances. When no suitable standby is available, primary server will still accept writes, but does not guarantee their replication. When the primary fails in this mode no standby will be promoted. When the host that used to be the primary comes back it will get promoted automatically, unless system administrator performed a manual failover. This behavior makes synchronous mode usable with 2 node clusters.

When synchronous mode is used and a standby crashes, commits will block until the primary is switched to standalone mode. Manually shutting down or restarting a standby will not cause a commit service interruption. Standby will signal the primary to release itself from synchronous standby duties before PostgreSQL shutdown is initiated.

strict-sync

When it is absolutely necessary to guarantee that each write is stored durably on at least two nodes, use the strict synchronous mode. This mode prevents synchronous replication to be switched off on the primary when no synchronous standby candidates are available. As a downside, the primary will not be available for writes (unless the Postgres transaction explicitly turns off synchronous_mode parameter), blocking all client write requests until at least one synchronous replica comes up.

Note: Because of the way synchronous replication is implemented in PostgreSQL it is still possible to lose transactions even when using strict synchronous mode. If the PostgreSQL backend is cancelled while waiting to acknowledge replication (as a result of packet cancellation due to client timeout or backend failure) transaction changes become visible for other backends. Such changes are not yet replicated and may be lost in case of standby promotion.

sync-all

The same as sync but syncInstances is ignored and the number of synchronous instances is equals to the total number of instances less one.

strict-sync-all

The same as strict-sync but syncInstances is ignored and the number of synchronous instances is equals to the total number of instances less one.

When FromExistingBackup mode is set this field restrict the selection of SGBackup to be used for recovery newer than the specified value.

When FromNewlyCreatedBackup mode is set this field skip the creation SGBackup to be used for recovery if one newer than the specified value exists.

Possible values are:

• FromPrimary: When this mode is used replicas will be always created from the primary using pg_basebackup.
• FromReplica: When this mode is used replicas will be created from another existing replica using pg_basebackup. Fallsback to FromPrimary if there’s no replica or it fails.
• FromExistingBackup: When this mode is used replicas will be created from an existing SGBackup. If backupNewerThan is set the SGBackup must be newer than its value. When this mode fails to restore an SGBackup it will try with a previous one (if exists). Fallsback to FromReplica if there’s no backup left or it fails.
• FromNewlyCreatedBackup: When this mode is used replicas will be created from a newly created SGBackup. Fallsback to FromExistingBackup if backupNewerThan is set and exists a recent backup newer than its value or it fails.
  

• The string ‘latest’, which automatically sets the latest major.minor Postgres version.
• A major version, like ‘14’ or ‘13’, which sets that major version and the latest minor version.
• A specific major.minor version, like ‘14.4’.
  

requires the creation in a database using the CREATE EXTENSION statement. After an extension is deployed correctly it will be present until removed and the cluster restarted.

A cluster restart is required for:

• Extensions that requires to add an entry to shared_preload_libraries configuration parameter.
• Upgrading extensions that overwrite any file that is not the extension’s control file or extension’s script file.
• Removing extensions. Until the cluster is not restarted a removed extension will still be available.
• Install of extensions that require extra mount. After installed the cluster will require to be restarted.

If not specified then the vanilla Postgres will be used for the cluster.

This field can only be set on creation.

This section is filled by the operator.

If not specified the default duration will be of 13 months.

The certificate will be re-generated 1 day or, if more, 1/12th of its duration before it expires.

If true certificate and private key will be auto-generated unless fields certificateSecretKeySelector and privateKeySecretKeySelector are specified.

For more information see https://servicebinding.io/spec/core/1.0.0/

Changing this field may require a restart.

Use cron syntax (m h dom mon dow) for this parameter, i.e., 5 values separated by spaces:

• m: minute, 0 to 59.
• h: hour, 0 to 23.
• dom: day of month, 1 to 31 (recommended not to set it higher than 28).
• mon: month, 1 to 12.
• dow: day of week, 0 to 7 (0 and 7 both represent Sunday).

Also ranges of values (start-end), the symbol * (meaning first-last) or even */N, where N is a number, meaning ““every N, may be used. All times are UTC. It is recommended to avoid 00:00 as base backup time, to avoid overlapping with any other external operations happening at this time.

If not set, full backups are never performed automatically.

See also https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP

A value of 0 (zero) means no retries are made. Defaults to: 3.

When provided will indicate where the backups and WAL files will be stored.

The first path indicate the coordinator path and the other paths indicate the workers paths

WARNING: Most users should leave this field empty since having it manually set could be dangerous. If the value is repeated due to re-creating an SGShardedCluster or re-using the same value in another SGShardedCluster and you may get a mixed WAL history with unrecoverable backups.

When provided will indicate where the backups and WAL files will be stored.

WARNING: Most users should leave this field empty since having it manually set could be dangerous. If the value is repeated due to re-creating an SGShardedCluster or re-using the same value in another SGShardedCluster and you may get a mixed WAL history with unrecoverable backups.

If not set defaults to 300 (5 minutes). If set to 0 it will disable timeout.

Failure of reconciliation will not make the backup fail and will be re-tried the next time a SGBackup or shecduled backup Job take place.

Consequently, the time range covered by backups is periodicity*retention, where periodicity is the separation between backups as specified by the cronSchedule property.

Default is 5.

Defaults to: PT1S.

Defaults to: 10.

Defaults to: PT1M.

If not set it will be disabled and the backup operation will continue until the backup completes or fail. If set to 0 is the same as not being set.

Make sure to set a reasonable high value in order to allow for any unexpected delays during backup creation (network low bandwidth, disk low throughput and so forth).

This functionality still require to store WAL files in an SGObjectStorage but could result in much faster backups and restore of those backups.

See also https://kubernetes.io/docs/concepts/storage/volume-snapshots/

See also https://kubernetes.io/docs/concepts/storage/volume-snapshots/

Changing this field may require a restart.

Changing this field may require a manual modification of the database users to reflect the new values specified.

In particular you may have to create those users if username is changed or alter password if it is changed. Here are the SQL commands to perform such operation (replace default usernames with the new ones and *** with their respective passwords):

• Superuser username changed:

CREATE ROLE postgres;

• Superuser password changed:

ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD '***';

• Replication username changed:

CREATE ROLE replicator;

• Replication password changed:

ALTER ROLE replicator WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN REPLICATION NOBYPASSRLS PASSWORD '***';

• Authenticator username changed:

CREATE ROLE authenticator;

• Authenticator password changed:

ALTER ROLE authenticator WITH SUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION NOBYPASSRLS PASSWORD '***';

Changing this field may require a restart.

Changing this field may require a restart.

The queries defined here will overwrite those created by the operator.

WARNING: Changing this may break some of the functionality that depend on the query overwritten.

When this field is changed the retention will be applied only to log entries that are newer than the end of the retention window previously specified. If no retention window was previously specified it is considered to be of 7 days. This means that if previous retention window is of 7 days new retention configuration will apply after UTC timestamp calculated with: SELECT date_trunc('days', now() at time zone 'UTC') - INTERVAL '7 days'.

If not specified it will be interpreted as latest.

Point In Time Recovery (PITR). PITR allows restoring the database state to an arbitrary point of time in the past, as long as you specify a backup older than the PITR requested restoration date and does not exist a backup newer than the same restoration date.

See also: https://www.postgresql.org/docs/current/continuous-archiving.html

Custom Kubernetes annotations.

Custom Kubernetes labels.

The same best practice applies to databases on containers. By default, StackGres will not allow running more than one StackGres pod on a given Kubernetes node. Set this property to true to allow more than one StackGres pod per node.

This property default value may be changed depending on the value of field .spec.profile.

This property default value may be changed depending on the value of field .spec.profile.

By default, StackGres will configure resource requirements for all the containers. Set this property to true to prevent StackGres from setting container’s resources requirements (except for patroni container, see disablePatroniResourceRequirements).

This property default value may be changed depending on the value of field .spec.profile.

The same best practice applies to databases on containers. By default, StackGres will configure resource requirements for patroni container. Set this property to true to prevent StackGres from setting patroni container’s resources requirement.

This property default value may be changed depending on the value of field .spec.profile.

On containerized environments, when running production workloads, enforcing container’s cpu requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less cpu than it requires. It also allows setting static CPU management policy that allows to guarantee a pod the usage exclusive CPUs on the node.

By default, StackGres will configure cpu requirements to have the same limit and request for all the containers. Set this property to true to make StackGres set container’s cpu requirements request equals to the limit (except for patroni container, see enableSetPatroniCpuRequests) when .spec.requests.containers.<container name>.cpu .spec.requests.initContainers.<container name>.cpu is configured in the referenced SGInstanceProfile.

On containerized environments, when running production workloads, enforcing container’s memory requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less memory than it requires.

By default, StackGres will configure memory requirements to have the same limit and request for all the containers. Set this property to true to make StackGres set container’s memory requirements request equals to the limit (except for patroni container, see enableSetPatroniMemoryRequests) when .spec.requests.containers.<container name>.memory .spec.requests.initContainers.<container name>.memory is configured in the referenced SGInstanceProfile.

On containerized environments, when running production workloads, enforcing container’s cpu requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less cpu than it requires. It also allows setting static CPU management policy that allows to guarantee a pod the usage exclusive CPUs on the node.

By default, StackGres will configure cpu requirements to have the same limit and request for the patroni container. Set this property to true to make StackGres set patroni container’s cpu requirements request equals to the limit when .spec.requests.cpu is configured in the referenced SGInstanceProfile.

On containerized environments, when running production workloads, enforcing container’s memory requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less memory than it requires.

By default, StackGres will configure memory requirements to have the same limit and request for the patroni container. Set this property to true to make StackGres set patroni container’s memory requirements request equals to the limit when .spec.requests.memory is configured in the referenced SGInstanceProfile.

Available feature gates are:

• babelfish-flavor: Allows using the babelfish flavor.
  

Configuration for the workers services

If the sharding type is shardingsphere then the name of the service will be the same name as the SGShardedCluster.

It provides a stable connection (regardless of node failures) to any Postgres server of the coordinator cluster. Servers are load-balanced via this service.

See also https://kubernetes.io/docs/concepts/services-networking/service/

The names of custom ports will be prefixed with the string custom- so they do not conflict with ports defined for the coordinator services.

The names of target ports will be prefixed with the string custom- so that the ports that can be referenced in this section will be only those defined under .spec.pods.customContainers[].ports sections where names are also prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#serviceport-v1-core

If the sharding type is shardingsphere then this service will be disabled.

It provides a stable connection (regardless of primary failures or switchovers) to the read-write Postgres server of the coordinator cluster.

See also https://kubernetes.io/docs/concepts/services-networking/service/

It provides a stable connection to read-write Postgres servers of any query router worker SGCluster. Read-write servers are load-balanced via this service.

See also .spec.coordinator.queryRouterClusters

See also https://kubernetes.io/docs/concepts/services-networking/service/

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
  

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
  

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
  

The names of custom ports will be prefixed with the string custom- so they do not conflict with ports defined for the workers services.

The names of target ports will be prefixed with the string custom- so that the ports that can be referenced in this section will be only those defined under .spec.pods.customContainers[].ports sections where names are also prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#serviceport-v1-core

It provides a stable connection (regardless of primary failures or switchovers) to read-write Postgres servers of any worker SGCluster. Read-write servers are load-balanced via this service.

See also https://kubernetes.io/docs/concepts/services-networking/service/

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.