Why might a team self-host Qdrant on Kubernetes instead of using Qdrant Cloud, and what responsibility does that create?

Self-hosting can make sense when an organization needs tight control over network topology, data residency, security boundaries, compliance, or infrastructure economics at sustained scale. It can also fit teams that already operate Kubernetes as a mature platform and want Qdrant integrated into their existing operational model.

The cost is that the team becomes responsible for the database lifecycle: provisioning storage, configuring replicas and resources, monitoring health, performing upgrades, testing backups and restores, handling failures, and planning capacity. Kubernetes automates orchestration, but it does not magically make database operations disappear.

I would choose Qdrant Cloud when reducing operational burden and getting managed infrastructure is more valuable than low-level control. I would self-host when compliance or infrastructure requirements justify the additional engineering ownership.

A common misconception is that Kubernetes itself provides database durability. Kubernetes can restart workloads, but durable database behavior depends on correctly designed persistent storage, replication, recovery procedures, and Qdrant configuration.