├── LICENSE ├── README.md └── postgres ├── README.md ├── spec ├── README.md ├── feature_matrix.md ├── feature_matrix.yaml └── yaml2md │ ├── README.md │ ├── yaml2md.sh │ └── yaml2md.tmpl └── vendor-submissions ├── README.md ├── vendor-submission-template-generator ├── vendor-submission-template-generator.sh └── vendor-submission-template-generator.tmpl └── vendor-submission-template.yaml /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Operator Feature Matrix (OFM) 2 | 3 | The *Operator Feature Matrix* (OFM) is a project from the [Data on Kubernetes (DoK) Community](https://dok.community/) to create standardized and vendor-neutral _feature matrix_ for various Kubernetes operators that manage stateful workloads. The key concepts behind the project are: 4 | 5 | * **The Feature Matrix**. A categorized and structured set of features that a given operator (for a particular technology) may support. 6 | * **Standardized features**. Define terminology for features so that naming is standardized. 7 | * **Vendor neutral**. OFM is a project started by the DoK with contributions from various organizations and contributors. 8 | 9 | 10 | The main goals of the OFM are: 11 | * Allow end users to quickly identify if a given operator supports or not a given feature or set of features. 12 | * Provide clear and standardize feature naming to avoid end users being confused about the meaning of particular features provided by an operator. 13 | * Enable end users to produce objective, side-by-side comparisons of the features implemented by different operators (for a given technology). 14 | 15 | 16 | The OFM is developed by consensus, and standardized; submissions of the features implemented by each vendor at a particular operator release are expected to be contributed by the vendors themselves or their respective Communities. 17 | 18 | 19 | The OFM is technology-dependent, as most of the features of a given technology (e.g. the Postgres relational database) are different from the features end users expect from another different technology (e.g. Kafka). As of today, there is one OFM implemented: 20 | 21 | * [Postgres](postgres) 22 | 23 | It is expected that other technologies may add their respective OFM to this project, following similar directions to the one already existing. However, it is also expected that once a few technologies and their respective OFM are added, a common subset of features that may span across all potential technologies may be identified. In this case, a cross-technology OFM subset could be created, and existing projects (partially) retrofitted to that model, so that technology-independent features are identified as such. 24 | -------------------------------------------------------------------------------- /postgres/README.md: -------------------------------------------------------------------------------- 1 | # Postgres Operator Feature Matrix (Postgres OFM) 2 | 3 | 4 | This directory contains the OFM for Postgres Kubernetes operators. Please refer to the [main project's README.md](../README.md) for more information about the the OFM (Operator Feature Matrix) project. 5 | 6 | 7 | The contents of this directory are structured as follows: 8 | 9 | * [spec](spec). Contains the specification of the Postgres OFM. 10 | * [vendor-submissions](vendor-submissions). Contains the submission files that every vendor has contributed for each of the releases that they submitted a compliance OFM. Includes documentation for vendors on how to submit their compliance OFMs. 11 | 12 | -------------------------------------------------------------------------------- /postgres/spec/README.md: -------------------------------------------------------------------------------- 1 | # Postgres OFM Specification 2 | 3 | 4 | The contents of this directory are structured as follows: 5 | 6 | * [feature_matrix.yaml](feature_matrix.yaml). The feature matrix itself. It is a YAML file that serves as the source of truth for the Postgres OFM features. It is encoded in a machine parsable format to allow other files to be derived from it, as well as to allow automatic processing of the features. 7 | * [feature_matrix.md](feature_matrix.md). This file acts as a "view" to the matrix, providing a convenient way to represent it visually. This file should not be edited directly, as it is generated automatically from the [feature_matrix.yaml](feature_matrix.yaml) file. This render is intented to aid in reading and understanding the specification itself, but it is not expected to be consumed directly by end users. Instead, end users are expected to view the submissions made by vendors or, better, the Markdown or web renderings of such submissions. 8 | * [yaml2md](yaml2md). Directory that contains the script to render the Markdown feature matrix from the YAML feature matrix. 9 | 10 | 11 | ## Description of the Postgres feature matrix 12 | 13 | The OFM is contained in the [feature_matrix.yaml](feature_matrix.yaml) file. The most relevant fields of the document are: 14 | * `.metadata`. Contains information about the OFM Specification, including its version and version release date. 15 | * `.categories`. Features are classified first into categories. It is an array of features. Each category has an `.id` and a `.name`. The `.id` is an immutable and unique four characters identifier, and the `.name` is a mutable and user-friendly definition of the category. 16 | * `.categories[].features`. An array that contains all the features for every category. 17 | * `.categories[].features[]`. Each feature. Similarly to categories, they contain an `.id` (in this case five characters) and a `.name`. They also contain other relevant fields: 18 | * `type`. It is the data type of the value that vendors will provide on the submission for this particular feature. For most of the features this field will be `boolean`, which is the easiest way for end users to visually read a comprehensive feature matrix with many features. Some other features require more details, and may have `enum`, `string` or even `string_array` types for this field. 19 | * `description`. It is the end user facing description of the feature. May include Markdown syntax to enhance readability. 20 | * `vendor_compliance`. It is a field for vendors that provides clarification on how the feature is expected to be implemented in order to achieve compliance with the feature. It also accepts Markdown formatting. 21 | * `main`. It is a cross-categories field to identify features that are considered more important or "core" to the whole OFM. They may be rendered independently of the others to signify their relevance. 22 | 23 | 24 | 25 | -------------------------------------------------------------------------------- /postgres/spec/feature_matrix.md: -------------------------------------------------------------------------------- 1 | 2 | ## General Characteristics – [genc](#genc) 3 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 4 | |---|---|---|---|---|---| 5 | | instm | Installation mechanism | string_array | Mechanism(s) provided to install the operator. | Provide a succinct value or list of values of the supported mechanisms.
If any of the following names apply, use them, and add other mechanism names, as needed:

* YAML
* Helm
* Kustomize
* Operator Bundle
| ✓ | 6 | | mcrds | Management via CRDs | boolean | The operator manages CRDs (Custom Resource Definition). | If true, provide a list of the names of the CRDs managed by the operator. Names should be direct links to their documentation or API reference.
| ✓ | 7 | | offin | Offline installation | boolean | Whether it is possible to install the operator on a (air-gapped) cluster without internet connection. | A link should be provided with documentation on how to install the operator on air-gapped environments.
| | 8 | | scpua | Supported CPU architectures | string_array | Support for the operator to run on nodes with specified CPU architectures. | Provide a list of CPU architectures that are supported between:

* amd64
* arm
* arm64
* ppc64le
* s390x

In case you support additional architectures, add their name(s) in a similar fashion.
| | 9 | | coios | Container images OSes | string_array | Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.).
Provide the image name without tags (e.g. debian instead of debian:8.11). | | | 10 | | olmcl | Operator Capability Level | string | [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) indicates the operator maturity
levels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability models
aims to provide guidance in terminology to express what features users can expect from an operator. | Capability level must be set to one of the following levels:

1. `Basic Install`
2. `Seamless Upgrades`
3. `Full Lifecycle`
4. `Deep Insights`
5. `Auto Pilot`

A link should be provided with documentation on how the operator fulfil the declared capability level.

For a detailed description of each capability level refer to the Operator Framework documentation for
[Operator Capability Level](https://sdk.operatorframework.io/docs/overview/operator-capabilities/).
| | 11 | 12 | 13 | ## Versions – [vers](#vers) 14 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 15 | |---|---|---|---|---|---| 16 | | pgver | Supported PostgreSQL versions | string_array | Which major (and minor) versions does this version of the operator support. | Provide a list of every supported major version followed by a list in parenthesis of the minor versions supported for that major version.
E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order.
Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.)
| ✓ | 17 | | k8ver | Supported Kubernetes versions | string_array | Which Kubernetes versions the operator can be installed into. | Provide a list of official Kubernetes minor versions numbers, ordered by reverse chronological order.
Use a range of versions, if possible, e.g. '1.26 - 1.23' or '1.22 - 1.19'.
| ✓ | 18 | | pgfor | PostgreSQL OSS forks | string_array | PostgreSQL forks are considered derived projects that started from PostgreSQL codebase and add different features while maintaining compatibility with PostgreSQL.
Some operators may provide support for some of such forks, alongside with the original PostgreSQL. | Leave empty if no version other than the original PostgreSQL is supported. Otherwise, provide a list of names and links to the PostgreSQL forks supported.
If non-OSS forks are supported, leave empty but add a link to them in the comments section.
| | 19 | 20 | 21 | ## Licensing & Support – [lisu](#lisu) 22 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 23 | |---|---|---|---|---|---| 24 | | ossli | Open Source license | boolean | The operator is published, and its source code is made publicly available, under an OSI-approved open source license. | If true, provide the SPDX identifier(s) of the license.
| ✓ | 25 | | fcimg | Free container images | boolean | The container images used for the operator's operation are free to distribute and use, not subject to commercial restrictions. | If false, provide a link with documentation on the usage requisites/restrictions of the container images.
| ✓ | 26 | | nenof | No enterprise-only features | boolean | All the operator's features are provided as open source.
No derived, proprietary (often called 'enterprise') versions exist with additional, non open source features. | If false, provide links to all known derived, proprietary versions.
Linked documentation should clearly reflect the features that are only part of proprietary versions.
| | 27 | | comms | Commercial support | boolean | Vendor and/or other entities offer paid-for, commercial support for the operator. | Provide a link or list of links to the entities that provide commercial support.
Links should be as specific as possible, pointing to informative documentation on the provided support.
| | 28 | | pubit | Public issue tracker | boolean | Development happens in the open. There is a public issue tracker where users may view, comment and create issues. | Provide a specific link to the issue tracker.
| | 29 | | pubch | Public chat/forums | boolean | There is/are public forums, mailing lists, chat groups (Slack, Discord, Matrix, etc) where users may freely join and participate in discussions. | Provide links to all relevant user forums.
| | 30 | 31 | 32 | ## PostgreSQL Clusters – [pgcl](#pgcl) 33 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 34 | |---|---|---|---|---|---| 35 | | depau | Deployment automation | boolean | The operator provides capabilities to automatically deploy production-ready clusters based on a provided configuration.
No user initiated commands must be required. | | | 36 | | pomte | Pod management technology | string | Which Pod management technology is used to handle database's Pods. E.g. 'StatefulSet', 'Deployment', 'Custom', etc. | Provide the most succinct possible name of the technology. Use the Kubernetes resource type name (e.g. 'Deployment'), if applicable.
| ✓ | 37 | | pgcnf | PostgreSQL custom config | boolean | The operator allows the user to supply custom PostgreSQL configuration. | | | 38 | | conpl | Integrated connection pooling | boolean | The operator provides options to deploy a connection pool in front of the database, automatically deployed and configured. | The connection pool may be deployed in several ways, like a Deployment layer, a side car, etc.
All should be valid towards this feature as long as they are deployed automatically and offer an entrypoint for the user to the connection pooler.
| ✓ | 39 | | cpccf | Connection pool custom config | boolean | The operator allows the user to supply a custom connection pool configuration for the connection pool service. | Only applies if [pgcl/conpl] is true.
| | 40 | | tlssp | TLS Support | boolean | PostgreSQL connections can be secured with Postgres SSL/TLS support. | | ✓ | 41 | | tlscu | TLS user-provided certificates | boolean | Operators may chose by default to generate self-signed SSL certificates.
They may also offer the option to specify the CA and certificates that users want Postgres clusters to use. | | | 42 | | crtmg | CertManager integration | boolean | The operator integrates with CertManager in order to generate the certificate to be used with Postgres. | Only applies if [pgcl/tlscu] is true.
| | 43 | | insql | Initialization from SQL scripts | boolean | After the database cluster creation, the operator will run automatically one or more user-supplied scripts for initial DDL or data (possibly limited in size) creation.
The operator must properly inform the user of the execution result of the scripts. | | | 44 | | inext | Initialization from external source | boolean | After the database cluster creation, the operator will automatically connect to an external data source (like an object storage or a public repo) and fetch the DDL/data.
The operator must properly inform the user of the execution result of the scripts. | | | 45 | | cuhba | HBA custom config | boolean | The operator allows users to provide custom configuration for the Postgres HBA (Host-Based Authentication) mechanism.
It may involve directly generating the custom `pg_hba.conf` file or by using more cloud-native technologies. | | | 46 | | mgmup | Management of db users/passwords | boolean | The operator provides a mechanism to declaratively create, modify or delete users, roles and/or password for the PostgreSQL cluster. | | | 47 | | reqli | Customize computing resource requests, limits | boolean | The user may specify/customize the requests, the limits or both for computing resources (CPU, memory) of the Postgres pods. | | ✓ | 48 | | hugpa | Support for huge pages | boolean | The user may specify the request to use huge pages for Postgres (and/or potentially other sidecars).
Postgres must be able to be configured and start using huge pages. | | ✓ | 49 | | pgsrv | PostgreSQL exposed via Service | string | The operator creates by default or allows the user to request one or more Kubernetes Service(s) to be created to expose the PostgreSQL connections.
Expected capabilities should include a RW (read-write) or RO (read-only in case of cascading replication) connection to the primary instance; and, optionally, a RO (read-only) to load balance read-only replicas instances in the cluster. | The value must be one of:

