発端

新しく作るK8sベースのWebアプリのDBに、数年前使っていたPostgreSQLのKubernetes OperatorであるCrunchy DataのPGOを使おうと思った
しかし、Crunchy DataのPGOを改めて調べてみると、ソース自体はオープンソースだが、使っているコンテナイメージがオープンソースではなく実質商用利用できないらしいことがわかった参考1 参考2
そこでオープンソースのPostgreSQL向けOperatorを調査して使うべきものを選定した
ざっくりした選定基準は、Cloud Providerにバックアップできるか、カスタマイズ項目が多いか、カスタマイズしやすいか、将来的に使い続けられそうか等

俯瞰調査

下記のオープンソースのPostgreSQL向けOperatorについて調査
- CrunchyData/postgres-operator
- cloudnative-pg/cloudnative-pg
- zalando/postgres-operator
- ongres/stackgres
- percona/percona-postgresql-operator
- sorintlab/stolon
- (kubedb/docs)
上記のプロジェクトの概要（カスタマイズ性やプロジェクトの盛り上がり等）を調査したところ、機能面で優れるCrunchyDataのPGOをforkして作られたPerconaのPostgres Operatorと、CNCFプロジェクト（Sandbox）にリクエストしたCloudNativePGが良さそうに思えた
比較調査の詳細はこちら：KubernetesのPostgreSQL向けOperator比較
CNCFについて

v2.0.0が最新バージョンとの記載があったが、Helmでもソースからでもエラーが出てデプロイできなかった（デフォルト設定でデプロイできるかのみを試した）ので、v1.3.0でテスト（v1.3.0はCrunchy Data PGOの4.7相当）
アプリから使うときはpgBounderというServiceにアクセスすることでDBを利用する
手順と上記の話の詳細：Percona Operator for PostgreSQLを動かしてみる

通常は、Cluster名の後に-r、-ro、-rwがsuffixとしてついたServiceにアクセスすることで、DBを利用する（読み書きしたければ、-rwのServiceを使う）
手順と上記の話の詳細：CloudNativePGを動かしてみる

Crunchy DataのPostgreSQL Operatorの知見を利用できるCrunchy DataのPGOをforkしたPerconaのOperatorは機能的に非常に魅力的
ただし、Crunchy Dataの後追いになる
CloudNativePGは、CNCFにリクエストしたのもあり、将来性にも強力なオープンソースコミュニティになりそう（注目度が高いのか、GithubのStar数の伸びがPerconaを上回る）
PerconaのOperatorが将来的にオープンソースでなくなることはないと思うが、なんともいえないところ
CLoudNativePGのfull-exampleのyamlと、PerconaのOperatorのOptionページを見ると、PerconaのOperatorの方が圧倒的に設定項目数が多いため、PerconaのOperatorの方がカスタマイズ性は高そう
ドキュメントはCloudNativePGの方がわかりやすいのでアーキテクチャをイメージしやすい（PerconaのOperatorのドキュメントはところどころCrunchy Dataへのリンクになっているところがある）
（追記する可能性あり）