Summary
In this episode, you'll learn how to set up Postgres as your database for the course using two approaches: installing it directly on your system or running it in a Docker container. The tutorial covers creating Postgres roles and databases, understanding how Postgres authentication works with system users, and demonstrates both installation methods step-by-step. Docker is recommended for easier development setup, while direct installation is preferred for production environments.
Transcript
So we will be using Postgres as our database of choice in this course. You have two options for installing this: you can do it directly on your system or you can run it in a Docker container. I just want to show you how to work with Postgres so that you are a bit more familiar with what to do to set up a user, to set up a database and how it works. I will not walk you through how to install it because there's a lot of guides on how to install Postgres, but I want you to be aware of how Postgres works. So after you have installed it, if you choose to install it directly on your system, Postgres, at least on a Unix or Linux-based system, will create a system user called Postgres. It will also create a role called Postgres. And this is how Postgres deals with users - it's a user, but it's technically called a role. The first time, whenever you install Postgres, you will also get access to the CLI right here called PSQL. And if I enter it, having installed Postgres on my system, I jump in and I log in as MBV, because I created a user called MBV. Now, what happens here is that the way that Postgres does authentication on a Unix-based system is that it looks up the user account and then checks if there is a role in a database for that user. When you just install Postgres, you will not have this user. So what you can do is you can use sudo -u and then jump in and log in as Postgres. I need to provide my password here. Try again. And now I'm logged in as Postgres or as the Postgres user on my system. And then I can jump into PSQL. You will see the same here, but you will just get logged directly into Postgres, right? Once we are in here, we can actually go ahead and create a role. So, for example, if I wanted to create a role called, let's say we call it Morten with login, password and just secret here. We create a role. Then I can say create database Morten owner Morten, which will now create the database and set the owner to be me. Then you will be able to jump out completely. Let's clear this out. PSQL -U Morten as the user, database is going to be Morten as well and then -h for localhost and then I need to set the password for user Morten and I believe that was secret. And now we are in as Morten and if we check the database - oh, how do I do that? It's \l. So we can see all the databases. So this is how you can create a user and a database and then you need to provide those credentials. You will probably not need to do this often, but you need to create a role in Postgres that has the name of your system user if you want to be able to use the PSQL command directly like I do here. So here I have a role called MBV, database called MBV and I can create databases with MBV as owner. If you do not want to do this, you can still use the Postgres user or role to manage your databases. This is typically - whenever I want to show you in a second how we can do this with Docker instead - that you will just use the Postgres, that's completely fine. You just need to remember to set a password on the user so that we can actually log in with our application for how we can provide the credentials to our application to log into the database. I hope that makes sense, right? If you don't want to install Postgres on your system and you want to just do this with Docker instead so you don't have to deal with all the user setup, it is actually quite straightforward, especially for development purposes. Postgres in Docker is fine. Don't do it in production. There are some memory optimizations that Postgres does that doesn't really work that well with Docker. So when we go to production, we will install Postgres on our server and then set up everything with the user and then we have a locked - or yeah, we can call it locked because you can only access the database directly on the server. So all of that we will deal with later. So let me just quickly show you how you can run Postgres locally by having Docker installed, and this is probably going to be easier for most use cases. So we can simply say docker run - I'm on version 29, so assuming you have Docker installed - we say docker run and then let's give this container a name. So let's say bleeding-edge-dev for development. And then we want to set a password for the Postgres. So the Docker image uses the Postgres role or user and we need a password before we can access it. Then we need to specify a port and typically if you don't have Postgres installed, you will just do this. But since I have this installed on my system, this port is already in use, so I need to use another one. And what this one does is simply says on port 5341 redirect the request to port 5432 inside of the container. Again, if you don't have Postgres installed locally, just do 5432:5432. Great. Then we're just going to say database Postgres, which will grab the latest Postgres tag from Docker Hub. And now, after it's done downloading - this might take a second - then we can run docker ps and we can see we have a container running here: image Postgres, container ID and the port and we also have a name bleeding-edge-dev. If we say docker exec -it and then we say bleeding-edge-dev psql as the Postgres user, we are now in the Docker image as the Postgres user and now we can create a database for our application. So let's say create database bleeding_edge_development. We create the database and we can simply specify access to this in our env variables. You just need to remember that if you have it on your system, you need to be mindful of the port that you are pointing to. But now you have a database running that's in Docker and you can quickly spin it up and kill it again. So I can just say docker kill and we can just specify the first three elements of the ID, kill it and there's no more Docker database. Both of these approaches get you to the same place: running a Postgres instance with a database that's ready for your application. Whether you want to do this directly on the system or through Docker is completely up to you. I think it's probably easier if you are familiar with Docker to go that route. If not, then install it on the system, create a role that matches your username, create a database and then we are ready to go. All right, in the next episode, we will dive into some relational database concepts and see why Postgres is designed the way it is.