Why Kubernetes Was a Mistake for My SaaS Business

> the default storage options did not support ReadWriteMany for Block and Object Storage, which were necessary for using my database Postgres.

Postgres does not require ReadWriteMany volumes.

> To better understand this, when I created multiple replicas, the same database could not be accessed by all the replicas. Only one at a time could access the database.

Assuming you mean multiple replicas accessing a single postgres database, this should not be a problem. I can't think of any networked database that prevents multiple clients from concurrently connecting. Postgres even has MVCC to allow multiple concurrent changes to the same record.

The architecture diagram towards the end of your blog post shows multiple subdomains, each with their own database. Each of these should be using their own RWO volume, not a single ReadWriteMany volume; that's a good way to cripple your ability to scale.

CNPG is my preferred way to manage postgres clusters on Kubernetes.

Keep your stateful data out of Kube at all costs. Unless you are enterprise scale and can afford to feed and water a DevOps engineer per cluster.

Obviously title is clickbait - OP basically deployed a whole set of pods including a db and api layer, basically the entire stack, for each new customer. This is difficulty level "nightmare" and not how most people probably use k8s.

This design has its place and I've built variation of this before, the challenges of doing it this way have nothing to do with k8s IMO. In fact k8s makes it considerably easier to implement which I think is true challenge here - it gives you just enough rope to hang yourself.

yes. K8s is fine, but keep your db out of it.

Have you ever used Kubernetes and it was worth it?

Clickbait detected

> I spent 10 days to configuration

Is it K8s some toy for you? May be you have such complains about Oracle RAC too or other complex systems?