The discussion revolves around using a PostgreSQL database outside of Docker for a Discourse installation. ylluminate initially notes the absence of a production database in database.yml and seeks guidance on connecting to an external PostgreSQL server. cpradio directs them to a guide on running Discourse with a separate PostgreSQL server. ylluminate confirms it works but highlights a critical issue: data loss when switching databases. Falco advises backing up before and restoring after the change. ylluminate then asks how to back up the Dockerized PostgreSQL instance, questioning whether reinserting the template line in app.yml and rebuilding the app would disrupt the system, seeking clarity on the process and potential downtime.
I’m doing the standard Docker installation of Discourse, however it appears that there are some quirks regarding the database. First, I don’t see any listing for a production database within the config/database.yml (only development, test and profile), but it appears that the Dockerized system is using PostgreSQL.
What is the proper method for directing the standard Dockerized installation to use a PostgreSQL database on another server?
I would start with
Can’t promise it still doesn’t use Docker, but it might get you started on the right track.
Thanks @cpradio this worked out rather well and works with any database (ie, even non-Docker database instances), but there was one major hiccup: It’s not made clear that the process will not transfer the database info over and any existing tables will be effectively lost.
I guess the followup would be: If one were to want to retain the data after moving to a separate database, what’s the process for that?
Take a backup before, restore after.
Yeah, was afraid you’d say that @Falco. 
I guess the question evolves to be: how do you get a backup of the pgsql instance that Discourse is using / how do you get into that instance? ./launcher enter postgres?
So I’ve removed the template line from the app.yml, I guess that means I need to put that back in and then ./launcher rebuild app? Or is there a better way?
And if I do this, does that mean it will try to use the Docker pgsql db again and thus screw the app up temporarily while I have that active?
I guess a kind of complete snapshot of what’s happening there and how to interact with it and what’s to be expected (such as perhaps the new external db no longer being used temporarily while recovering the Dockerized pgsql instance)…