Is anyone running KubeBlocks in production, particularly for PostgreSQL? I'm trying to understand how it compares with CloudNativePG in real-world use, especially for upgrades, backups, and long-term reliability. KubeBlocks is appealing because it supports several database engines, while CloudNativePG would mainly cover PostgreSQL. I'm having trouble finding detailed feedback from actual users and would appreciate hearing about production experience, limitations, or reasons to choose one over the other.
3 Answers
CloudNativePG has been very solid for us, but upgrades and backups are the areas I’d investigate most carefully with KubeBlocks. Those are often where database operators show their weaknesses, so production experience there would matter more than just getting the pods running.
One potentially useful feature is that it can manage database and database-role resources, which may fit well with a broader database platform. I haven’t used it in production myself, though, so I’d treat the fact that it can get workloads running as a starting point rather than proof that the operational experience matches CloudNativePG.
The main reason I’m considering KubeBlocks is that we also need support for databases other than PostgreSQL. If its PostgreSQL support, upgrades, and backup workflows are dependable, using one operator could be simpler than adding CloudNativePG just for PostgreSQL. The challenge is finding enough real production feedback, since it doesn’t seem to have a large user base yet.
That broader database support is probably KubeBlocks’ biggest advantage. I’d still validate the PostgreSQL-specific backup and upgrade behavior carefully before standardizing on it.