In a discussion titled “Accessing Database” under the Installation category, users explore methods to connect to a PostgreSQL database used by Discourse. cmoi initially struggled connecting via Psequel due to incorrect port mapping (“15432:5432”), later correcting it to “5432:5432” cmoi. EricGT suggested downloading a backup from the admin panel (now .sql.gz, previously .tar.gz) and importing it locally into a PostgreSQL instance, which gassim found helpful. However, gassim reported empty tables after importing via pgAdmin, including a missing users table. nat advised checking the dump file size and content, confirming the users table definition exists. EricGT verified the process, showing the dump begins with standard PostgreSQL headers. gassim confirmed the SQL structure matched but still saw empty tables. EricGT admitted unfamiliarity with pgAdmin and recommended ODBC tools instead. Ultimately, gassim resolved the issue by realizing the dump was from an older PostgreSQL version incompatible with their newer client. Kimberly_Haniff also shared an alternative method: opening port 5432 via cloud firewall and connecting via pgAdmin’s SSH tab.
I am trying to access my database via a GUI (Psequel).
I forwarded the port setting from my container as such:
app.yml:
expose:
<standard definitions>
- "15432:5432" # PostgreSQL
Also changed my password as such:
./launcher enter app
su - postgres
psql
ALTER ROLE postgres WITH PASSWORD '<your password>';
And I am unable to access the database. Any suggestions?If you only need a static snap shot of the database then from https://<site>/admin/backups download a backup. It should be a *.tar.gz file and when uncompressed will be a *.sql file. Create a PostgreSQL database on another machine, which could even be your laptop, and then import the *.sql file.
Now you should be able to access the data all you want with any means that can connect to a PostgreSQL database.
I use the above but access the Discourse database in PostgreSQL via ODBC.
HTH
ok good idea.
Actually I figured it out. It runs on port 5432 also in the container.
it should read:
expose:
thanks
Hi Everyone,
I am able to access my postgres db via pgadmin using the following steps:
Let me know if this works for you.
Kind Regards,
Kimberly
@EricGT never thought of it! Thank you!! 
Hey!
I wanted to double check with you please. When I export the dump.sql to a postgresql database, I end up with empty tables. It’s not clear why. Here are the steps that I follow after I download the backup file:
dump.sql fileIt says that everything was successful but when I ‘view data’ in the tables, they are empty.
Additionally, it’s probably how the instance is managed but it seems that the users table is not included as well, but I need that table to know who did what.
Did I miss anything here? Thanks!
What’s the size of the dump.sql? It should be sizeable (a few MB at least). Can you take a look inside the file? e.g.
$ zgrep -i "CREATE TABLE public.users" dump.sql.gz
#output should be
> CREATE TABLE public.users (
If you don’t see this, the dump looks wrong.
Also, if you share your steps on how you are exporting the dump or paste your console output here, we can understand your issue better.
Thank you so much!
6.34 GB !
To download the dump, I followed the steps suggested above by @EricGT:
After that I followed these steps:
And then when I want to view the data, it shows:
Just redid this to check.
gz file e.g. abc-2025-01-23-095947-v20250122131007.sql.gz. On Windows uncompressed the file using 7-zip which created a directory with the same name less the .gz on the end.C:\Users\Groot\Downloads>dir *.sql.gz
01/23/2025 05:04 AM 407,213,170 abc-2025-01-23-095947-v20250122131007.sql.gz
C:\Users\Groot\Downloads>dir *.sql
01/23/2025 05:04 AM <DIR> abc-2025-01-23-095947-v20250122131007.sql
C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>dir
01/23/2025 05:04 AM 1,572,346,154 abc-2025-01-23-095947-v20250122131007.sql
1 File(s) 1,572,346,154 bytes
type <file> /a | more
C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>type "abc-2025-01-23-095947-v20250122131007.sql" /a | more
abc-2025-01-23-095947-v20250122131007.sql
--
-- PostgreSQL database dump
--
-- Dumped from database version 15.8 (Debian 15.8-1.pgdg110+1)
-- Dumped by pg_dump version 15.10 (Debian 15.10-1.pgdg120+1)
-- Started on 2025-01-23 09:59:47 UTC
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
Hopefully this gets you to the point that you can use the SQL file with PGAdmin to import the data.
NB
When I posted about this ~5 years ago, the file downloaded file type was tar.gz it is now sql.gz. The only difference is that now one less uncompressession step is needed.
Hi @EricGT
Thank you so much for your help! I followed all the same steps (with one extra since my file still has tar.gz). I reached the same result with the sql file:
--
-- PostgreSQL database dump
--
.........
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
However, the issue is that when I use PgAdmin to get the data, all the tables are empty and the Users table is just missing.
Thank you so much for all your help! I really appreciate it. It turns out that I was trying to use the latest postgresql version whereas the dump.sql was from a previous version. I discovered this while trying to follow the guide you used. Thank you!