Conventional approach is to have both the master db and app servers at the same Provider and same datacenter. (I.e., super-fast & reliable networking) Then, for extra redundancy, have follower db’s at other providers.

So that’s two VM’s, one provider, one datacenter as the first start. But TBH, if your app is an initial proof of concept and/or not bringing in real traffic and money, you can easily run both on one VM, and get pretty far with that.

At Linode, my db is a managed cluster of 3 VM’s, but it presents itself as a single always-available db. Then, my apps are on the second VM that’s a dedicated-CPU with containers that I manage with Dokku. All the network traffic between the apps and the db is on Linode’s private network, and it’s unmetered. Linode has a nice free Firewall app that I’ve configured. Both VM’s get auto-backups by Linode. Total cost = $100/month.

I haven’t yet found the need for more redundancy.

Finally, though, I’m always trying out new hosting ideas in the background. I’m extremely impressed with fly.io and I’m working on that atm.

So there are two ways to do this

1. Make your postgresql run on a public ip and setup ssl, etc. to ensure it is communicated securely.
2. Setup wireguard as a private vpn between two hosts.

I would recommend that you just run them both on the same machine to be honest. I do believe that running wireguard is probably the better option if you don’t want to use the same machine.

I’m not sure that separating the app from the db will help you avoid a disaster. I think it will make it worse. With this approach you have more possible points of failure (if either DO or Vultr go down, or the connectivity between them goes down, your application will be broken). In addition, it is more complicated to manage and you will have a larger attack surface for hackers as you need to expose Postgres to the internet (or correctly implement a VPN without leaking details).

As @dogweather says, you are better off regularly copying/replicating the db off your main provider onto a secondary provider. If you have the code for the application, having the ability to restore the database onto new infrastructure is the most important thing for basic disaster recovery. You will also need to understand how to deploy the application onto that new infrastructure, update DNS records etc, but there’s no way to reconstruct the system if you lose the database.