Installing PostgreSQL Server

I just cannot succeed to install a postgresql database server in any way, just does not work even using distrobox, please give me some pointers on what to do. Thx.

It is difficult to help if you do not provide what you have tried and what error message you got.


Because PostgreSQL is server Universal Blue (Aurora/Bazzzite/Blufin) recommends to install it using “brew”. Second option is podman:

There is also a docker image.

Don’t use brew or distrobox, use the normal container:

(Note: we don’t include docker desktop but podman desktop is a flatpak and works great for this if you want a gui.)

1 Like

Depends on what you’re trying to do, but for local web development I vote to directly install postgresql with brew, and then run your web server / script / whatever locally to directly talk to it.

Deployment with docker compose and docker, but for local development I prefer to just run things directly and sidestep the build steps, devcontainer messing, etc

1 Like

That is the first thing I have thought when I saw @j0rge answer. It is difficult to understand the intention of your PostgreSQL database. I assued if you want to install it on Aurora desktop machine this is not going to be some production database. Production database should not be installed on desktop PC.

If @Niko assumption is correct, so for some local testing and you can afford to lose data in this database, then I think brew may be simpler to install.

It depends on database intention and how much experience you already have with containers. I also assumed if you are talking about distrobox, then you probably don’t have podman/docker experience. Distrobox is great if you want to expose your host PC home directory to container. For example using some GUI tool that when run can access your host files. This can also be done directly with docker/podman, but it requires more knowledge.

In case of database server, server will be accessed with some TCP port and database server does not need access to host PC.

Why? Benefit of using docker/podman is to have separate environment from other tools. If brew breaks somehow, then your database server does not break… But if data in PostgreSQL are important, then database backup has to be taken care of anyway.

Just wondering when do you recommend brew over podman/docker container? Is it:

  • servers → use podman/docker
  • text based terminal tools → use brew
1 Like

Yes, if something is a service (listens on a port) then the default should be a container. Though some people may prefer brew, we always default to the cloud native way.

You have to manage the data no matter which method you use.

2 Likes

To add to what others have said: You want to use a container. And the best tool to deploy a postgresql server on Bluefin is to use a quadlet which allows you to run a postgres server as a regular user (no root required).

The following is a spontaneous tutorial how to set up a postgres quadlet on Bluefin.

Create the following directory if it doesn’t exist already:

mkdir -p ~/.config/containers/systemd
cd ~/.config/containers/systemd

We will use the latest version of postgres which is postgres 17. Every major version of postgres has a different binary format, which is why you need to be explicit about the version that you use.

You need to create 3 files in the directory:

  • postgres17.container
  • postgres17 .volume
  • postgres17.env

The file postgres17.container should have the following contents:

[Unit]
Description=Postgres 17 server

[Container]
Image=docker.io/library/postgres:17
ContainerName=postgres17
PublishPort=5432:5432
Network=host
Volume=postgres17.volume:/var/lib/postgresql/data:z
EnvironmentFile=postgres17.env

[Install]
RequiredBy=default.target

And the file postgres17.volume should have the following contents:

[Unit]
Description=postgres 17 data

[Volume]
# default options are probably fine

And finally you need to create the file postgres17.env which should contain the password you want to use for the postgres user:

POSTGRES_PASSWORD=mysecretpassword

You can find more useful environment variables in the official docker image docs.

Finally run

systemctl --user daemon-reload
systemctl --user start postgres17

And your container will be available on your local machine listening on port 5432.

To connect to the server you need to use the URL postgres://postgres@localhost. If you only run psql it won’t find the server, because there is no socket on the host to connect to. You can also run

podman exec -itu postgres postgres17 psql

to interact directly with the database in the container.

5 Likes

This thread is wonderful… so many options user can choose from.

I have tried @stego instructions for Quadlets and it is working fine. Very nice. The only issue I have had is after Blufin reboot PostgreSQL service does not automatically starts. I fixed that by adding following line at the end of postgres17.container file:

WantedBy=default.target

and after reboot PostgreSQL service starts up automatically.


Maybe just for “completeness” if someone wants to run SQL commands from host (and not having any other client to access database and that file is not needed to transfer into podman container every time you want to execute multiple commands from file) then PostgreSQL client can be installed using brew:

brew install libpq
brew link --force libpq

Then on your host you can create file e.g. file.txt with for example some SQL commands:

create database testdb;
\c testdb;
create schema schema1;
create table schema1.table1 (col1 int);
insert into schema1.table1 values (1);
select * from schema1.table1;

and execute SQL commands from host file.txt file with PostgreSQL client:
psql -d postgres -h localhost -U postgres -f file.txt

2 Likes

Hey, It’s a really helpful method, and I’ve tried it successfully.

This got me thinking, if quadlet is also useful for automatically starting a podman distrobox at boot.
Because I hate the little delay the first time i need to use an exported binary from a distrobox.

Is it a similar method, or because it’s distrobox it’s not supported?

Quadlets are more low-level than distroboxes, because you have to specify more things yourself. If you run distrobox enter --dry-run some-image you see all the parameters that distrobox configures for you.

I suggest you take a look at podlet. I haven’t used it myself yet, but it should help you create quadlets for the distroboxes that you care about.

1 Like