I'm comfortable using Swarm for stateless applications, but persistent services such as PostgreSQL and Redis are proving much harder. NFS volumes struggle under heavy I/O, while pinning a database to a particular node with placement constraints seems to turn the setup into a single-node failure point rather than a highly available service.
Is the practical approach to keep databases outside the Swarm cluster, using managed services or dedicated machines? Has anyone had good results running distributed storage such as GlusterFS or Longhorn with Swarm, or does that usually mean fighting the platform? I'd like to understand how others handle backups, failover, and storage performance in production.
4 Answers
I’d keep serious databases outside Swarm. In one setup, PostgreSQL ran on dedicated virtual machines with proper backups, while Swarm handled the stateless application layer. Swarm is convenient for services that can be recreated, but it doesn’t provide the same storage and failover guarantees you need for a critical database. If high availability matters, use replication across separate machines rather than relying on a single pinned container.
Swarm can connect to external storage, and it can use storage interfaces that are also seen in larger orchestration systems, but it doesn’t give you a complete storage control plane. In practice, you have to deploy, operate, and troubleshoot the storage layer yourself. Distributed filesystems may work, but they add another distributed system with their own failure modes and performance costs, so test them under realistic database workloads before depending on them.
Moving to Kubernetes is not automatically the answer. Kubernetes operators can make database deployment more structured, but they do not eliminate the complexity of replication, backups, storage, or recovery. For a small team, a managed database or a separately operated database cluster is often safer and simpler than putting everything inside the application orchestrator.
Treat databases as separate infrastructure whenever possible. A managed PostgreSQL service is usually the simplest way to get backups, replication, failover, and a useful SLA without making the application cluster responsible for storage. Redis can sometimes run as a single container if the data is small or disposable, but anything important should have its own replication and recovery plan.
Patroni is a common option for PostgreSQL high availability, although it does add operational work. The cluster management and failover process need to be monitored just as carefully as the database itself.
That makes sense, but with a dedicated database host, would you accept downtime if the host failed, or run PostgreSQL replication across multiple virtual-machine nodes?