* PrimaryAndReplicas: Primary and replicas services must be offered.
* PrimaryAndReplicasAndBalanced: Primary service, replicas services and a service that load balance RW/RO traffic transparently must be offered.
* Balanced: A single service that load balances RW/RO traffic transparently.
* Primary: Primary service must be offered.
| | 50 | | stosc | Automatic storage scaling | boolean | If the user's selected storage technology supports transparent scaling, the operator will take care of scaling the storage automatically
(either by setting some default thresholds or requiring explicit declarative configuration from the user). | | | 51 | | scal0 | Scale down to zero | boolean | The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed.
Upon scaling up, the cluster should be brought back up without the need to restore a backup. This feature may also be known as "hibernation". | | | 52 | | tblsp | Tablespaces | boolean | The user may specify one or more PostgreSQL tablespaces and their associated backing storage. | | | 53 | | cupgi | Custom Postgres images | boolean | The operator allows the user to specify custom (user-provided) Postgres container images, instead of using the operator's provided images. | The operator should specify if the custom image needs to follow some minimal patterns to be able to work, or if it can work
with any postgres container image provided.
| | 54 | | uside | User supplied sidecars | boolean | The user may specify custom sidecars (containers or init containers) to be created alongside the Postgres container (and, possibly, other operator sidecars).
User supplied sidecars must be able, by default or by configuration, to access the Postgres container filesystem and Unix Domain Sockets file. | | | 55 | | usvol | User supplied volumes | boolean | The user may specify and mount custom volumes to be created alongside the volumes created for the Postgres container. | | | 56 | | usprt | User supplied ports | boolean | The user may specify custom ports to be created alongside the services that expose PostgreSQL. | Only applies if [pgcl/pgsrv] is set.
| | 57 | | srvbi | Support for Service Binding | boolean | [Service Binding](https://servicebinding.io/spec/core/1.0.0/) is a Kubernetes specification to "communicating service secrets to workloads in a consistent way".
If the operator supports Service Binding, applications that are bound to the Postgres clusters will be able to fetch database access credentials without requiring
the user to specify them manually in the application. | The operator must implement the [Provisioned Service](https://servicebinding.io/spec/core/1.0.0/#provisioned-service) part of the specification.
| | 58 | | cuann | Custom Annotations | boolean | The operator allows the user to provide custom [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
(aside from any operator generated Annotations) to the objects generated by the operator. | The operator must provide configuration for setting Annotations on all objects generated by the operator.
Partial compliance is achieved if at least Pods can be annotated and this is clearly marked in the comments.
| | 59 | | culab | Custom Labels | boolean | The operator allows the user to provide custom [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to the objects generated by the operator. | The operator must provide configuration for setting Labels on all objects generated by the operator.
Partial compliance is achieved if at Labels can be added to at least Pods and this is clearly marked in the comments.
| | 60 | | apdnd | Assign Pod to Node | string | The operator allows Postgres Pods to be assigned to a specific set of Nodes based on some [Kubernetes known rules](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/). E.g. Node Labels, Affinity, etc. | Indicate one of the following values:

* 'Complete': if the operator support all the rules to assign a Pod to a Node defined in the latest Kubernetes version specified under [vers/k8ver].
* 'Partial': if the operator support only partially the rules to assign a Pod to a Node.

A link for each supported rule or rules group to assign a Pod to a Node must be specified.
| | 61 | | topsc | Topology Spread Constraints | boolean | The operator allows Postgres pods to specify [Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints),
to control how Pods are spread across the Kubernetes cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. | | | 62 | 63 | 64 | ## HA & Replication – [harp](#harp) 65 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 66 | |---|---|---|---|---|---| 67 | | autfa | Automated failover | boolean | The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected,
another Postgres instance (if available) will be promoted to primary. The operation must happen automatically without user intervention. | | ✓ | 68 | | techa | HA Technology | string | The technology (software name or technology principles) that support the high availability and automated failover capabilities of the operator. | Provide a succinct software or technology name. E.g.: Patroni, Stolon, Custom.
| ✓ | 69 | | asrep | Asynchronous replication | boolean | The operator allows to configure Postgres clusters using asynchronous streaming replication.
Asynchronous is the default streaming replication mode in Postgres. | | | 70 | | syrep | Synchronous replication | boolean | The operator allows to configure Postgres clusters using synchronous streaming replication.
The operator must manage the configuration details based on the user's preferences on which nodes behave synchronously. | | | 71 | | serep | Semi-synchronous replication | boolean | Semi-synchronous, or also called group or quorum replication, is a hybrid mode where a subset of the nodes is expected to replicate synchronously;
and once that level is reached, the remainding nodes replicate asynchronously.
That is, Postgres waits for confirmation of the write only from the synchronous nodes before considering the transaction committed. | | | 72 | | derep | Delayed replicas | boolean | The operator allows the user to configure one or more replicas subject to a user-specified (intentional) replication lag.
This is useful to have always an online instance with data "in the past" for analytics or data recovery purposes. | | | 73 | | carep | Cascading replication | boolean | Postgres allows to create replicas that are fed from another replica, instead of replicating from the primary instance.
This is interesting to alleviate the effects of replication on the primary; and allows to create arbitrary replication tree-like topologies. | | | 74 | | exrep | Replication from external origin | boolean | The operator allows a Postgres cluster to be setup in recovery mode while replicating from an external (non-operator managed) Postgres origin.
This allows migrations to the operator using streaming replication. | To implement the feature, the user should be able to provide arbitrary host, port, username and password (or other means of credential passing) of the origin.
| | 75 | | walsh | WAL Shipping | boolean | WAL Shipping is a Postgres technique that allows replication via a shared storage mechanism where WAL files produced on the primary node are copied ("shipped") to the replica.
This feature is useful for having replicas for example on DR sites, replicate over global storage object stores and others. | Implementing the feature implies both generating WAL files to a suitable location; as well as creating clusters that permanently read those WAL files and replicate from them.
| | 76 | | prstb | Promote standby cluster | boolean | The operator allows the user to promote a standby cluster that is a cluster with primary in recovery mode so that the primary becomes RW. This feature is used in conjunction with [harp/exrep] and/or [harp/walsh] to make GEO-replicated and/or DR (Disaster Recovery) clusters on other regions, where a region is essentially an independent Kubernetes cluster. | Only applies if [harp/exrep] or [harp/walsh] are true.
The operator must allow to promote a standby clusters replicating either via WAL Shipping and/or streaming replication.
| ✓ | 77 | | lorep | Managed logical replication | boolean | Postgres supports logical replication as well as streaming replication. It requires some configuration and commands to be run by the user.
This feature represents operator capabilities to perform these operations in a managed way, without the user having to type commands or create configurations directly. | The operator is considered compliant if it allows the user to provide logical replication without having to setup it directly, just specifying (declarative) preferences.
The operator is still considered compliant if it cannot proceed until certain operations are performed by the users that are dependent on their environment
(e.g. adding PKs, UNIQUEs or REPLICA IDENTITY to the DDL).
| | 78 | 79 | 80 | ## PostgreSQL Extensions – [pgex](#pgex) 81 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 82 | |---|---|---|---|---|---| 83 | | extme | Extensions distribution mechanism | string | This feature is set to describe how extensions are shipped in a containerized environment.
Typically they are part of the same Postgres container image, but they may also be distributed via other mechanisms. | Indicate 'built-in' if the extensions come included with the same Postgres container; or a succinct word or few words naming the distribution mechanism.
More details may be provided, if needed, via the links and comments fields.
| | 84 | | coext | Core/contrib extensions | integer | The number of core+contrib extensions provided by the operator for the latest Postgres version provided by the operator. | Submission must provide the total number of core+contrib extensions supported for the latest Postgres version provided by the operator.
It should also be provided, when available, a link with a detailed list of those extensions supported (via links field).
| ✓ | 85 | | thext | Third-party extensions | integer | The number of extensions not included in the Postgres core+contrib (i.e. created by third parties, outside of Postgres repository) for the latest Postgres version provided by the operator. | Submission must provide the total number of third-party extensions supported for the latest Postgres version provided by the operator.
A link with a detailed list of those extensions supported (via links field) should also be provided, if available.
| ✓ | 86 | | byext | Bring your own extension | boolean | The operator provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. | The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism,
if a user builds a local extension, this could be uploaded or included on the postgres container with an automatic copy to all replicas related.
| | 87 | 88 | 89 | ## Backups – [bkup](#bkup) 90 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 91 | |---|---|---|---|---|---| 92 | | bktch | Backup Technology | string | What technology (pgbasebackup, PgBackRest, WAL-e/g, Barman, custom, etc) is used to support creation and restoration of backups. | Provide the most succinct possible name of the technology.
| ✓ | 93 | | bkdst | Backup destinations | string_array | Where backups can be stored (typically this may include object stores, PVs, etc). | If any of the following technology names apply, use them, and add other names, as needed:

* PersistentVolume
* NFS
* S3
* GCS
* Azure Blob
* Local file system
| | 94 | | autbk | Automated backup management | boolean | The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy - often known as retention policies). | True response for the feature implies both automatic backups and lifecycle management.
If only the former is provided, answer should be false but this capability should be mentioned in the comments field.
| ✓ | 95 | | encbk | Backups encryption | boolean | Backups can be performed with user-supplied encryption keys. | | | 96 | | ptrbk | Point In Time Recovery | boolean | The operator provides support for the user to specify a recovery point (in the past) to which a backup should be recovered to
(if unspecified, backup will be recovered in full). | True response implies that at least time-based recovery is supported.
If the operator also supports PITR by xid and label, clarify in the comments field.
| | 97 | | mulbk | Multiple backup configurations | boolean | The operator supports managing more than one backup configuration.
This is typically used to store backups on different object stores (for protection purposes) or to send them to different sites.
It may also include different lifecycle policies. | | | 98 | 99 | 100 | ## Management Interfaces – [mgmi](#mgmi) 101 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 102 | |---|---|---|---|---|---| 103 | | cucol | Resource display columns | boolean | Operator-managed objects (CRDs) include specific fields that provide additional information about the Postgres instances.
These fields are shown when querying the Kubernetes resources using tools like `kubectl`. | In order to be compliant, operators have to provide at least the following information:

* Replication status (primary/replica/etc)
* Cluster status (healthy/not healthy)
* Postgres major/minor version
* Latest base backup date
* SSL on/off
| | 104 | | kbplg | kubectl plugin | boolean | The users may download an additional kubectl plugin which provides custom commands to manage the operator. | If the feature is provided, include a link to the downloadable plugin in the links field.
| | 105 | | bagui | Basic management GUI | boolean | The operator bundles some GUI (web interface or other) that allows to perform basic operations (e.g. cluster creation) graphically. | | ✓ | 106 | | fugui | Fully-featured GUI | boolean | The operator bundles a GUI that is fully-featured (that is, in feature-parity with the capabilities provided via the other management interfaces -- typically CRDs).
The GUI may provide additional features that cannot be otherwise provided via text interfaces (e.g. graphical representation of resources or operations). | | ✓ | 107 | | urgui | GUI users & roles | boolean | The bundled management GUI has authentication and authorization baked in and provides mechanisms to support multiple users and authorize/deny them to perform operations. | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided.
Submission should detail in the link and/or comments field how users and roles for the GUI can be managed.
| | 108 | | guiss | GUI Single-Sign On | boolean | The bundled management GUI supports integration with Single-Sign On (SSO), like OIDC, identity providers (e.g. Google, Github or Twitter login). | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided.
| | 109 | | cogui | GUI database console | boolean | The bundled management GUI includes a console that can connect to any database managed by the operator and send command (e.g. like `psql`). | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided.
| | 110 | 111 | 112 | ## Observability – [o11y](#o11y) 113 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 114 | |---|---|---|---|---|---| 115 | | mtech | Metrics technology | string_array | If the operator supports extracting metrics from Postgres, define how they are handled, which technology receives and processes them.

If any of the following technology names apply, use them, and add other names, as needed:

* Prometheus
* OTEL
* OpenTSDB
* Nagios
* Sensu | If supported, provide in the comments information about whether the technology is a dependency, is built-in, external, etc.
Provide link(s) to the documentation for further information.
| ✓ | 116 | | expme | Export metrics | boolean | Regardless of how metrics are processed (e.g. as part of the operator),
this feature is implemented when the operator allows the user to configure sending metrics to external services, like a metrics SaaS. | | | 117 | | cudas | Custom dashboards | boolean | In order to display the captured Postgres metrics, the operator provides specialized Postgres dashboards for the users. | | | 118 | | cuale | Custom alerts | boolean | The operator provides bundled specific Postgres alerts to be triggered on the Postgres metrics processed.
E.g. there is an alert for transaction wraparound or for unused replication slots. | | | 119 | | exdel | Exposed decorated logs | boolean | The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool.
The logs must be decorated with extra metadata in order to provide semantic meaning, including the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries.
There is no need to configure the tool in order to obtain required extra metadata from the logs. | | | 120 | | explg | Export logs | boolean | The operator allows the user to configure an external sink for the Postgres logs (e.g. a SaaS service). | | | 121 | | oo11y | Operator Observability | boolean | The operator is itself a source of telemetry data, potentially including metrics, traces and logs, about its own performance. | | | 122 | 123 | 124 | ## Security – [secy](#secy) 125 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 126 | |---|---|---|---|---|---| 127 | | opcsc | Operator code security scanning | boolean | The operator code is always scanned for security vulnerabilities. | | ✓ | 128 | | imgsc | Image scanning | boolean | Operator-provided images are always scanned for security vulnerabilities. | | ✓ | 129 | | sigim | Signed images | boolean | Container images are digitally signed according to the [sigstore](https://www.sigstore.dev/) project. | Compliance may also be achieved by using a technology other than sigstore, as long as it provides an equivalent set of security capabilities.
| | 130 | | isbom | Software Bill of Materials | boolean | The operator releases include the SBOM (Software Bill of Materials), a detailed description of all the components, modules, and their dependencies. | SBOM is expected to be in accordance to the [Kubernetes SIG BOM](https://github.com/kubernetes-sigs/bom).
| | 131 | | fgopp | Fine-grained RBAC permissions | boolean | The operator uses a separate serviceaccount that has RBAC permissions that only require the access that is actually needed to create and manage the Kubernetes resources, not more. | | | 132 | | noprm | No or justified privileged mode | boolean | The operator-provided containers do not require privileged mode.
The container processes do not run as root. | Reasonable exceptions to this rule can be made for features that require or do not diminish the container's security, e.g. when using eBPF.
| | 133 | 134 | 135 | ## Day 2 Operations – [day2](#day2) 136 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 137 | |---|---|---|---|---|---| 138 | | amiup | Automated minor upgrades | boolean | The operator can perform a minor version upgrade of a Postgres cluster automatically.
This operation can be managed by the user declaratively. | The operator must provide proper information to the user as to the status and final result of the operation.
The operator should provide ongoing status information, and perform the operation with the minimum downtime required.
Provide information about the update strategy (i.e. restart of the pods or rolling update followed by a switchover or a restart).
| ✓ | 139 | | amaup | Automated major upgrades | boolean | The operator can perform a major version upgrade of a Postgres cluster automatically.
This operation can be managed by the user declaratively. | The operator must provide proper information to the user as to the status and final result of the operation.
The operator should provide ongoing status information, and perform the operation with the minimum downtime required.
| ✓ | 140 | | crest | Controlled cluster restart | boolean | Sometimes Postgres needs to be restarted (e.g. changing of a parameter that requires restart).
The operator provides means to perform this operation automatically and in a controlled manner (rolling restart) so that the cluster faces a minimal downtime only. | | | 141 | | ociup | Container images upgrade | boolean | Similarly to the controlled restart operation, the operator is capable of updating the running container images (which require a pod restart) automatically and with minimal cluster impact. | | | 142 | | swtch | Switchover | boolean | If HA capabilities are provided, the operator also provides a mechanism for manual switchover.
The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, by demoting the current primary, promoting the a replica, and updating the endpoints/services as required. | | | 143 | | sqlmi | SQL Migrations | boolean | The operator provides managed SQL migration capabilities.
The user may specify SQL scripts that contain migrations (DDL changes, etc) to be deployed to a given database, having the operator apply them automatically. | The operator must report back to the user detailed information about the results of the execution(s) of the script(s) provided by the user.
| | 144 | | oday2 | Other Day 2 Operations | string_array | The operator provides support for other managed Day 2 operations. | All the mentioned additional day 2 operations need to be possible via declarative configuration and the operator to fully execute them without further user intervention.
| | 145 | 146 | 147 | ## Data Integration – [dain](#dain) 148 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 149 | |---|---|---|---|---|---| 150 | | kfkin | Kafka integration | boolean | The operator provides a managed solution for automation to export CDC (Change Data Capture) events to Kafka. | Kafka could be an external dependency to the operator.
The whole operation is expected to be fully automated, with the user only providing a declarative configuration.
| | 151 | | migpg | Migration from Postgres | string_array | The operator provides a managed capability to automatically migrate data from another (external) Postgres database.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations. | Provide one or more of the following values: `offline`, `cdc`.
| | 152 | | migmy | Migration from MySQL | string_array | The operator provides a managed capability to automatically migrate data from a MySQL database.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations.
Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`.
| | 153 | | migor | Migration from Oracle | string_array | The operator provides a managed capability to automatically migrate data from an Oracle database.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations.
Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`.
| | 154 | | migms | Migration from SQL Server | string_array | The operator provides a managed capability to automatically migrate data from a SQL Server database.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations.
Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`.
| | 155 | | migmo | Migration from MongoDB | string_array | The operator provides a managed capability to automatically migrate data from a MongoDB database.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations.
Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`.
| | 156 | | migot | Migration from other databases | string_array | The operator provides a managed capability to automatically migrate data from other relational or non-relational databases.
Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),
which allows for near-zero downtime migrations.
Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. | Provide the names of the other database from where migration is supported.
| | 157 | 158 | 159 | ## Sharding – [shrd](#shrd) 160 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 161 | |---|---|---|---|---|---| 162 | | mshrd | Managed sharding support | boolean | The operator understands horizontal scalability and is capable to automatically deploying sets of clusters (shards) with their accompanying infrastructure (coordinators, services, etc).
The user should be able to write a declarative configuration of a sharded cluster and the operator to fully deploy it without any further manual user intervention. | | ✓ | 163 | | shrdt | Sharding technology | string_array | If managed sharding support is provided, which technology or technologies are used to provide sharding support (which is not included in Postgres core). | | | 164 | | aggds | Aggregated monitoring dashboards | boolean | Since a sharded cluster is a set of (independent) Postgres clusters, an aggregated dashboard is one that provides Observability information across all shards of the cluster.
E.g. total database size, tps processed or total number of client connections. | | | 165 | | cobkp | Coordinated backups | boolean | A sharded cluster can be backed up by backing up each shard independently, but those backups are not necessarily consistent with each other.
If sharding is used, an additional capability is to coordinate backups on a given timestamp so that they are performed or can be restored at the same logical timestamp,
so they become consistent with each other. | | | 166 | 167 | -------------------------------------------------------------------------------- /postgres/spec/feature_matrix.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | metadata: 3 | version: 1.0-BETA1 4 | date: # when released 5 | categories: 6 | - id: genc 7 | name: General Characteristics 8 | features: 9 | - id: instm 10 | name: Installation mechanism 11 | type: string_array 12 | description: | 13 | Mechanism(s) provided to install the operator. 14 | vendor_compliance: | 15 | Provide a succinct value or list of values of the supported mechanisms. 16 | If any of the following names apply, use them, and add other mechanism names, as needed: 17 | 18 | * YAML 19 | * Helm 20 | * Kustomize 21 | * Operator Bundle 22 | main: true 23 | - id: mcrds 24 | name: Management via CRDs 25 | type: boolean 26 | description: | 27 | The operator manages CRDs (Custom Resource Definition). 28 | vendor_compliance: | 29 | If true, provide a list of the names of the CRDs managed by the operator. Names should be direct links to their documentation or API reference. 30 | main: true 31 | - id: offin 32 | name: Offline installation 33 | type: boolean 34 | description: | 35 | Whether it is possible to install the operator on a (air-gapped) cluster without internet connection. 36 | vendor_compliance: | 37 | A link should be provided with documentation on how to install the operator on air-gapped environments. 38 | - id: scpua 39 | name: Supported CPU architectures 40 | type: string_array 41 | description: | 42 | Support for the operator to run on nodes with specified CPU architectures. 43 | vendor_compliance: | 44 | Provide a list of CPU architectures that are supported between: 45 | 46 | * amd64 47 | * arm 48 | * arm64 49 | * ppc64le 50 | * s390x 51 | 52 | In case you support additional architectures, add their name(s) in a similar fashion. 53 | - id: coios 54 | name: Container images OSes 55 | type: string_array 56 | description: | 57 | Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.). 58 | Provide the image name without tags (e.g. debian instead of debian:8.11). 59 | - id: olmcl 60 | name: Operator Capability Level 61 | type: string 62 | description: | 63 | [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) indicates the operator maturity 64 | levels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability models 65 | aims to provide guidance in terminology to express what features users can expect from an operator. 66 | vendor_compliance: | 67 | Capability level must be set to one of the following levels: 68 | 69 | 1. `Basic Install` 70 | 2. `Seamless Upgrades` 71 | 3. `Full Lifecycle` 72 | 4. `Deep Insights` 73 | 5. `Auto Pilot` 74 | 75 | A link should be provided with documentation on how the operator fulfil the declared capability level. 76 | 77 | For a detailed description of each capability level refer to the Operator Framework documentation for 78 | [Operator Capability Level](https://sdk.operatorframework.io/docs/overview/operator-capabilities/). 79 | - id: vers 80 | name: Versions 81 | features: 82 | - id: pgver 83 | name: Supported PostgreSQL versions 84 | type: string_array 85 | description: | 86 | Which major (and minor) versions does this version of the operator support. 87 | vendor_compliance: | 88 | Provide a list of every supported major version followed by a list in parenthesis of the minor versions supported for that major version. 89 | E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order. 90 | Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.) 91 | main: true 92 | - id: k8ver 93 | name: Supported Kubernetes versions 94 | type: string_array 95 | description: | 96 | Which Kubernetes versions the operator can be installed into. 97 | vendor_compliance: | 98 | Provide a list of official Kubernetes minor versions numbers, ordered by reverse chronological order. 99 | Use a range of versions, if possible, e.g. '1.26 - 1.23' or '1.22 - 1.19'. 100 | main: true 101 | - id: pgfor 102 | name: PostgreSQL OSS forks 103 | type: string_array 104 | description: | 105 | PostgreSQL forks are considered derived projects that started from PostgreSQL codebase and add different features while maintaining compatibility with PostgreSQL. 106 | Some operators may provide support for some of such forks, alongside with the original PostgreSQL. 107 | vendor_compliance: | 108 | Leave empty if no version other than the original PostgreSQL is supported. Otherwise, provide a list of names and links to the PostgreSQL forks supported. 109 | If non-OSS forks are supported, leave empty but add a link to them in the comments section. 110 | - id: lisu 111 | name: Licensing & Support 112 | features: 113 | - id: ossli 114 | name: Open Source license 115 | type: boolean 116 | description: | 117 | The operator is published, and its source code is made publicly available, under an OSI-approved open source license. 118 | vendor_compliance: | 119 | If true, provide the SPDX identifier(s) of the license. 120 | main: true 121 | - id: fcimg 122 | name: Free container images 123 | type: boolean 124 | description: | 125 | The container images used for the operator's operation are free to distribute and use, not subject to commercial restrictions. 126 | vendor_compliance: | 127 | If false, provide a link with documentation on the usage requisites/restrictions of the container images. 128 | main: true 129 | - id: nenof 130 | name: No enterprise-only features 131 | type: boolean 132 | description: | 133 | All the operator's features are provided as open source. 134 | No derived, proprietary (often called 'enterprise') versions exist with additional, non open source features. 135 | vendor_compliance: | 136 | If false, provide links to all known derived, proprietary versions. 137 | Linked documentation should clearly reflect the features that are only part of proprietary versions. 138 | - id: comms 139 | name: Commercial support 140 | type: boolean 141 | description: | 142 | Vendor and/or other entities offer paid-for, commercial support for the operator. 143 | vendor_compliance: | 144 | Provide a link or list of links to the entities that provide commercial support. 145 | Links should be as specific as possible, pointing to informative documentation on the provided support. 146 | - id: pubit 147 | name: Public issue tracker 148 | type: boolean 149 | description: | 150 | Development happens in the open. There is a public issue tracker where users may view, comment and create issues. 151 | vendor_compliance: | 152 | Provide a specific link to the issue tracker. 153 | - id: pubch 154 | name: Public chat/forums 155 | type: boolean 156 | description: | 157 | There is/are public forums, mailing lists, chat groups (Slack, Discord, Matrix, etc) where users may freely join and participate in discussions. 158 | vendor_compliance: | 159 | Provide links to all relevant user forums. 160 | - id: pgcl 161 | name: PostgreSQL Clusters 162 | features: 163 | - id: depau 164 | name: Deployment automation 165 | type: boolean 166 | description: | 167 | The operator provides capabilities to automatically deploy production-ready clusters based on a provided configuration. 168 | No user initiated commands must be required. 169 | - id: pomte 170 | name: Pod management technology 171 | type: string 172 | description: | 173 | Which Pod management technology is used to handle database's Pods. E.g. 'StatefulSet', 'Deployment', 'Custom', etc. 174 | vendor_compliance: | 175 | Provide the most succinct possible name of the technology. Use the Kubernetes resource type name (e.g. 'Deployment'), if applicable. 176 | main: true 177 | - id: pgcnf 178 | name: PostgreSQL custom config 179 | type: boolean 180 | description: | 181 | The operator allows the user to supply custom PostgreSQL configuration. 182 | - id: conpl 183 | name: Integrated connection pooling 184 | type: boolean 185 | description: | 186 | The operator provides options to deploy a connection pool in front of the database, automatically deployed and configured. 187 | vendor_compliance: | 188 | The connection pool may be deployed in several ways, like a Deployment layer, a side car, etc. 189 | All should be valid towards this feature as long as they are deployed automatically and offer an entrypoint for the user to the connection pooler. 190 | main: true 191 | - id: cpccf 192 | name: Connection pool custom config 193 | type: boolean 194 | description: | 195 | The operator allows the user to supply a custom connection pool configuration for the connection pool service. 196 | vendor_compliance: | 197 | Only applies if [pgcl/conpl] is true. 198 | - id: tlssp 199 | name: TLS Support 200 | type: boolean 201 | description: | 202 | PostgreSQL connections can be secured with Postgres SSL/TLS support. 203 | main: true 204 | - id: tlscu 205 | name: TLS user-provided certificates 206 | type: boolean 207 | description: | 208 | Operators may chose by default to generate self-signed SSL certificates. 209 | They may also offer the option to specify the CA and certificates that users want Postgres clusters to use. 210 | - id: crtmg 211 | name: CertManager integration 212 | type: boolean 213 | description: | 214 | The operator integrates with CertManager in order to generate the certificate to be used with Postgres. 215 | vendor_compliance: | 216 | Only applies if [pgcl/tlscu] is true. 217 | - id: insql 218 | name: Initialization from SQL scripts 219 | type: boolean 220 | description: | 221 | After the database cluster creation, the operator will run automatically one or more user-supplied scripts for initial DDL or data (possibly limited in size) creation. 222 | The operator must properly inform the user of the execution result of the scripts. 223 | - id: inext 224 | name: Initialization from external source 225 | type: boolean 226 | description: | 227 | After the database cluster creation, the operator will automatically connect to an external data source (like an object storage or a public repo) and fetch the DDL/data. 228 | The operator must properly inform the user of the execution result of the scripts. 229 | - id: cuhba 230 | name: HBA custom config 231 | type: boolean 232 | description: | 233 | The operator allows users to provide custom configuration for the Postgres HBA (Host-Based Authentication) mechanism. 234 | It may involve directly generating the custom `pg_hba.conf` file or by using more cloud-native technologies. 235 | - id: mgmup 236 | name: Management of db users/passwords 237 | type: boolean 238 | description: | 239 | The operator provides a mechanism to declaratively create, modify or delete users, roles and/or password for the PostgreSQL cluster. 240 | - id: reqli 241 | name: Customize computing resource requests, limits 242 | type: boolean 243 | description: | 244 | The user may specify/customize the requests, the limits or both for computing resources (CPU, memory) of the Postgres pods. 245 | main: true 246 | - id: hugpa 247 | name: Support for huge pages 248 | type: boolean 249 | description: | 250 | The user may specify the request to use huge pages for Postgres (and/or potentially other sidecars). 251 | Postgres must be able to be configured and start using huge pages. 252 | main: true 253 | - id: pgsrv 254 | name: PostgreSQL exposed via Service 255 | type: string 256 | description: | 257 | The operator creates by default or allows the user to request one or more Kubernetes Service(s) to be created to expose the PostgreSQL connections. 258 | Expected capabilities should include a RW (read-write) or RO (read-only in case of cascading replication) connection to the primary instance; and, optionally, a RO (read-only) to load balance read-only replicas instances in the cluster. 259 | vendor_compliance: | 260 | The value must be one of: 261 | 262 | * PrimaryAndReplicas: Primary and replicas services must be offered. 263 | * PrimaryAndReplicasAndBalanced: Primary service, replicas services and a service that load balance RW/RO traffic transparently must be offered. 264 | * Balanced: A single service that load balances RW/RO traffic transparently. 265 | * Primary: Primary service must be offered. 266 | - id: stosc 267 | name: Automatic storage scaling 268 | type: boolean 269 | description: | 270 | If the user's selected storage technology supports transparent scaling, the operator will take care of scaling the storage automatically 271 | (either by setting some default thresholds or requiring explicit declarative configuration from the user). 272 | - id: scal0 273 | name: Scale down to zero 274 | type: boolean 275 | description: | 276 | The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed. 277 | Upon scaling up, the cluster should be brought back up without the need to restore a backup. This feature may also be known as "hibernation". 278 | - id: tblsp 279 | name: Tablespaces 280 | type: boolean 281 | description: | 282 | The user may specify one or more PostgreSQL tablespaces and their associated backing storage. 283 | - id: cupgi 284 | name: Custom Postgres images 285 | type: boolean 286 | description: | 287 | The operator allows the user to specify custom (user-provided) Postgres container images, instead of using the operator's provided images. 288 | vendor_compliance: | 289 | The operator should specify if the custom image needs to follow some minimal patterns to be able to work, or if it can work 290 | with any postgres container image provided. 291 | - id: uside 292 | name: User supplied sidecars 293 | type: boolean 294 | description: | 295 | The user may specify custom sidecars (containers or init containers) to be created alongside the Postgres container (and, possibly, other operator sidecars). 296 | User supplied sidecars must be able, by default or by configuration, to access the Postgres container filesystem and Unix Domain Sockets file. 297 | - id: usvol 298 | name: User supplied volumes 299 | type: boolean 300 | description: | 301 | The user may specify and mount custom volumes to be created alongside the volumes created for the Postgres container. 302 | - id: usprt 303 | name: User supplied ports 304 | type: boolean 305 | description: | 306 | The user may specify custom ports to be created alongside the services that expose PostgreSQL. 307 | vendor_compliance: | 308 | Only applies if [pgcl/pgsrv] is set. 309 | - id: srvbi 310 | name: Support for Service Binding 311 | type: boolean 312 | description: | 313 | [Service Binding](https://servicebinding.io/spec/core/1.0.0/) is a Kubernetes specification to "communicating service secrets to workloads in a consistent way". 314 | If the operator supports Service Binding, applications that are bound to the Postgres clusters will be able to fetch database access credentials without requiring 315 | the user to specify them manually in the application. 316 | vendor_compliance: | 317 | The operator must implement the [Provisioned Service](https://servicebinding.io/spec/core/1.0.0/#provisioned-service) part of the specification. 318 | - id: cuann 319 | name: Custom Annotations 320 | type: boolean 321 | description: | 322 | The operator allows the user to provide custom [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) 323 | (aside from any operator generated Annotations) to the objects generated by the operator. 324 | vendor_compliance: | 325 | The operator must provide configuration for setting Annotations on all objects generated by the operator. 326 | Partial compliance is achieved if at least Pods can be annotated and this is clearly marked in the comments. 327 | - id: culab 328 | name: Custom Labels 329 | type: boolean 330 | description: | 331 | The operator allows the user to provide custom [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to the objects generated by the operator. 332 | vendor_compliance: | 333 | The operator must provide configuration for setting Labels on all objects generated by the operator. 334 | Partial compliance is achieved if at Labels can be added to at least Pods and this is clearly marked in the comments. 335 | - id: apdnd 336 | name: Assign Pod to Node 337 | type: string 338 | description: | 339 | The operator allows Postgres Pods to be assigned to a specific set of Nodes based on some [Kubernetes known rules](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/). E.g. Node Labels, Affinity, etc. 340 | vendor_compliance: | 341 | Indicate one of the following values: 342 | 343 | * 'Complete': if the operator support all the rules to assign a Pod to a Node defined in the latest Kubernetes version specified under [vers/k8ver]. 344 | * 'Partial': if the operator support only partially the rules to assign a Pod to a Node. 345 | 346 | A link for each supported rule or rules group to assign a Pod to a Node must be specified. 347 | - id: topsc 348 | name: Topology Spread Constraints 349 | type: boolean 350 | description: | 351 | The operator allows Postgres pods to specify [Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints), 352 | to control how Pods are spread across the Kubernetes cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. 353 | - id: harp 354 | name: HA & Replication 355 | features: 356 | - id: autfa 357 | name: Automated failover 358 | type: boolean 359 | description: | 360 | The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected, 361 | another Postgres instance (if available) will be promoted to primary. The operation must happen automatically without user intervention. 362 | main: true 363 | - id: techa 364 | name: HA Technology 365 | type: string 366 | description: | 367 | The technology (software name or technology principles) that support the high availability and automated failover capabilities of the operator. 368 | vendor_compliance: | 369 | Provide a succinct software or technology name. E.g.: Patroni, Stolon, Custom. 370 | main: true 371 | - id: asrep 372 | name: Asynchronous replication 373 | type: boolean 374 | description: | 375 | The operator allows to configure Postgres clusters using asynchronous streaming replication. 376 | Asynchronous is the default streaming replication mode in Postgres. 377 | - id: syrep 378 | name: Synchronous replication 379 | type: boolean 380 | description: | 381 | The operator allows to configure Postgres clusters using synchronous streaming replication. 382 | The operator must manage the configuration details based on the user's preferences on which nodes behave synchronously. 383 | - id: serep 384 | name: Semi-synchronous replication 385 | type: boolean 386 | description: | 387 | Semi-synchronous, or also called group or quorum replication, is a hybrid mode where a subset of the nodes is expected to replicate synchronously; 388 | and once that level is reached, the remainding nodes replicate asynchronously. 389 | That is, Postgres waits for confirmation of the write only from the synchronous nodes before considering the transaction committed. 390 | - id: derep 391 | name: Delayed replicas 392 | type: boolean 393 | description: | 394 | The operator allows the user to configure one or more replicas subject to a user-specified (intentional) replication lag. 395 | This is useful to have always an online instance with data "in the past" for analytics or data recovery purposes. 396 | - id: carep 397 | name: Cascading replication 398 | type: boolean 399 | description: | 400 | Postgres allows to create replicas that are fed from another replica, instead of replicating from the primary instance. 401 | This is interesting to alleviate the effects of replication on the primary; and allows to create arbitrary replication tree-like topologies. 402 | - id: exrep 403 | name: Replication from external origin 404 | type: boolean 405 | description: | 406 | The operator allows a Postgres cluster to be setup in recovery mode while replicating from an external (non-operator managed) Postgres origin. 407 | This allows migrations to the operator using streaming replication. 408 | vendor_compliance: | 409 | To implement the feature, the user should be able to provide arbitrary host, port, username and password (or other means of credential passing) of the origin. 410 | - id: walsh 411 | name: WAL Shipping 412 | type: boolean 413 | description: | 414 | WAL Shipping is a Postgres technique that allows replication via a shared storage mechanism where WAL files produced on the primary node are copied ("shipped") to the replica. 415 | This feature is useful for having replicas for example on DR sites, replicate over global storage object stores and others. 416 | vendor_compliance: | 417 | Implementing the feature implies both generating WAL files to a suitable location; as well as creating clusters that permanently read those WAL files and replicate from them. 418 | - id: prstb 419 | name: Promote standby cluster 420 | type: boolean 421 | description: | 422 | The operator allows the user to promote a standby cluster that is a cluster with primary in recovery mode so that the primary becomes RW. This feature is used in conjunction with [harp/exrep] and/or [harp/walsh] to make GEO-replicated and/or DR (Disaster Recovery) clusters on other regions, where a region is essentially an independent Kubernetes cluster. 423 | vendor_compliance: | 424 | Only applies if [harp/exrep] or [harp/walsh] are true. 425 | The operator must allow to promote a standby clusters replicating either via WAL Shipping and/or streaming replication. 426 | main: true 427 | - id: lorep 428 | name: Managed logical replication 429 | type: boolean 430 | description: | 431 | Postgres supports logical replication as well as streaming replication. It requires some configuration and commands to be run by the user. 432 | This feature represents operator capabilities to perform these operations in a managed way, without the user having to type commands or create configurations directly. 433 | vendor_compliance: | 434 | The operator is considered compliant if it allows the user to provide logical replication without having to setup it directly, just specifying (declarative) preferences. 435 | The operator is still considered compliant if it cannot proceed until certain operations are performed by the users that are dependent on their environment 436 | (e.g. adding PKs, UNIQUEs or REPLICA IDENTITY to the DDL). 437 | - id: pgex 438 | name: PostgreSQL Extensions 439 | features: 440 | - id: extme 441 | name: Extensions distribution mechanism 442 | type: string 443 | description: | 444 | This feature is set to describe how extensions are shipped in a containerized environment. 445 | Typically they are part of the same Postgres container image, but they may also be distributed via other mechanisms. 446 | vendor_compliance: | 447 | Indicate 'built-in' if the extensions come included with the same Postgres container; or a succinct word or few words naming the distribution mechanism. 448 | More details may be provided, if needed, via the links and comments fields. 449 | - id: coext 450 | name: Core/contrib extensions 451 | type: integer 452 | description: | 453 | The number of core+contrib extensions provided by the operator for the latest Postgres version provided by the operator. 454 | vendor_compliance: | 455 | Submission must provide the total number of core+contrib extensions supported for the latest Postgres version provided by the operator. 456 | It should also be provided, when available, a link with a detailed list of those extensions supported (via links field). 457 | main: true 458 | - id: thext 459 | name: Third-party extensions 460 | type: integer 461 | description: | 462 | The number of extensions not included in the Postgres core+contrib (i.e. created by third parties, outside of Postgres repository) for the latest Postgres version provided by the operator. 463 | vendor_compliance: | 464 | Submission must provide the total number of third-party extensions supported for the latest Postgres version provided by the operator. 465 | A link with a detailed list of those extensions supported (via links field) should also be provided, if available. 466 | main: true 467 | - id: byext 468 | name: Bring your own extension 469 | type: boolean 470 | description: | 471 | The operator provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. 472 | vendor_compliance: | 473 | The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism, 474 | if a user builds a local extension, this could be uploaded or included on the postgres container with an automatic copy to all replicas related. 475 | - id: bkup 476 | name: Backups 477 | features: 478 | - id: bktch 479 | name: Backup Technology 480 | type: string 481 | description: | 482 | What technology (pgbasebackup, PgBackRest, WAL-e/g, Barman, custom, etc) is used to support creation and restoration of backups. 483 | vendor_compliance: | 484 | Provide the most succinct possible name of the technology. 485 | main: true 486 | - id: bkdst 487 | name: Backup destinations 488 | type: string_array 489 | description: | 490 | Where backups can be stored (typically this may include object stores, PVs, etc). 491 | vendor_compliance: | 492 | If any of the following technology names apply, use them, and add other names, as needed: 493 | 494 | * PersistentVolume 495 | * NFS 496 | * S3 497 | * GCS 498 | * Azure Blob 499 | * Local file system 500 | - id: autbk 501 | name: Automated backup management 502 | type: boolean 503 | description: | 504 | The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy - often known as retention policies). 505 | vendor_compliance: | 506 | True response for the feature implies both automatic backups and lifecycle management. 507 | If only the former is provided, answer should be false but this capability should be mentioned in the comments field. 508 | main: true 509 | - id: encbk 510 | name: Backups encryption 511 | type: boolean 512 | description: | 513 | Backups can be performed with user-supplied encryption keys. 514 | - id: ptrbk 515 | name: Point In Time Recovery 516 | type: boolean 517 | description: | 518 | The operator provides support for the user to specify a recovery point (in the past) to which a backup should be recovered to 519 | (if unspecified, backup will be recovered in full). 520 | vendor_compliance: | 521 | True response implies that at least time-based recovery is supported. 522 | If the operator also supports PITR by xid and label, clarify in the comments field. 523 | - id: mulbk 524 | name: Multiple backup configurations 525 | type: boolean 526 | description: | 527 | The operator supports managing more than one backup configuration. 528 | This is typically used to store backups on different object stores (for protection purposes) or to send them to different sites. 529 | It may also include different lifecycle policies. 530 | - id: mgmi 531 | name: Management Interfaces 532 | features: 533 | - id: cucol 534 | name: Resource display columns 535 | type: boolean 536 | description: | 537 | Operator-managed objects (CRDs) include specific fields that provide additional information about the Postgres instances. 538 | These fields are shown when querying the Kubernetes resources using tools like `kubectl`. 539 | vendor_compliance: | 540 | In order to be compliant, operators have to provide at least the following information: 541 | 542 | * Replication status (primary/replica/etc) 543 | * Cluster status (healthy/not healthy) 544 | * Postgres major/minor version 545 | * Latest base backup date 546 | * SSL on/off 547 | - id: kbplg 548 | name: kubectl plugin 549 | type: boolean 550 | description: | 551 | The users may download an additional kubectl plugin which provides custom commands to manage the operator. 552 | vendor_compliance: | 553 | If the feature is provided, include a link to the downloadable plugin in the links field. 554 | - id: bagui 555 | name: Basic management GUI 556 | type: boolean 557 | description: | 558 | The operator bundles some GUI (web interface or other) that allows to perform basic operations (e.g. cluster creation) graphically. 559 | main: true 560 | - id: fugui 561 | name: Fully-featured GUI 562 | type: boolean 563 | description: | 564 | The operator bundles a GUI that is fully-featured (that is, in feature-parity with the capabilities provided via the other management interfaces -- typically CRDs). 565 | The GUI may provide additional features that cannot be otherwise provided via text interfaces (e.g. graphical representation of resources or operations). 566 | main: true 567 | - id: urgui 568 | name: GUI users & roles 569 | type: boolean 570 | description: | 571 | The bundled management GUI has authentication and authorization baked in and provides mechanisms to support multiple users and authorize/deny them to perform operations. 572 | vendor_compliance: | 573 | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 574 | Submission should detail in the link and/or comments field how users and roles for the GUI can be managed. 575 | - id: guiss 576 | name: GUI Single-Sign On 577 | type: boolean 578 | description: | 579 | The bundled management GUI supports integration with Single-Sign On (SSO), like OIDC, identity providers (e.g. Google, Github or Twitter login). 580 | vendor_compliance: | 581 | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 582 | - id: cogui 583 | name: GUI database console 584 | type: boolean 585 | description: | 586 | The bundled management GUI includes a console that can connect to any database managed by the operator and send command (e.g. like `psql`). 587 | vendor_compliance: | 588 | Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 589 | - id: o11y 590 | name: Observability 591 | features: 592 | - id: mtech 593 | name: Metrics technology 594 | type: string_array 595 | description: | 596 | If the operator supports extracting metrics from Postgres, define how they are handled, which technology receives and processes them. 597 | 598 | If any of the following technology names apply, use them, and add other names, as needed: 599 | 600 | * Prometheus 601 | * OTEL 602 | * OpenTSDB 603 | * Nagios 604 | * Sensu 605 | vendor_compliance: | 606 | If supported, provide in the comments information about whether the technology is a dependency, is built-in, external, etc. 607 | Provide link(s) to the documentation for further information. 608 | main: true 609 | - id: expme 610 | name: Export metrics 611 | type: boolean 612 | description: | 613 | Regardless of how metrics are processed (e.g. as part of the operator), 614 | this feature is implemented when the operator allows the user to configure sending metrics to external services, like a metrics SaaS. 615 | - id: cudas 616 | name: Custom dashboards 617 | type: boolean 618 | description: | 619 | In order to display the captured Postgres metrics, the operator provides specialized Postgres dashboards for the users. 620 | - id: cuale 621 | name: Custom alerts 622 | type: boolean 623 | description: | 624 | The operator provides bundled specific Postgres alerts to be triggered on the Postgres metrics processed. 625 | E.g. there is an alert for transaction wraparound or for unused replication slots. 626 | - id: exdel 627 | name: Exposed decorated logs 628 | type: boolean 629 | description: | 630 | The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool. 631 | The logs must be decorated with extra metadata in order to provide semantic meaning, including the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries. 632 | There is no need to configure the tool in order to obtain required extra metadata from the logs. 633 | - id: explg 634 | name: Export logs 635 | type: boolean 636 | description: | 637 | The operator allows the user to configure an external sink for the Postgres logs (e.g. a SaaS service). 638 | - id: oo11y 639 | name: Operator Observability 640 | type: boolean 641 | description: | 642 | The operator is itself a source of telemetry data, potentially including metrics, traces and logs, about its own performance. 643 | - id: secy 644 | name: Security 645 | features: 646 | - id: opcsc 647 | name: Operator code security scanning 648 | type: boolean 649 | description: | 650 | The operator code is always scanned for security vulnerabilities. 651 | main: true 652 | - id: imgsc 653 | name: Image scanning 654 | type: boolean 655 | description: | 656 | Operator-provided images are always scanned for security vulnerabilities. 657 | main: true 658 | - id: sigim 659 | name: Signed images 660 | type: boolean 661 | description: | 662 | Container images are digitally signed according to the [sigstore](https://www.sigstore.dev/) project. 663 | vendor_compliance: | 664 | Compliance may also be achieved by using a technology other than sigstore, as long as it provides an equivalent set of security capabilities. 665 | - id: isbom 666 | name: Software Bill of Materials 667 | type: boolean 668 | description: | 669 | The operator releases include the SBOM (Software Bill of Materials), a detailed description of all the components, modules, and their dependencies. 670 | vendor_compliance: | 671 | SBOM is expected to be in accordance to the [Kubernetes SIG BOM](https://github.com/kubernetes-sigs/bom). 672 | - id: fgopp 673 | name: Fine-grained RBAC permissions 674 | type: boolean 675 | description: | 676 | The operator uses a separate serviceaccount that has RBAC permissions that only require the access that is actually needed to create and manage the Kubernetes resources, not more. 677 | - id: noprm 678 | name: No or justified privileged mode 679 | type: boolean 680 | description: | 681 | The operator-provided containers do not require privileged mode. 682 | The container processes do not run as root. 683 | vendor_compliance: | 684 | Reasonable exceptions to this rule can be made for features that require or do not diminish the container's security, e.g. when using eBPF. 685 | - id: day2 686 | name: Day 2 Operations 687 | features: 688 | - id: amiup 689 | name: Automated minor upgrades 690 | type: boolean 691 | description: | 692 | The operator can perform a minor version upgrade of a Postgres cluster automatically. 693 | This operation can be managed by the user declaratively. 694 | vendor_compliance: | 695 | The operator must provide proper information to the user as to the status and final result of the operation. 696 | The operator should provide ongoing status information, and perform the operation with the minimum downtime required. 697 | Provide information about the update strategy (i.e. restart of the pods or rolling update followed by a switchover or a restart). 698 | main: true 699 | - id: amaup 700 | name: Automated major upgrades 701 | type: boolean 702 | description: | 703 | The operator can perform a major version upgrade of a Postgres cluster automatically. 704 | This operation can be managed by the user declaratively. 705 | vendor_compliance: | 706 | The operator must provide proper information to the user as to the status and final result of the operation. 707 | The operator should provide ongoing status information, and perform the operation with the minimum downtime required. 708 | main: true 709 | - id: crest 710 | name: Controlled cluster restart 711 | type: boolean 712 | description: | 713 | Sometimes Postgres needs to be restarted (e.g. changing of a parameter that requires restart). 714 | The operator provides means to perform this operation automatically and in a controlled manner (rolling restart) so that the cluster faces a minimal downtime only. 715 | - id: ociup 716 | name: Container images upgrade 717 | type: boolean 718 | description: | 719 | Similarly to the controlled restart operation, the operator is capable of updating the running container images (which require a pod restart) automatically and with minimal cluster impact. 720 | - id: swtch 721 | name: Switchover 722 | type: boolean 723 | description: | 724 | If HA capabilities are provided, the operator also provides a mechanism for manual switchover. 725 | The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, by demoting the current primary, promoting the a replica, and updating the endpoints/services as required. 726 | - id: sqlmi 727 | name: SQL Migrations 728 | type: boolean 729 | description: | 730 | The operator provides managed SQL migration capabilities. 731 | The user may specify SQL scripts that contain migrations (DDL changes, etc) to be deployed to a given database, having the operator apply them automatically. 732 | vendor_compliance: | 733 | The operator must report back to the user detailed information about the results of the execution(s) of the script(s) provided by the user. 734 | - id: oday2 735 | name: Other Day 2 Operations 736 | type: string_array 737 | description: | 738 | The operator provides support for other managed Day 2 operations. 739 | vendor_compliance: | 740 | All the mentioned additional day 2 operations need to be possible via declarative configuration and the operator to fully execute them without further user intervention. 741 | - id: dain 742 | name: Data Integration 743 | features: 744 | - id: kfkin 745 | name: Kafka integration 746 | type: boolean 747 | description: | 748 | The operator provides a managed solution for automation to export CDC (Change Data Capture) events to Kafka. 749 | vendor_compliance: | 750 | Kafka could be an external dependency to the operator. 751 | The whole operation is expected to be fully automated, with the user only providing a declarative configuration. 752 | - id: migpg 753 | name: Migration from Postgres 754 | type: string_array 755 | description: | 756 | The operator provides a managed capability to automatically migrate data from another (external) Postgres database. 757 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 758 | which allows for near-zero downtime migrations. 759 | vendor_compliance: | 760 | Provide one or more of the following values: `offline`, `cdc`. 761 | - id: migmy 762 | name: Migration from MySQL 763 | type: string_array 764 | description: | 765 | The operator provides a managed capability to automatically migrate data from a MySQL database. 766 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 767 | which allows for near-zero downtime migrations. 768 | Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 769 | vendor_compliance: | 770 | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 771 | - id: migor 772 | name: Migration from Oracle 773 | type: string_array 774 | description: | 775 | The operator provides a managed capability to automatically migrate data from an Oracle database. 776 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 777 | which allows for near-zero downtime migrations. 778 | Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 779 | vendor_compliance: | 780 | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 781 | - id: migms 782 | name: Migration from SQL Server 783 | type: string_array 784 | description: | 785 | The operator provides a managed capability to automatically migrate data from a SQL Server database. 786 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 787 | which allows for near-zero downtime migrations. 788 | Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 789 | vendor_compliance: | 790 | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 791 | - id: migmo 792 | name: Migration from MongoDB 793 | type: string_array 794 | description: | 795 | The operator provides a managed capability to automatically migrate data from a MongoDB database. 796 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 797 | which allows for near-zero downtime migrations. 798 | Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 799 | vendor_compliance: | 800 | Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 801 | - id: migot 802 | name: Migration from other databases 803 | type: string_array 804 | description: | 805 | The operator provides a managed capability to automatically migrate data from other relational or non-relational databases. 806 | Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture), 807 | which allows for near-zero downtime migrations. 808 | Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 809 | vendor_compliance: | 810 | Provide the names of the other database from where migration is supported. 811 | - id: shrd 812 | name: Sharding 813 | features: 814 | - id: mshrd 815 | name: Managed sharding support 816 | type: boolean 817 | description: | 818 | The operator understands horizontal scalability and is capable to automatically deploying sets of clusters (shards) with their accompanying infrastructure (coordinators, services, etc). 819 | The user should be able to write a declarative configuration of a sharded cluster and the operator to fully deploy it without any further manual user intervention. 820 | main: true 821 | - id: shrdt 822 | name: Sharding technology 823 | type: string_array 824 | description: | 825 | If managed sharding support is provided, which technology or technologies are used to provide sharding support (which is not included in Postgres core). 826 | - id: aggds 827 | name: Aggregated monitoring dashboards 828 | type: boolean 829 | description: | 830 | Since a sharded cluster is a set of (independent) Postgres clusters, an aggregated dashboard is one that provides Observability information across all shards of the cluster. 831 | E.g. total database size, tps processed or total number of client connections. 832 | - id: cobkp 833 | name: Coordinated backups 834 | type: boolean 835 | description: | 836 | A sharded cluster can be backed up by backing up each shard independently, but those backups are not necessarily consistent with each other. 837 | If sharding is used, an additional capability is to coordinate backups on a given timestamp so that they are performed or can be restored at the same logical timestamp, 838 | so they become consistent with each other. 839 | -------------------------------------------------------------------------------- /postgres/spec/yaml2md/README.md: -------------------------------------------------------------------------------- 1 | # README 2 | 3 | In order to export the markdown file containing the table version of the origin YAML, you must have [gomplate](https://github.com/hairyhenderson/gomplate) installed. 4 | 5 | 6 | ## Installing gomplate 7 | 8 | Information on how to install the required command line tool can be found here: [https://docs.gomplate.ca/installing/](https://docs.gomplate.ca/installing/) 9 | 10 | ## Convert yaml to markdown table 11 | 12 | ``` 13 | sh yaml2md.sh 14 | ``` 15 | 16 | ## Notes 17 | 18 | - Make sure that the file `feature_matrix.yaml` is stored on the parent folder before running the script. 19 | - The html file `feature_matrix.md` will be created on the parent folder. 20 | -------------------------------------------------------------------------------- /postgres/spec/yaml2md/yaml2md.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | > ../feature_matrix.md 4 | 5 | if ! command -v gomplate &> /dev/null 6 | then 7 | echo "The required tool \"gomplate\" could not be found. Please make sure to install it and try again." 8 | exit 9 | fi 10 | 11 | gomplate -d fm='../feature_matrix.yaml' -o '../feature_matrix.md' -f 'yaml2md.tmpl' -------------------------------------------------------------------------------- /postgres/spec/yaml2md/yaml2md.tmpl: -------------------------------------------------------------------------------- 1 | {{ range (ds "fm").categories }} 2 | ## {{ .name }} – [{{ .id }}](#{{ .id }}) 3 | | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | 4 | |---|---|---|---|---|---| 5 | {{ range .features }}| {{ .id }} | {{ .name }} | {{ .type }} | {{ if (has . "description") }}{{ .description | strings.Trim "\n" | strings.ReplaceAll "\n" "
" }}{{ end }} | {{ if (has . "vendor_compliance") }}{{ .vendor_compliance | strings.ReplaceAll "\n" "
" }}{{ end }} | {{ if (has . "main") }} ✓ {{ end }} | 6 | {{ end }} 7 | {{ end }} -------------------------------------------------------------------------------- /postgres/vendor-submissions/README.md: -------------------------------------------------------------------------------- 1 | # Postgres OFM Vendor Submission 2 | 3 | This directory contains: 4 | 5 | * [vendor-submission-template.yaml](vendor-submission-template.yaml). This is the file that should be copied as a template to fill in the details of each vendor's submission. Note that this file should not be edited directly, as it is derived from the source [feature matrix](../spec/feature_matrix.yaml). 6 | * [vendor-submission-template-generator](vendor-submission-template-generator). Script and helper file to generate the `vendor-submission-template.yaml` from the source feature matrix. 7 | 8 | 9 | ## Vendor Submission Guidelines 10 | 11 | To produce a vendor submission, please observe the following rules: 12 | * Submissions are tied to a particular release of the vendor's operator. Vendors are expected to produce a new submission for every major release of their operator. If no significant change across operator releases is produced in terms of the features supported, submission may be skipped. The rendering of the vendor's OFM for end users will do a best effort to always show the "latest" version (if semantic versioning or similar versioning style is use) of a given vendor's submissions. It is however preferrable to always submit a version with each operator's release. It is suggested for vendors to treat the YAML file for the submission as another artifact of their release and add it to their standard release procedure. 13 | * Create a pull request against this repository with the submission. The filename for the submission must comply with the following naming format: `postgres/vendor-submissions/${vendor_name_lowercase}/${vendor_name_lowercase}-${ofm_version}-${operator_release_version}.yaml`, and be based on the `vendor-submission-template.yaml` of the given OFM version. 14 | * Observe the indications in the `.vendor_compliance` field of the OFM to determine whether the operator's release is compliant (implements) or not a given feature. 15 | * No bullshit, no marketing. Make objective assessments, and don't include marketing or subjective observations as part of the submission. 16 | 17 | The relevant fields of the submission template are: 18 | * Comments. They are provided as indications for the vendor. They must be left as part of the submission, without removing the comment character. 19 | * `.value`. It is the main value to provide for the feature, and it must be valid according to the `.type` field. Required. 20 | * `.references`. A string array. Ideally, a single string, provide more than one only if strictly necessary. Each reference must be a Markdown-formatted URL. The text part of the URL should be a short or very short text and the location the address of a webpage or section of a webpage that shows or demonstrates the implementation of the given feature. To keep the text short (for readability purposes) either a short version of the title of the documentation's section may be used, or simple words like `Documentation` or `Doc`. This field is not required, but of high value to end users if provided. 21 | * `.comments`. An optional free-form text field for the vendor to provide more detail information about the compliance/non compliance and possible justifications. Please observe the no bullshit and no marketing rules. Comments should be as concise and objective as possible. Markdown formatting may be used. 22 | * Unimplemented features can be left empty; be removed from the submission; or be left unimplemented (setting the `.value` field to `false` for boolean values or empty for every other type) and providing further information in the `.comments` field about why it is not (or partially) implemented. Empty (null) value is therefore treated as "unimplemented". 23 | 24 | -------------------------------------------------------------------------------- /postgres/vendor-submissions/vendor-submission-template-generator/vendor-submission-template-generator.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | > vendor-submission-template.yaml 4 | 5 | if ! command -v gomplate &> /dev/null 6 | then 7 | echo "The required tool \"gomplate\" could not be found. Please make sure to install it and try again." 8 | exit 9 | fi 10 | 11 | gomplate -d fm='../../spec/feature_matrix.yaml' -o '../vendor-submission-template.yaml' -f 'vendor-submission-template-generator.tmpl' 12 | -------------------------------------------------------------------------------- /postgres/vendor-submissions/vendor-submission-template-generator/vendor-submission-template-generator.tmpl: -------------------------------------------------------------------------------- 1 | --- 2 | metadata: 3 | featureMatrixSpecVersion: 4 | submission: 5 | version: 6 | datePublished: 7 | releaseNotes: 8 | operator: 9 | name: 10 | url: 11 | featureMatrix: 12 | categories:{{ range (ds "fm").categories }} 13 | - id: {{ .id }} 14 | # name: {{ .name }}{{ range .features }} 15 | - id: {{ .id }} 16 | # name: {{ .name }} 17 | # type: {{ .type }} 18 | # description: | 19 | # {{ .description | strings.ReplaceAll "\n" "" }}{{ if (has . "vendor_compliance") }}{{ "\n " }}# vendor_compliance: |{{ "\n " }}# {{ .vendor_compliance | strings.TrimSuffix "\n" | strings.ReplaceAll "\n" "\n # " }}{{ end }} 20 | value: 21 | references: 22 | comments:{{ end }} 23 | {{ end }} -------------------------------------------------------------------------------- /postgres/vendor-submissions/vendor-submission-template.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | metadata: 3 | featureMatrixSpecVersion: 4 | submission: 5 | version: 6 | datePublished: 7 | releaseNotes: 8 | operator: 9 | name: 10 | url: 11 | featureMatrix: 12 | categories: 13 | - id: genc 14 | # name: General Characteristics 15 | - id: instm 16 | # name: Installation mechanism 17 | # type: string_array 18 | # description: | 19 | # Mechanism(s) provided to install the operator. 20 | # vendor_compliance: | 21 | # Provide a succinct value or list of values of the mechanisms supported. 22 | # If any of the following names apply, use them, and add other mechanism names, as needed: 23 | # 24 | # * YAML 25 | # * Helm 26 | # * Kustomize 27 | # * Operator Bundle 28 | value: 29 | references: 30 | comments: 31 | - id: mcrds 32 | # name: Management via CRDs 33 | # type: boolean 34 | # description: | 35 | # The operator can be managed via CRDs (Custom Resource Definition). 36 | # vendor_compliance: | 37 | # If true, provide a list of the names of the CRDs supported by the operator. Names should be direct links to their documentation. 38 | value: 39 | references: 40 | comments: 41 | - id: offin 42 | # name: Offline installation 43 | # type: boolean 44 | # description: | 45 | # Whether it is possible to install the operator on a (air-gapped) cluster without internet connection. 46 | # vendor_compliance: | 47 | # A link should be provided with documentation on how to install the operator on air-gapped environments. 48 | value: 49 | references: 50 | comments: 51 | - id: scpua 52 | # name: Supported CPU architectures 53 | # type: string_array 54 | # description: | 55 | # Support for the operator to run on nodes with specified CPU architectures. 56 | # vendor_compliance: | 57 | # Provide a list of CPU architectures that are supported between: 58 | # 59 | # * amd64 60 | # * arm 61 | # * arm64 62 | # * ppc64le 63 | # * s390x 64 | # 65 | # In case you support additional architectures, add their name(s) in a similar fashion. 66 | value: 67 | references: 68 | comments: 69 | - id: coios 70 | # name: Container images OSes 71 | # type: string_array 72 | # description: | 73 | # Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.).Provide the image name without tags (e.g. debian instead of debian:8.11) 74 | value: 75 | references: 76 | comments: 77 | - id: olmcl 78 | # name: Operator Capability Level 79 | # type: string 80 | # description: | 81 | # [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) indicates the operator maturitylevels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability modelsaims to provide guidance in terminology to express what features users can expect from an operator. 82 | # vendor_compliance: | 83 | # Capability level must be set one of the following levels: 84 | # 85 | # 1. `Basic Install` 86 | # 2. `Seamless Upgrades` 87 | # 3. `Full Lifecycle` 88 | # 4. `Deep Insights` 89 | # 5. `Auto Pilot` 90 | # 91 | # A link should be provided with documentation on how the operator fulfil the declared capability level. 92 | # 93 | # For a detailed description of each capability level refer to the Operator Framework documentation for 94 | # [Operator Capability Level](https://sdk.operatorframework.io/docs/overview/operator-capabilities/). 95 | value: 96 | references: 97 | comments: 98 | 99 | - id: vers 100 | # name: Versions 101 | - id: pgver 102 | # name: Supported PostgreSQL versions 103 | # type: string_array 104 | # description: | 105 | # Which major (and minor) versions does this version of the operator support. 106 | # vendor_compliance: | 107 | # Provide a list of every major version supported followed by a list in parenthesis of the minor versions supported for that major version. 108 | # E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order. 109 | # Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.) 110 | value: 111 | references: 112 | comments: 113 | - id: k8ver 114 | # name: Supported Kubernetes versions 115 | # type: string_array 116 | # description: | 117 | # Which Kubernetes versions the operator can be installed into. 118 | # vendor_compliance: | 119 | # Provide a list of official Kubernetes minor versions numbers, ordered by reverse chronological order. 120 | # Use a range of versions, if possible, e.g. '1.26 - 1.23' or '1.22 - 1.19'. 121 | value: 122 | references: 123 | comments: 124 | - id: pgfor 125 | # name: PostgreSQL OSS forks 126 | # type: string_array 127 | # description: | 128 | # PostgreSQL forks are considered derived projects that started from PostgreSQL codebase and add different features while maintaining compatibility with PostgreSQL.Some operators may provide support for some of such forks, alongside with the original PostgreSQL. 129 | # vendor_compliance: | 130 | # Leave empty if no version other than the original PostgreSQL is supported. Otherwise, provide a list of names and links to the PostgreSQL forks supported. 131 | # If non-OSS forks are supported, leave empty but add a link to them in the comments section. 132 | value: 133 | references: 134 | comments: 135 | 136 | - id: lisu 137 | # name: Licensing & Support 138 | - id: ossli 139 | # name: Open Source license 140 | # type: boolean 141 | # description: | 142 | # The operator is published, and its source code is made publicly available, under an OSI-approved open source license. 143 | # vendor_compliance: | 144 | # If true, provide the SPDX identifier(s) of the license. 145 | value: 146 | references: 147 | comments: 148 | - id: fcimg 149 | # name: Free container images 150 | # type: boolean 151 | # description: | 152 | # The container images used for the operator's operation are free to distribute and use, not subject to commercial restrictions. 153 | # vendor_compliance: | 154 | # If false, provide a link with documentation on the usage requisites/restrictions of the container images. 155 | value: 156 | references: 157 | comments: 158 | - id: nenof 159 | # name: No enterprise-only features 160 | # type: boolean 161 | # description: | 162 | # All the operator's features are provided as open source.No derived, proprietary (often called 'enterprise') versions exist with additional, non open source features. 163 | # vendor_compliance: | 164 | # If false, provide links to all known derived, proprietary versions. 165 | # Linked documentation should clearly reflect the features that are only part of proprietary versions. 166 | value: 167 | references: 168 | comments: 169 | - id: comms 170 | # name: Commercial support 171 | # type: boolean 172 | # description: | 173 | # Vendor and/or other entities offer paid-for, commercial support for the operator. 174 | # vendor_compliance: | 175 | # Provide a link or list of links to the entities that provide commercial support. 176 | # Links should be as specific as possible, pointing to informative documentation on the provided support. 177 | value: 178 | references: 179 | comments: 180 | - id: pubit 181 | # name: Public issue tracker 182 | # type: boolean 183 | # description: | 184 | # Development happens in the open. There is a public issue tracker where users may view, comment and create issues. 185 | # vendor_compliance: | 186 | # Provide a specific link to the issue tracker. 187 | value: 188 | references: 189 | comments: 190 | - id: pubch 191 | # name: Public chat/forums 192 | # type: boolean 193 | # description: | 194 | # There is/are public forums, mailing lists, chat groups (Slack, Discord, Matrix, etc) where users may freely join and participate in discussions. 195 | # vendor_compliance: | 196 | # Provide links to all relevant user forums. 197 | value: 198 | references: 199 | comments: 200 | 201 | - id: pgcl 202 | # name: PostgreSQL Clusters 203 | - id: depau 204 | # name: Deployment automation 205 | # type: boolean 206 | # description: | 207 | # The operator provides capabilities to deploy production-ready clusters automatically based on a provided configuration.No user initiated commands must be required. 208 | value: 209 | references: 210 | comments: 211 | - id: pomte 212 | # name: Pod management technology 213 | # type: string 214 | # description: | 215 | # Which Pod management technology is used to handle database's Pods. E.g. 'StatefulSet', 'Deployment', 'Custom', etc. 216 | # vendor_compliance: | 217 | # Provide the most succinct possible name of the technology. Use the Kubernetes resource type name (e.g. 'Deployment'), if applicable. 218 | value: 219 | references: 220 | comments: 221 | - id: pgcnf 222 | # name: PostgreSQL custom config 223 | # type: boolean 224 | # description: | 225 | # The operator allows the user to supply custom PostgreSQL configuration. 226 | value: 227 | references: 228 | comments: 229 | - id: conpl 230 | # name: Integrated connection pooling 231 | # type: boolean 232 | # description: | 233 | # The operator provides options to deploy a connection pool in front of the database, automatically deployed and configured. 234 | # vendor_compliance: | 235 | # The connection pool may be deployed in several ways, like a Deployment layer, a side car, etc. 236 | # All should be valid towards this feature as long as they are deployed automatically and offer an entrypoint for the user to the connection pooler. 237 | value: 238 | references: 239 | comments: 240 | - id: cpccf 241 | # name: Connection pool custom config 242 | # type: boolean 243 | # description: | 244 | # The operator allows the user to supply a custom connection pool configuration for the connection pool service. 245 | # vendor_compliance: | 246 | # Only applies if [pgcl/conpl] is true. 247 | value: 248 | references: 249 | comments: 250 | - id: tlssp 251 | # name: TLS Support 252 | # type: boolean 253 | # description: | 254 | # PostgreSQL connections can be secured with Postgres SSL/TLS support. 255 | value: 256 | references: 257 | comments: 258 | - id: tlscu 259 | # name: TLS user-provided certificates 260 | # type: boolean 261 | # description: | 262 | # Operators may chose by default to generate self-signed SSL certificates.They may also offer the option to specify the CA and certificates that users want Postgres clusters to use. 263 | value: 264 | references: 265 | comments: 266 | - id: crtmg 267 | # name: CertManager integration 268 | # type: boolean 269 | # description: | 270 | # The operator integrates with CertManager in order to generate the certificate to be used with Postgres. 271 | # vendor_compliance: | 272 | # Only applies if [pgcl/tlscu] is true. 273 | value: 274 | references: 275 | comments: 276 | - id: insql 277 | # name: Initialization from SQL scripts 278 | # type: boolean 279 | # description: | 280 | # After the database cluster creation, the operator will run automatically one or more user-supplied scripts for initial DDL or data (possibly limited in size) creation.The operator must properly inform the user of the execution result of the scripts. 281 | value: 282 | references: 283 | comments: 284 | - id: inext 285 | # name: Initialization from external source 286 | # type: boolean 287 | # description: | 288 | # After the database cluster creation, the operator will automatically connect to an external data source (like an object storage or a public repo) and fetch the DDL/data.The operator must properly inform the user of the execution result of the scripts. 289 | value: 290 | references: 291 | comments: 292 | - id: cuhba 293 | # name: HBA custom config 294 | # type: boolean 295 | # description: | 296 | # The operator allows users to provide custom configuration for the Postgres HBA (Host-Based Authentication) mechanism.It may involve directly generating the custom `pg_hba.conf` file or by using more cloud-native technologies. 297 | value: 298 | references: 299 | comments: 300 | - id: mgmup 301 | # name: Management of db users/passwords 302 | # type: boolean 303 | # description: | 304 | # The operator provides a mechanism to declaratively create, modify or delete users, roles and/or password for the PostgreSQL cluster. 305 | value: 306 | references: 307 | comments: 308 | - id: reqli 309 | # name: Customize computing resource requests, limits 310 | # type: boolean 311 | # description: | 312 | # The user may specify/customize the requests, the limits or both for computing resources (CPU, memory) of the Postgres pods. 313 | value: 314 | references: 315 | comments: 316 | - id: hugpa 317 | # name: Support for huge pages 318 | # type: boolean 319 | # description: | 320 | # The user may specify the request to use huge pages for Postgres (and/or potentially other sidecars).Postgres must be able to be configured and start using huge pages. 321 | value: 322 | references: 323 | comments: 324 | - id: pgsrv 325 | # name: PostgreSQL exposed via Service 326 | # type: string 327 | # description: | 328 | # The operator creates by default or allows the user to request one or more Kubernetes Service(s) to be created to expose the PostgreSQL connections.Expected capabilities should include a RW (read-write) or RO (read-only in case of cascading replication) connection to the primary instance; and, optionally, a RO (read-only) to load balance read-only replicas instances in the cluster. 329 | # vendor_compliance: | 330 | # The value must be one of: 331 | # 332 | # * PrimaryAndReplicas: Primary and replicas services must be offered. 333 | # * PrimaryAndReplicasAndBalanced: Primary service, replicas services and a service that load balance RW/RO traffic transparently must be offered. 334 | # * Balanced: A single service that load balances RW/RO traffic transparently. 335 | # * Primary: Primary service must be offered. 336 | value: 337 | references: 338 | comments: 339 | - id: stosc 340 | # name: Automatic storage scaling 341 | # type: boolean 342 | # description: | 343 | # If the user's selected storage technology supports transparent scaling, the operator will take care of scaling the storage automatically(either by setting some default thresholds or requiring explicit declarative configuration from the user). 344 | value: 345 | references: 346 | comments: 347 | - id: scal0 348 | # name: Scale down to zero 349 | # type: boolean 350 | # description: | 351 | # The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed.Upon scaling up, the cluster should be brought back up without the need to restore a backup. 352 | value: 353 | references: 354 | comments: 355 | - id: tblsp 356 | # name: Tablespaces 357 | # type: boolean 358 | # description: | 359 | # The user may specify one or more PostgreSQL tablespaces and their associated backing storage. 360 | value: 361 | references: 362 | comments: 363 | - id: cupgi 364 | # name: Custom Postgres images 365 | # type: boolean 366 | # description: | 367 | # The operator allows the user to specify custom (user-provided) Postgres container images, instead of using the operator's provided images. 368 | # vendor_compliance: | 369 | # The operator should specify if the custom image needs to follow some minimal patterns to be able to work, or if it can work 370 | # with any postgres container image provided. 371 | value: 372 | references: 373 | comments: 374 | - id: uside 375 | # name: User supplied sidecars 376 | # type: boolean 377 | # description: | 378 | # The user may specify custom sidecars (containers or init containers) to be created alongside the Postgres container (and, possibly, other operator sidecars).User supplied sidecars must be able, by default or by configuration, to access the Postgres container filesystem and Unix Domain Sockets file. 379 | value: 380 | references: 381 | comments: 382 | - id: usvol 383 | # name: User supplied volumes 384 | # type: boolean 385 | # description: | 386 | # The user may specify and mount custom volumes to be created alongside the volumes created for the Postgres container. 387 | value: 388 | references: 389 | comments: 390 | - id: usprt 391 | # name: User supplied ports 392 | # type: boolean 393 | # description: | 394 | # The user may specify custom ports to be created alongside the services that expose PostgreSQL. 395 | # vendor_compliance: | 396 | # Only applies if [pgcl/pgsrv] is set. 397 | value: 398 | references: 399 | comments: 400 | - id: srvbi 401 | # name: Support for Service Binding 402 | # type: boolean 403 | # description: | 404 | # [Service Binding](https://servicebinding.io/spec/core/1.0.0/) is a Kubernetes specification to "communicating service secrets to workloads in a consistent way".If the operator supports Service Binding, applications that are bound to the Postgres clusters will be able to fetch database access credentials without requiringthe user to specify them manually in the application. 405 | # vendor_compliance: | 406 | # The operator must implement the [Provisioned Service](https://servicebinding.io/spec/core/1.0.0/#provisioned-service) part of the specification. 407 | value: 408 | references: 409 | comments: 410 | - id: cuann 411 | # name: Custom Annotations 412 | # type: boolean 413 | # description: | 414 | # The operator allows the user to provide custom [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)(aside from any operator generated Annotations) to the objects generated by the operator. 415 | # vendor_compliance: | 416 | # The operator must provide configuration for setting Annotations on all objects generated by the operator. 417 | # Partial compliance is achieved if at least Pods can be annotated and this is clearly marked in the comments. 418 | value: 419 | references: 420 | comments: 421 | - id: culab 422 | # name: Custom Labels 423 | # type: boolean 424 | # description: | 425 | # The operator allows the user to provide custom [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to the objects generated by the operator. 426 | # vendor_compliance: | 427 | # The operator must provide configuration for setting Labels on all objects generated by the operator. 428 | # Partial compliance is achieved if at Labels can be added to at least Pods and this is clearly marked in the comments. 429 | value: 430 | references: 431 | comments: 432 | - id: apdnd 433 | # name: Assign Pod to Node 434 | # type: string 435 | # description: | 436 | # The operator allows Postgres Pods to be assigned to a specific set of Nodes based on some [Kubernetes known rules](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/). E.g. Node Labels, Affinity, etc. 437 | # vendor_compliance: | 438 | # Indicate one of the following values: 439 | # 440 | # * 'Complete': if the operator support all the rules to assign a Pod to a Node defined in the latest Kubernetes version specified under [vers/k8ver]. 441 | # * 'Partial': if the operator support only partially the rules to assign a Pod to a Node. 442 | # 443 | # A link for each supported rule or rules group to assign a Pod to a Node must be specified. 444 | value: 445 | references: 446 | comments: 447 | - id: topsc 448 | # name: Topology Spread Constraints 449 | # type: boolean 450 | # description: | 451 | # The operator allows Postgres pods to specify [Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints),to control how Pods are spread across the Kubernetes cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. 452 | value: 453 | references: 454 | comments: 455 | 456 | - id: harp 457 | # name: HA & Replication 458 | - id: autfa 459 | # name: Automated failover 460 | # type: boolean 461 | # description: | 462 | # The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected,another Postgres pod (if it exists) will be promoted to primary. The operation must happen automatically without user intervention. 463 | value: 464 | references: 465 | comments: 466 | - id: techa 467 | # name: HA Technology 468 | # type: string 469 | # description: | 470 | # The technology (software name or technology principles) that support the high availability and automated failover capabilities of the operator. 471 | # vendor_compliance: | 472 | # Provide a succinct software or technology name. E.g.: Patroni, Stolon, Custom. 473 | value: 474 | references: 475 | comments: 476 | - id: asrep 477 | # name: Asynchronous replication 478 | # type: boolean 479 | # description: | 480 | # The operator allows to configure Postgres clusters using asynchronous streaming replication.Asynchronous is the default streaming replication mode in Postgres. 481 | value: 482 | references: 483 | comments: 484 | - id: syrep 485 | # name: Synchronous replication 486 | # type: boolean 487 | # description: | 488 | # The operator allows to configure Postgres clusters using synchronous streaming replication.The operator must manage the configuration details based on the user's preferences on which nodes behave synchronously. 489 | value: 490 | references: 491 | comments: 492 | - id: serep 493 | # name: Semi-synchronous replication 494 | # type: boolean 495 | # description: | 496 | # Semi-synchronous, or also called group or quorum replication, is a hybrid mode where a subset of the nodes is expected to replicate synchronously;and once that level is reached, the remainding nodes replicate asynchronously.That is, Postgres waits for confirmation of the write only from the synchronous nodes before considering the transaction committed. 497 | value: 498 | references: 499 | comments: 500 | - id: derep 501 | # name: Delayed replicas 502 | # type: boolean 503 | # description: | 504 | # The operator allows the user to configure one or more replicas subject to a user-specified (intentional) replication lag.This is useful to have always an online instance with data "in the past" for analytics or data recovery purposes. 505 | value: 506 | references: 507 | comments: 508 | - id: carep 509 | # name: Cascading replication 510 | # type: boolean 511 | # description: | 512 | # Postgres allows to create replicas that are fed from another replica, instead of replicating from the primary instance.This is interesting to alleviate the effects of replication on the primary; and allows to create arbitrary replication tree-like topologies. 513 | value: 514 | references: 515 | comments: 516 | - id: exrep 517 | # name: Replication from external origin 518 | # type: boolean 519 | # description: | 520 | # The operator allows a Postgres cluster to be setup in recovery mode while replicating from an external (non-operator managed) Postgres origin.This allows migrations to the operator using streaming replication. 521 | # vendor_compliance: | 522 | # To implement the feature, the user should be able to provide arbitrary host, port, username and password (or other means of credential passing) of the origin. 523 | value: 524 | references: 525 | comments: 526 | - id: walsh 527 | # name: WAL Shipping 528 | # type: boolean 529 | # description: | 530 | # WAL Shipping is a Postgres technique that allows replication via a shared storage mechanism where WAL files produced on the primary node are copied ("shipped") to the replica.This feature is useful for having replicas for example on DR sites, replicate over global storage object stores and others. 531 | # vendor_compliance: | 532 | # Implementing the feature implies both generating WAL files to a suitable location; as well as creating clusters that permanently read those WAL files and replicate from them. 533 | value: 534 | references: 535 | comments: 536 | - id: prstb 537 | # name: Promote standby cluster 538 | # type: boolean 539 | # description: | 540 | # The operator allows the user to promote a standby cluster that is a cluster with primary in recovery mode so that the primary becomes RW. This feature is used in conjunction with [harp/exrep] and/or [harp/walsh] to make GEO-replicated and/or DR (Disaster Recovery) clusters on other regions, where a region is essentially an independent Kubernetes cluster. 541 | # vendor_compliance: | 542 | # Only applies if [harp/exrep] or [harp/walsh] are true. 543 | # The operator must allow to promote a standby clusters replicating either via WAL Shipping and/or streaming replication. 544 | value: 545 | references: 546 | comments: 547 | - id: lorep 548 | # name: Managed logical replication 549 | # type: boolean 550 | # description: | 551 | # Postgres supports logical replication as well as streaming replication. It requires some configuration and commands to be run by the user.This feature represents operator capabilities to perform these operations in a managed way, without the user having to type commands or create configurations directly. 552 | # vendor_compliance: | 553 | # The operator is considered compliant if it allows the user to provide logical replication without having to setup it directly, just specifying (declarative) preferences. 554 | # The operator is still considered compliant if it cannot proceed until certain operations are performed by the users that are dependent on their environment 555 | # (e.g. adding PKs, UNIQUEs or REPLICA IDENTITY to the DDL). 556 | value: 557 | references: 558 | comments: 559 | 560 | - id: pgex 561 | # name: PostgreSQL Extensions 562 | - id: extme 563 | # name: Extensions distribution mechanism 564 | # type: string 565 | # description: | 566 | # This feature is set to describe how extensions are shipped in a containerized environment.Typically they are part of the same Postgres container image, but they may also be distributed via other mechanisms. 567 | # vendor_compliance: | 568 | # Indicate 'built-in' if the extensions come included with the same Postgres container; or a succinct word or few words naming the distribution mechanism. 569 | # More details may be provided, if needed, via the links and comments fields. 570 | value: 571 | references: 572 | comments: 573 | - id: coext 574 | # name: Core/contrib extensions 575 | # type: integer 576 | # description: | 577 | # The number of core+contrib extensions provided by the operator for the latest Postgres version provided by the operator. 578 | # vendor_compliance: | 579 | # Submission must provide the total number of core+contrib extensions supported for the latest Postgres version provided by the operator. 580 | # It should also be provided, when available, a link with a detailed list of those extensions supported (via links field). 581 | value: 582 | references: 583 | comments: 584 | - id: thext 585 | # name: Third-party extensions 586 | # type: integer 587 | # description: | 588 | # The number of extensions not included in the Postgres core+contrib (i.e. created by third parties, outside of Postgres repository) for the latest Postgres version provided by the operator. 589 | # vendor_compliance: | 590 | # Submission must provide the total number of third-party extensions supported for the latest Postgres version provided by the operator. 591 | # A link with a detailed list of those extensions supported (via links field) should also be provided, if available. 592 | value: 593 | references: 594 | comments: 595 | - id: byext 596 | # name: Bring your own extension 597 | # type: boolean 598 | # description: | 599 | # The opertor provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. 600 | # vendor_compliance: | 601 | # The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism, 602 | # if a user build a local extension it could be uploaded or included on the postgres container with an automatic copy to all replicas related. 603 | value: 604 | references: 605 | comments: 606 | 607 | - id: bkup 608 | # name: Backups 609 | - id: bktch 610 | # name: Backup Technology 611 | # type: string 612 | # description: | 613 | # What technology (pgbasebackup, PgBackRest, WAL-e/g, Barman, custom, etc) is used to support creation and restoration of backups. 614 | # vendor_compliance: | 615 | # Provide the most succinct possible name of the technology. 616 | value: 617 | references: 618 | comments: 619 | - id: bkdst 620 | # name: Backup destinations 621 | # type: string_array 622 | # description: | 623 | # Where backups can be stored (typically this may include object stores, PVs, etc). 624 | # vendor_compliance: | 625 | # If any of the following technology names apply, use them, and add other names, as needed: 626 | # 627 | # * PersistentVolume 628 | # * NFS 629 | # * S3 630 | # * GCS 631 | # * Azure Blob 632 | # * Local file system 633 | value: 634 | references: 635 | comments: 636 | - id: autbk 637 | # name: Automated backup management 638 | # type: boolean 639 | # description: | 640 | # The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy). 641 | # vendor_compliance: | 642 | # True response for the feature implies both automatic backups and lifecycle management. 643 | # If only the former is provided, answer should be false but this capability should be mentioned in the comments field. 644 | value: 645 | references: 646 | comments: 647 | - id: encbk 648 | # name: Backups encryption 649 | # type: boolean 650 | # description: | 651 | # Backups can be performed with user-supplied encryption keys. 652 | value: 653 | references: 654 | comments: 655 | - id: ptrbk 656 | # name: Point In Time Recovery 657 | # type: boolean 658 | # description: | 659 | # The operator provides support for the user to specify a recovery point (in the past) to which a backup should be recovered to(if unspecified, backup will be recovered in full). 660 | # vendor_compliance: | 661 | # True response implies that at least time-based recovery is supported. 662 | # If the operator also supports PITR by xid and label, clarify in the comments field. 663 | value: 664 | references: 665 | comments: 666 | - id: mulbk 667 | # name: Multiple backup configurations 668 | # type: boolean 669 | # description: | 670 | # The operator supports managing more than one backup configuration.This is typically used to store backups on different object stores (for protection purposes) or to send them to different sites.It may also include different lifecycle policies. 671 | value: 672 | references: 673 | comments: 674 | 675 | - id: mgmi 676 | # name: Management Interfaces 677 | - id: cucol 678 | # name: Resource display columns 679 | # type: boolean 680 | # description: | 681 | # Operator-managed objects (CRDs) include specific fields that provide additional information about the Postgres instances.These fields are shown when querying the Kubernetes resources using tools like `kubectl`. 682 | # vendor_compliance: | 683 | # In order to be compliant, operators have to provide at least the following information: 684 | # 685 | # * Replication status (primary/replica/etc) 686 | # * Cluster status (healthy/not healthy) 687 | # * Postgres major/minor version 688 | # * Latest base backup date 689 | # * SSL on/off 690 | value: 691 | references: 692 | comments: 693 | - id: kbplg 694 | # name: kubectl plugin 695 | # type: boolean 696 | # description: | 697 | # The users may download an additional kubectl plugin which provides custom commands to manage the operator. 698 | # vendor_compliance: | 699 | # If the feature is provided, include a link to the downloadable plugin in the links field. 700 | value: 701 | references: 702 | comments: 703 | - id: bagui 704 | # name: Basic management GUI 705 | # type: boolean 706 | # description: | 707 | # The operator bundles some GUI (web interface or other) that allows to perform basic operations (e.g. cluster creation) graphically. 708 | value: 709 | references: 710 | comments: 711 | - id: fugui 712 | # name: Fully-featured GUI 713 | # type: boolean 714 | # description: | 715 | # The operator bundles a GUI that is fully-featured (that is, in feature-parity with the capabilities provided via the other management interfaces -- typically CRDs).The GUI may provide additional features that cannot be otherwise provided via text interfaces (e.g. graphical representation of resources or operations). 716 | value: 717 | references: 718 | comments: 719 | - id: urgui 720 | # name: GUI users & roles 721 | # type: boolean 722 | # description: | 723 | # The bundled management GUI has authentication and authorization baked in and provides mechanisms to support multiple users and authorize/deny them to perform operations. 724 | # vendor_compliance: | 725 | # Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 726 | # Submission should detail in the link and/or comments field how users and roles for the GUI can be managed. 727 | value: 728 | references: 729 | comments: 730 | - id: guiss 731 | # name: GUI Single-Sign On 732 | # type: boolean 733 | # description: | 734 | # The bundled management GUI supports integration with Single-Sign On (SSO), like OIDC, identity providers (e.g. Google, Github or Twitter login). 735 | # vendor_compliance: | 736 | # Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 737 | value: 738 | references: 739 | comments: 740 | - id: cogui 741 | # name: GUI database console 742 | # type: boolean 743 | # description: | 744 | # The bundled management GUI includes a console that can connect to any database managed by the operator and send command (e.g. like `psql`). 745 | # vendor_compliance: | 746 | # Only applies if [mgmi/bagui] or [mgmi/fugui] are provided. 747 | value: 748 | references: 749 | comments: 750 | 751 | - id: o11y 752 | # name: Observability 753 | - id: mtech 754 | # name: Metrics technology 755 | # type: string_array 756 | # description: | 757 | # If the operator supports extracting metrics from Postgres, how are they handled, which technology receives and process them?If any of the following technology names apply, use them, and add other names, as needed:* Prometheus* OpenTSDB* Nagios* Sensu 758 | # vendor_compliance: | 759 | # If supported, provide in the comments information about whether the technology is a dependency, is built-in, external, etc. 760 | # Provide link(s) to the documentation for further information. 761 | value: 762 | references: 763 | comments: 764 | - id: expme 765 | # name: Export metrics 766 | # type: boolean 767 | # description: | 768 | # Regardless of how metrics are processed (e.g. as part of the operator),this feature is implemented when the operator allows the user to configure sending metrics to external services, like a metrics SaaS. 769 | value: 770 | references: 771 | comments: 772 | - id: cudas 773 | # name: Custom dashboards 774 | # type: boolean 775 | # description: | 776 | # In order to display the captured Postgres metrics, the operator provides specialized Postgres dashboards for the users. 777 | value: 778 | references: 779 | comments: 780 | - id: cuale 781 | # name: Custom alerts 782 | # type: boolean 783 | # description: | 784 | # The operator provides bundled specific Postgres alerts to be triggered on the Postgres metrics processed.E.g. there is an alert for transaction wraparound or for unused replication slots. 785 | value: 786 | references: 787 | comments: 788 | - id: exdel 789 | # name: Exposed decorated logs 790 | # type: boolean 791 | # description: | 792 | # The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool.The logs must be decorated with extra metadata that includes the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries.There is no need to configure the tool in order to obtain required extra metadata from the logs. 793 | value: 794 | references: 795 | comments: 796 | - id: explg 797 | # name: Export logs 798 | # type: boolean 799 | # description: | 800 | # The operator allows the user to configure an external sink for the Postgres logs (e.g. a SaaS service). 801 | value: 802 | references: 803 | comments: 804 | - id: oo11y 805 | # name: Operator Observability 806 | # type: boolean 807 | # description: | 808 | # The operator is itself a source of telemetry data, potentially including metrics, traces and logs, about its own performance. 809 | value: 810 | references: 811 | comments: 812 | 813 | - id: secy 814 | # name: Security 815 | - id: opcsc 816 | # name: Operator code security scanning 817 | # type: boolean 818 | # description: | 819 | # The operator code is always scanned for security vulnerabilities. 820 | value: 821 | references: 822 | comments: 823 | - id: imgsc 824 | # name: Image scanning 825 | # type: boolean 826 | # description: | 827 | # Operator-provided images are always scanned for security vulnerabilities. 828 | value: 829 | references: 830 | comments: 831 | - id: sigim 832 | # name: Signed images 833 | # type: boolean 834 | # description: | 835 | # Container images are digitally signed according to the [sigstore](https://www.sigstore.dev/) project. 836 | # vendor_compliance: | 837 | # Compliance may also be achieved by using a technology other than sigstore, as long as it provides an equivalent set of security capabilities. 838 | value: 839 | references: 840 | comments: 841 | - id: isbom 842 | # name: Software Bill of Materials 843 | # type: boolean 844 | # description: | 845 | # The operator releases include the SBOM (Software Bill of Materials), a detailed description of all the components, modules, and their dependencies. 846 | # vendor_compliance: | 847 | # SBOM is expected to be in accordance to the [Kubernetes SIG BOM](https://github.com/kubernetes-sigs/bom). 848 | value: 849 | references: 850 | comments: 851 | - id: fgopp 852 | # name: Fine-grained RBAC permissions 853 | # type: boolean 854 | # description: | 855 | # The operator uses a separate serviceaccount that has RBAC permissions that only require the access that is actually needed to create and manage the Kubernetes resources, not more. 856 | value: 857 | references: 858 | comments: 859 | - id: noprm 860 | # name: No or justified privileged mode 861 | # type: boolean 862 | # description: | 863 | # The operator-provided containers do not require privileged mode.The container processes do not run as root. 864 | # vendor_compliance: | 865 | # Reasonable exceptions to this rule can be made for features that require or do not diminish the container's security, e.g. when using eBPF. 866 | value: 867 | references: 868 | comments: 869 | 870 | - id: day2 871 | # name: Day 2 Operations 872 | - id: amiup 873 | # name: Automated minor upgrades 874 | # type: boolean 875 | # description: | 876 | # The operator can perform a minor version upgrade of a Postgres cluster automatically.This operation can be managed by the user declaratively. 877 | # vendor_compliance: | 878 | # The operator must provide proper information to the user as to the status and final result of the operation. 879 | # The operator should provide ongoing status information, and perform the operation with the minimum downtime required. 880 | value: 881 | references: 882 | comments: 883 | - id: amaup 884 | # name: Automated major upgrades 885 | # type: boolean 886 | # description: | 887 | # The operator can perform a major version upgrade of a Postgres cluster automatically.This operation can be managed by the user declaratively. 888 | # vendor_compliance: | 889 | # The operator must provide proper information to the user as to the status and final result of the operation. 890 | # The operator should provide ongoing status information, and perform the operation with the minimum downtime required. 891 | value: 892 | references: 893 | comments: 894 | - id: crest 895 | # name: Controlled cluster restart 896 | # type: boolean 897 | # description: | 898 | # Sometimes Postgres needs to be restarted (e.g. changing of a parameter that requires restart).The operator provides means to perform this operation automatically and in a controlled manner (rolling restart) so that the cluster faces a minimal downtime only. 899 | value: 900 | references: 901 | comments: 902 | - id: ociup 903 | # name: Container images upgrade 904 | # type: boolean 905 | # description: | 906 | # Similarly to the controlled restart operation, the operator is capable of updating the running container images (which require a pod restart) automatically and with minimal cluster impact. 907 | value: 908 | references: 909 | comments: 910 | - id: swtch 911 | # name: Switchover 912 | # type: boolean 913 | # description: | 914 | # If HA capabilities are provided, the operator also provides a mechanism for manual switchover.The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, updating the endpoints/services as required. 915 | value: 916 | references: 917 | comments: 918 | - id: sqlmi 919 | # name: SQL Migrations 920 | # type: boolean 921 | # description: | 922 | # The operator provides managed SQL migration capabilities.The user may specify SQL scripts that contain migrations (DDL changes, etc) to be deployed to a given database, having the operator apply them automatically. 923 | # vendor_compliance: | 924 | # The operator must report back to the user detailed information about the results of the execution(s) of the script(s) provided by the user. 925 | value: 926 | references: 927 | comments: 928 | - id: oday2 929 | # name: Other Day 2 Operations 930 | # type: string_array 931 | # description: | 932 | # The operator provides support for other managed Day 2 operations. 933 | # vendor_compliance: | 934 | # All the mentioned additional day 2 operations need to be possible via declarative configuration and the operator to fully execute them without further user intervention. 935 | value: 936 | references: 937 | comments: 938 | 939 | - id: dain 940 | # name: Data Integration 941 | - id: kfkin 942 | # name: Kafka integration 943 | # type: boolean 944 | # description: | 945 | # The operator provides a managed solution for automation to export CDC (Change Data Capture) events to Kafka. 946 | # vendor_compliance: | 947 | # Kafka could be an external dependency to the operator. 948 | # The whole operation is expected to be fully automated, with the user only providing a declarative configuration. 949 | value: 950 | references: 951 | comments: 952 | - id: migpg 953 | # name: Migration from Postgres 954 | # type: string_array 955 | # description: | 956 | # The operator provides a managed capability to automatically migrate data from another (external) Postgres database.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations. 957 | # vendor_compliance: | 958 | # Provide one or more of the following values: `offline`, `cdc`. 959 | value: 960 | references: 961 | comments: 962 | - id: migmy 963 | # name: Migration from MySQL 964 | # type: string_array 965 | # description: | 966 | # The operator provides a managed capability to automatically migrate data from a MySQL database.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations.Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 967 | # vendor_compliance: | 968 | # Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 969 | value: 970 | references: 971 | comments: 972 | - id: migor 973 | # name: Migration from Oracle 974 | # type: string_array 975 | # description: | 976 | # The operator provides a managed capability to automatically migrate data from an Oracle database.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations.Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 977 | # vendor_compliance: | 978 | # Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 979 | value: 980 | references: 981 | comments: 982 | - id: migms 983 | # name: Migration from SQL Server 984 | # type: string_array 985 | # description: | 986 | # The operator provides a managed capability to automatically migrate data from a SQL Server database.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations.Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 987 | # vendor_compliance: | 988 | # Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 989 | value: 990 | references: 991 | comments: 992 | - id: migmo 993 | # name: Migration from MongoDB 994 | # type: string_array 995 | # description: | 996 | # The operator provides a managed capability to automatically migrate data from a MongoDB database.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations.Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 997 | # vendor_compliance: | 998 | # Provide one or more of the following values: `offline`, `cdc`, `schema conversion`. 999 | value: 1000 | references: 1001 | comments: 1002 | - id: migot 1003 | # name: Migration from other databases 1004 | # type: string_array 1005 | # description: | 1006 | # The operator provides a managed capability to automatically migrate data from other relational or non-relational databases.Migrations may be offline (source needs to be disconnected from clients while the migration happens) and/or via CDC (Change Data Capture),which allows for near-zero downtime migrations.Optionally, the operator may provide additional capabilities to convert the schema from the source database into the target Postgres database. 1007 | # vendor_compliance: | 1008 | # Provide the names of the other database from where migration is supported. 1009 | value: 1010 | references: 1011 | comments: 1012 | 1013 | - id: shrd 1014 | # name: Sharding 1015 | - id: mshrd 1016 | # name: Managed sharding support 1017 | # type: boolean 1018 | # description: | 1019 | # The operator understands horizontal scalability and is capable to automatically deploying sets of clusters (shards) with their accompanying infrastructure (coordinators, services, etc).The user should be able to write a declarative configuration of a sharded cluster and the operator to fully deploy it without any further manual user intervention. 1020 | value: 1021 | references: 1022 | comments: 1023 | - id: shrdt 1024 | # name: Sharding technology 1025 | # type: string_array 1026 | # description: | 1027 | # If managed sharding support is provided, which technology or technologies are used to provide sharding support (which is not included in Postgres core). 1028 | value: 1029 | references: 1030 | comments: 1031 | - id: aggds 1032 | # name: Aggregated monitoring dashboards 1033 | # type: boolean 1034 | # description: | 1035 | # Since a sharded cluster is a set of (independent) Postgres clusters, an aggregated dashboard is one that provides Observability information across all shards of the cluster.E.g. total database size, tps processed or total number of client connections. 1036 | value: 1037 | references: 1038 | comments: 1039 | - id: cobkp 1040 | # name: Coordinated backups 1041 | # type: boolean 1042 | # description: | 1043 | # A sharded cluster can be backed up by backing up each shard independently, but those backups are not necessarily consistent with each other.If sharding is used, an additional capability is to coordinate backups on a given timestamp so that they are performed or can be restored at the same logical timestamp,so they become consistent with each other. 1044 | value: 1045 | references: 1046 | comments: 1047 | --------------------------------------------------------------------------------