I'm using Docker Swarm for several stateless services and it has worked well, but I'm struggling with persistent workloads such as PostgreSQL and Redis. Shared NFS volumes become a bottleneck under heavy I/O, while pinning a database to one node with placement constraints seems to create a single point of failure and defeats much of the benefit of orchestration. Is the practical approach to run databases as managed cloud services or on separate infrastructure, or have people successfully used distributed storage such as GlusterFS or Longhorn with Swarm? I'm wondering whether I'm missing a reliable Swarm pattern or simply trying to force the wrong tool to handle stateful workloads.
4 Answers
For serious production databases, I’d keep them outside the Swarm cluster. A separate PostgreSQL setup with solid backups, replication, and monitoring is usually easier to reason about than trying to make shared volumes and node pinning provide database availability. Swarm is excellent for stateless services, but it doesn’t remove the need to design the storage and failover layers yourself.
We run small, disposable Redis instances as single containers because the data can be rebuilt and the workload is limited. PostgreSQL is different: it runs in a dedicated high-availability cluster managed with PostgreSQL-specific tooling such as Patroni. That keeps database failover, replication, and health checks in the system designed for them instead of putting those responsibilities on Swarm.
Patroni is a strong option, but it does add operational work. You still have to manage the cluster coordination layer, backups, upgrades, and failure testing, so it’s worth comparing that cost with a managed PostgreSQL service.
The simplest architecture is to treat databases as external dependencies. Use a managed PostgreSQL or Redis service when possible, or run them on dedicated machines with their own replication, backups, monitoring, and recovery procedures. This also lets the database and application have separate availability targets. Kubernetes operators can provide a more integrated stateful workflow, but they bring considerably more operational complexity, while Swarm remains a reasonable choice for smaller, mostly stateless deployments.
For a small self-hosted environment, Swarm can still be a practical low-overhead choice. I’d just avoid assuming that moving to Kubernetes automatically makes database operations easy; the operator, storage platform, and recovery process still need to be operated correctly.
In theory, Swarm can work with external storage systems through volume plugins and storage interfaces, but the integration is much less turnkey than in Kubernetes. You’ll likely be hand-building the storage integration, handling node recovery yourself, and validating performance and failure behavior under real load. A distributed filesystem may provide redundancy, but it can also add latency and another complex system to operate.
That’s the key distinction: moving or resynchronizing a volume between nodes isn’t the same as providing database high availability. Swarm largely leaves the storage and recovery design to you.
That still leaves the question of high availability. If the separate database host fails, you need replication across multiple machines or you’re accepting downtime. The important part is treating that as a deliberate database architecture decision rather than expecting the scheduler to solve it.