Databases

Now that you know all about volumes, you might be thinking, "Awesome! I'll host my CRUD app on Kubernetes and use a volume to store my PostgreSQL database data!".

That's certainly possible, but frankly, it's not always the best idea. For example, the Boot.dev system that powers this website has the following components:

• A web application, currently served by Cloudflare (this could easily be a Kubernetes deployment if we cared to move it)
• Several backend microservices, all running on Kubernetes in Google Cloud
  • Our main JSON CRUD API
  • A Discord bot
  • A service that compiles student's Go code to WASM
  • etc
• A managed PostgreSQL database, hosted by Cloud SQL (GCP)

Why do we do this? Well, Kubernetes isn't always the simplest way to get a job done. We could certainly host a PostgreSQL database on Kubernetes, but it would require a lot of extra work to get it to work well. For example, we'd need to manually build all the configurations to:

• Create a persistent volume
• Handle Postgres version updates
• Set resource limits
• Set up automated backups

For that reason, when I need an SQL database, I typically use a managed service like Cloud SQL or RDS. There are exceptions to that rule, but it's a good rule of thumb.

When Would You Use a Database on Kubernetes?

I have used databases on Kubernetes in the past, but I've usually done it when the deployment wasn't exactly mission-critical. For example, I've deployed Grafana and Prometheus on Kubernetes, and they both have out-of-the-box support for in-cluster databases. I didn't care too much about backups and automatic upgrades for my telemetry data, and I knew the data set was small and static, so it was a good fit.