Should I use a Managed Postgres Instance?

I asked myself this question while developing willow.camp and decided to use a managed instance before sharing willow.camp with the world. In this post, I’ll explain my thought process and how it changed as I finished off willow.camp’s blogging features.

Hatching a New App

Once I had a rough version of willow.camp coded up, I wanted to deploy it so that I could test features like subdomains, multiple users (real people, not just me and some database seeds), and eventually custom domains.

I kicked off a new app on hatchbox.io using DigitalOcean. hatchbox wires everything up to deploy a Rails app off the main branch of a GitHub repository. All I needed was a database, so I clicked “PostgreSQL” in hatchbox, so that my Rails app and database would run on the same server. In just a few clicks, willow.camp was up and running with 1 vCPU, 1 GB of RAM, and 25 GB of storage.

Going to Production

Once I had most of the features I wanted, I had to make a decision. What do I do if my server crashes? The environment and data are ephemeral. It is easy enough to get the web app up and running again, but I’d lose all the data in my database.

My requirements for the database were:

1. Automated backups at a minimum in a daily interval. Despite making willow.camp for markdown, I end up saving drafts right in the UI.
2. Access to backups for a limited period. I don’t need much more than two or three days of backups.
3. Preferably, minimal configuration.

I had three options:

1. Take periodic snapshots of the server that I can restore in case of data loss. I didn’t see an automated way to take snapshots, so I dropped this from the list.
2. Mount a storage volume: This would separate the storage from the container on which my app was running. This seemed like an okay option to me but I was also wary of managing a single server with the Rails app and Postgres.
3. Use a managed Postgres instance: This met all my requirements, but it cost a bit more. I waffled on this and decided to go with it in the end.

Why I Chose a Managed Postgres Instance

In the past, I worked on a production app where the app and database were hosted on the same server. It constantly felt like a precarious situation. The database and the app server were competing for resources.

On willow.camp I only have 1 vCPU and 1 GB of RAM. I could upsize my droplet, but then I’d lose sleep over balancing resources between the two fundamental processes that run the app.

willow.camp is a tiny app and can easily run with the Rails app and Database on the same small server. I wouldn’t need to lose sleep over it, but I’d be thinking about it all the time.

I needed peace of mind that the processes would keep running and my data would be safe. Scaling up a single instance to handle the app and database didn’t sound like a fun hobby for me. It certainly wasn’t a fun job when I worked on the production setup like this in the past.

The resources on this instance are ideal for a small Rails app. With 1 vCPU and 1 GB of RAM, I can run 5 Puma threads. My response time is well under 200 milliseconds (often under 100ms), so it’ll be a while before I need to consider another CPU.

Choosing a managed Postgres instance gave me peace of mind that my data was safe, my app server and my database had isolated resources, and I had the flexibility to change the app server without affecting the data. The extra $10 a month simplifies my tiny infrastructure and lets me focus on the fun parts of willow.camp.