I'm preparing to launch a website that may generate significant database traffic. I prefer having control over my software and infrastructure, so I'm considering running and scaling the production database with Docker. However, I'm unsure whether that is practical as the database grows or whether I should use a managed cloud service instead. What factors should I consider, and is Docker a reasonable choice for a production database at launch?
4 Answers
For most new production sites, I would keep the application in containers and use a managed database service. Self-hosting can work if you have experienced infrastructure staff and a clear reason to accept the operational burden, but at launch the managed option usually provides better reliability and leaves you more time to focus on the product.
First, estimate the workload before assuming you need database scaling. Your expected traffic, read/write ratio, storage requirements, availability target, and growth rate will determine whether scaling is necessary and what kind is appropriate.
A managed database is usually the safer choice for a launch, especially if you have a small operations team. Services such as managed relational databases can provide automated backups, point-in-time recovery, replication options, patching, monitoring, and easier failover. Running the database in a container is straightforward; operating it reliably through backups, upgrades, storage failures, and incidents is the difficult part.
You can run a database in Docker, but Docker itself does not solve database scaling or reliability. You still need durable storage, backup verification, monitoring, replication, failover, security controls, and a plan for patching and recovery. The host's CPU, memory, storage performance, and network can also become bottlenecks.
That makes sense. I already use a cloud security layer, so I'll look into combining a managed database with a container-based application deployment.