Reasonable database size postgresql@openshift using Percona operator

PostgreSQL Percona Operator for PostgreSQL
1

If I remember correctly I heard, or I read, that the database setup in kubernetes/openshift for big database is not optimal.
I cannot find any documentation about reasonable database size limit.

In other words, does it make sense to have a 5TB postgresql database on kubernetes/openshift deployed by the PerconaOperator.
Does this break the kubernetes concept?
Is there any soft or hard limitation on kubernetes/openshift or caused by the operator itsself?

2

Hi Martin,
Services executed in the Kubernetes cluster are usually associated with something ephemeral and only HA solutions could survive in such conditions, because k8s worker nodes could be added or removed at any moment. In practice databases could work on a dedicated kubernetes cluster with 100% stable workers or on dedicated workers with taints/affinity: Anti-affinity and tolerations - Percona Operator for PostgreSQL . Even if all services provided by k8s will be down, processes are still not killed and the database could continue to work normally.

The second argument against Kubernetes (and generally cloud/VM solutions): In order to provide proper HA and failover we should put data on the network storage, but NAS/SAN makes database performance miserable.
Postgresql automatically restores data from the backup in case of node fault with pgBackrest and Patroni. Thus you may use local NVMe/Flash drives to obtain a maximum performance. XFS or Ext4 filesystems could be directly mounted to the postgresql container. Regardless what happened with kubernetes software, database files still will be on the worker node filesystem. How Postgresql could mount local filesystems? The simplest way is hostpath, but it requires volumes to be managed manually. More reasonable - use local-path-provisioner. More complex (and powerful) solution is OpenEBS: OpenEBS Documentation | OpenEBS Docs . It allows to manage directly attached volumes as disks or filesystems or path on the host.
The big database is not always require high disk fsync rate, in such cases you may use Ceph or SAN (or cloud storages). Do not forget to create proper StorageClasses to dedicate fast volumes to the database.

It still could be required to spawn a replica for your database. In order to do it for a reasonable time I recommend to use fast network (10GbE). With 1GbE network data could be copied for a day.

Disk space:
5TB for the database itself. 30-40% to allow database growth + 1-3GB, 5TB for a local backup (pgBackrest), 5TB+30-40% for reach replica. With 2 replicas 25-30TB is required.

In a standalone HA case the situation will be same/similar for the disk space/filesystems,