Very good question!

So your approach is perfectly fine, even though I wouldn't use docker compose for your production environment. The reason being that you will definitely need to rebuild and redeploy your application container multiple times and it's better to decouple it from your database container.

In order to do that, just run something similar to this in your server:

docker run -d \
    --name my_db \
    -p 5432:5432 \
    -e POSTGRES_PASSWORD='mypassword' \
    -e POSTGRES_USER="postgres" \
    -v /var/run/postgresql:/var/run/postgresql \
    --network=mynetwork \ 
    --restart=always \
    postgres

Make sure to define a custom network and to register in it your db container as well as your web container and any other standalone service that you need (for example Redis or Celery)

The advantage of the Digital Ocean databases is that they are fully managed. Meaning that you can use their infrastructure to handle backups, and that it would run on a separate server that you can scale up and down based on need.

If I were you I would start with a PostgreSQL container in your server, making sure to define a volume so that even if your server instance crashes the data will be stored on file and will be there waiting for you when you restart the server and db.

Then as your needs evolve you can migrate your data on a more reliable and flexible system. This can be a Digital Ocean database or AWS RDS or a number of others. DB migrations can be a bit scary but nowadays there are plenty of tools to help you with those too.