Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which has obviously resulted in some technical debt. The issue you mentioned concerns our decision not to integrate pgBackRest into CNPG's core, as we aimed to develop a pluggable interface (CNPG-I).
As a community, we have decided to support volume snapshot backups and offer the Barman Cloud plugin to ensure we provide the same level of service. Our aim is to encourage other organisations or developers to create plugins for their preferred backup solutions.
Currently, as maintainers of CNPG, we must concentrate on the core capabilities and allow the ecosystem to grow with both community and, potentially, commercial solutions based on CNPG-I.
I don’t agree here. There are operators like the one I’m a maintainer of (CloudnativePG) which works directly with Kubernetes, teaching it how to handle Postgres clusters as a coordinated set of instances. Enormous improvements have been done in the last couple of years, and we are particularly focused in working together with storage groups in Kubernetes to handle database workloads, such as for example declarative support for tablespaces and volume snapshots.
I actually do not understand the point here. And maybe you are not very familiar with the concept of transactions. Backups can only account for committed transactions.
However, we are talking about Postgres, here, not a generic database. PostgreSQL natively provides continuous backup, streaming replication, including synchronous (controlled at transaction level), cascading, and logical. You can easily implement with Postgres, even in Kubernetes with CloudNativePG, architectures with RPO=0 (yes, zero data loss) and low RTO in the same Kubernetes cluster (normally a region), and RPO <= 5 minutes with low RTO across regions. Out of the box, with CloudNativePG, through replica clusters.
We are also now launching native declarative support for Kubernetes Volume Snapshot API in CloudNativePG with the possibility to use incremental/differential backup and recovery to reduce RTO in case of very large databases recovery (like ... dozens of seconds to restore 500GB databases).
So maybe it is time to reconsider some assumptions.
The reason could be the last 4 years of evolution in Kubernetes. Have you heard of DoK Community (Data on Kubernetes)? Might be a good place where to start.
Why not dedicate some worker nodes using taints/tolerations/labels, even on bare metal, with locally attached storage? I wrote this many years ago now but that's the reason why we started CloudNativePG (OpenEBS might not be the answer today, but there are many storage engines now, including topolvm which brings LVM to the game): https://www.2ndquadrant.com/en/blog/local-persistent-volumes...
It is ultimately your choice. I am a big fan of shared nothing architecture for the database. (I am a maintainer of CloudNativePG)
That is why we took the approach to reduce the number of components and integrate everything in Kubernetes, especially with logging (we directly log in JSON to standard output) and the usage of application containers, which enables us to cover the case of troubleshooting via the fencing mechanism (your pods are up, you can access storage, but Postgres is down, giving you the possibility to check even possible data corruption issues).
Also, the status is directly available in Kubernetes, so in our view easier for Kubernetes administrators.
Finally, the source code is open source and directly available for inspection - if you want to understand what is happening.
Back then, we evaluated Crunchy Operator's source code. Being primarily imperative and using an external tool for failover, where the two main reasons we decided to start a new project in 2019 which was entirely declarative and purely based on the Kubernetes API server for cluster status. Such project was released open source last April under the name CloudNativePG and hopefully it will enter the CNCF Sandbox soon (fingers crossed).
Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been running and supporting PostgreSQL in production for 15+ years, creating also another open source software for backups (Barman). In CloudNativePG we have basically translated our recipes into Go code and tests.
Many people believe that databases should not run in Kubernetes. I not only believe the opposite, I believe that running Postgres in Kubernetes represents the best way, potentially, to run Postgres out there.
One clarification about CloudNativePG. It is not EDB's anymore (or EnterpriseDB if you prefer).
EDB is the original creator. The software is now entirely owned by a vendor neutral community, openly governed. We have applied for the CNCF sandbox and waiting for the approval at this stage.
CloudNativePG Maintainer and VP of CloudNative at EDB here.
We decided to go even further with the CloudNativePG operator.
EDB as original creator has decided to donate the intellectual property of the source code to the community, open sourced the existing operator under Apache License 2.0 to apply for the CNCF Sandbox. The project not only includes the operator, but also the PostgreSQL operand images - which can be customized (we provide details on how images should be).
We genuinely welcome other vendors to participate in the community and contribute to the project, including by offering professional services around it. Our multi-year commitment is to become a graduated CNCF project.
That's another good example of why CNCF is important, as in that ecosystem live technologies that are becoming standard for everything related to infrastructure, including monitoring and alerting. Prometheus is an example, Open Telemetry is another one. When you are able to "interface" with one of these components, you've done your integration job.
From a Postgres standpoint, IMO, it is also important the concept of cluster - as that's what applications connect too - the operator hides the underlying complexity of managing the single instances. And .. also important monitoring sets of clusters from an infrastructure management PoV.
Got it. That's an interesting point of view. I think it makes sense in the data workloads, especially in the database one. Consider for example how database workloads are still lagging behind in Kubernetes, and - most importantly - viceversa (Kubernetes is a hard topic IMO for traditional DBAs).
Operators are there to help in both cases, and this is the goal of our CloudNativePG operator.
IMO CNCF represents an opportunity for vendors of the same database engine to converge in a healthy community and provide the best operator for their platform. This is probably the first stage.
The second stage could be to study those operators (of different engines, like Postgres, MySQL, ...) and generalize commonalities in a sort of standard spec. Just an idea. Is this in line with what you are thinking?