Comment by smartbit | Hacker News Reader

Comment by smartbit | Hacker News Reader

Parent Full thread

The whole clue of cloudnative-pg is that it makes supporting Postgres so much easier. My DevOps colleague and I had no experience with running PG at all, studied the backup and replication chapters of Simon Riggs book [0], read the excellent cnpg documentation and deployed Postgres clusters on Lab, Dev & Prod k8s clusters. Production started sept 2022. Not a huge use case, 5TB of data, constant stream of IoT type of data. Continuous backup to Minio on TrueNAS Core. Later we added both a hot-standby and a backup replica in a secondary site for disaster recovery. No production issues like you describe.

Many EDB & 2nd Quadrant have 10+ years experience as core Postgres commiters. I had the pleasure meeting some at Kubecon EU in Amsterdam, friendly Italian & UK Engineers I felt I can trust to make good software. They saw the issues you describe and took a step forward by engineering a proper Kubernetes Operator, introducing it at Kubecon EU 2022 to the public when it reached version 1.5, after they had been running it on their DBaaS production clusters for some time.

Highly recommended. IMHO running Postgres on-prem in most use cases is cheaper than a hosted version. Especially taking into account Schrem 1, 2 & (upcoming) 3 [1].

[0] https://www.packtpub.com/product/postgresql-14-administratio...

[1] https://noyb.eu/en/european-commission-gives-eu-us-data-tran...

> supporting Postgres so much easier.

Easier in the sense that you don't know what it's doing... It's not hard to deploy PostgreSQL and make it do something. Making it do what it needs to do well is a completely different thing. Tools like this one (or any other management tool that comes from outside) aren't helping you to make it easier. To make things easy you need to learn how to do them. They make it easy to waste a ton of resources on things you don't need for the faction of performance you can get.

The OP was complaining it was difficult to maintain Postgres, with late nights. Expensive in human resource costs. You’re now switching to a different topic, from total cost of ownership to resource cost of ownership, not taking into account human operator costs.

EDB argues that human costs of operating an highly available cluster with hot standby etc using cnpg & the abstraction it offers is much lower than without an Kubernetes operator.

Of course a highly skilled and experienced Postgres guru with years of experience can run a highly available cluster on less compute resources. But what happens if that person is not available? On holiday leave, with pension? How many of those gurus would a company need to employ? How many of these self maintained pg clusters can a couple of these gurus maintain?

Not having DBAs, the people with the actual skills to run the databases you need, available when you need them, certainly sounds like a business staffing problem, and not an engineering problem. Why are inexperienced developers managing databases in the first place? Or is this something people think you can just wing and be okay?

Who says ‘inexperienced developers are managing databases’? That is not the use case EDB is advocating with cnpg, EDB offers a Postgres DBaaS for developers.

The README [0] explains that CloudNativePG has been designed by Postgres experts with Kubernetes administrators in mind. Put simply, it leverages Kubernetes by extending its controller and by defining, in a programmatic way, all the actions that a good DBA would normally do when managing a highly available PostgreSQL database cluster.

[0] https://github.com/cloudnative-pg/cloudnative-pg/blob/main/R...

Yeah, I like to call these sorta operators "half-managed". It automates some portion of your playbook.

Reply on news.ycombinator.com