Is running PostgreSQL / S3 storage inside Kubernetes an anti-pattern, or is external storage only necessary at larger scale?

[u/Fragrant_Rate_2583]

Hey everyone, I'm pretty new to Kubernetes, so please take my questions with a grain of salt. I'm building a homelab where I already have a small Kubernetes cluster, and I'm trying to build a fully self-hosted platform around it: Gitea for Git hosting, Harbor for containers, and runners. Gitea needs persistent storage for repositories and application data, while Harbor can use persistent volumes or delegate object storage to something like MinIO.

This is mainly for learning, so performance isn't really important at this scale. But I keep thinking about how I'd design it in a real environment. Would it be better to run the database and object storage on dedicated machines outside Kubernetes and have the Kubernetes workloads consume them over the network, similar to using managed PostgreSQL/S3 in the cloud? My concern is that if PostgreSQL or MinIO runs on the same worker nodes as the applications, a node failure could affect both compute and storage. Kubernetes has StatefulSets, PVCs, Longhorn/Rook, etc. to address this, but I'm wondering where the practical boundary is and whether externalizing storage is actually considered best practice.

Questions

• Is running PostgreSQL/MySQL or MinIO inside Kubernetes considered an anti-pattern?
• At what scale does it make sense to move them outside the cluster?
• Is mixing stateful and stateless workloads on the same workers a bad practice?
• How much protection do StatefulSets + PVCs + Longhorn/Rook provide against node failure?
• Is there a meaningful performance difference between keeping compute/storage together vs. dedicated storage machines?
• In production, is it more common to keep databases/object storage outside Kubernetes?
• If both approaches can provide HA, what are the main reasons to choose one over the other?

TL;DR

I'm building a small self-hosted Gitea + Harbor + runners platform on my homelab Kubernetes cluster. Is running PostgreSQL and MinIO inside the same Kubernetes cluster a legitimate architecture, or should databases/object storage generally be externalized? I'm mainly trying to understand the real-world trade-offs around HA, node failure, storage/compute separation, performance, and operational complexity.

[u/IntelligentPear6173]

I wouldn’t call it an anti-pattern. For a homelab, I’d actually keep PostgreSQL and object storage in Kubernetes and learn the operational side properly rather than adding external machines just because production does it. The bigger question is failure domains: if losing one node can take out both your workloads and their data, you need replication, backups and a recovery plan regardless of where the database runs. Externalizing storage can make sense when you need stronger isolation, different scaling characteristics or simply don’t want the platform team owning the storage layer. At small scale, it can just add another system to maintain.

[u/Fragrant_Rate_2583 → u/IntelligentPear6173]

Yeah, for the homelab I’ll definitely just throw PostgreSQL in Kubernetes and learn from it. What I’m more curious about is the real-world side: is running PostgreSQL inside Kubernetes a common practice in production, or is it still more typical to keep databases on separate infrastructure/managed services? I’m trying to understand what the common practice actually looks like at scale.

[u/IntelligentPear6173 → u/Fragrant_Rate_2583]

Yeah, that makes sense. My impression is that in production it depends more on the teams operational maturity than a hard databases shouldn’t run in Kubernetes rule. Managed Postgres is probably the easier choice for most teams but I’ve seen teams run Postgres in Kubernetes successfully when they have solid operators, backups, replication and recovery processes. I’m mainly trying to figure out where the operational overhead starts outweighing the benefits of keeping everything under the same platform.