Postgres Setup Options
Postgres is used as the primary database and can be installed directly on the system or run inside Docker. The focus is on understanding configuration rather than installation steps.
Roles, Users, and CLI Access
On Unix-based systems, Postgres creates a system user and a corresponding role. Access is managed through roles, and the psql CLI is used to interact with the database and manage users and databases.
Creating Roles and Databases
A new role with login credentials can be created and assigned ownership of a database. To use psql directly as a system user, a matching Postgres role must exist, or the default Postgres role can be used instead.
Application Authentication
Applications connect using defined credentials, requiring a role with a password. Proper configuration of user, database, host, and port is essential for successful connections.
Running Postgres with Docker
Postgres can be launched in a Docker container by setting environment variables such as the password and mapping ports. This approach simplifies local development and allows quick startup and teardown of database instances.
Development vs Production Considerations
Docker is suitable for development but not recommended for production due to performance and memory considerations. In production, Postgres should be installed directly on a server with controlled access.
Outcome and Next Steps
Both installation methods result in a running Postgres instance ready for application use. The next step is to explore relational database concepts and Postgres design principles.
So we will be using Postgres as our database of choice in this course.
You have two options for installing this.
Basically, 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 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 user.
A system user called Postgres.
And it will also create a role called Postgres.
And this is how Postgres deals with users.
So it's a user, but it's technically called a role.
So 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 applications again on a Unix-based system
is that it looks up the user account and then check 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.
I dash 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 to be me.
Then.
You will be able to jump out completely.
Let's clear this out as a PSQL.
There's you Morten as the user database is going to be Morten as well and then age for local host and then I need to set the password for use of 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 dash L.
Um.
So we can see all the databases.
So this is how you can create a user and a database and then you are you need to provide those credentials.
So you will probably not need to.
To do this often, but you need to create a role in Postgres that has the name of your system user if if you wanna if you want to be able to use the PS code command directly like I do here.
So here I have a role.
Called MPV database called MPV and I can create databases with MPV as owner.
If you do not want to do this, you can.
You can still use the Postgres user or role to manage your databases, and this is typically whenever I want to show you in a second how we can do this with dogger 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 look 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 wanna install Postgres on your system and you wanna just do this with dog instead so you don't have to deal with all the users set up, it is actually quite straightforward, especially for development purposes.
Postgres in dogger is fine.
Don't do it in production.
There are some.
Memory optimizations that Postgres does that doesn't really work that well with with dogger.
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 through 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 dogger installed, and this is probably going to be easier for most use cases.
So we can simply say dogger run after I'm just I'm on version 29.
So assuming you have dogger installed, we say dogger run and then let's give this container a name.
So let's say block.
Yeah.
We call this bleeding edge dev for development and then we want to set a password for the Postgres.
So the dog 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, I 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 5 432 inside of the container.
Again, if you don't have Postgres installed locally, just do 5 4 3 2 5 4 3 2 great.
Then we're just going to say database Postgres, which will grab the latest Postgres tag from dogger dogger hub.
And now.
After it's done downloading.
This might take a second.
Right.
Then we can run dogger 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 didn't say dogger exec.
Dash it and then we say bleeding edge dev psql as the Postgres user.
We are now in the dogger image as the Postgres user and now we can create a database for our application.
So let's say create database bleeding.
It's development.
We create the database and we can simply specify access to this in our AMV 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 that you are pointing to.
But now you have a database running that's in dogger and you can quickly spin it up and kill it again.
So I can just say dogger kill and.
And we can just specify the first free.
Elements of the ID kill it and there's no more dogger database.
Both of these approaches get you to the same place.
Is this 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 dogger is completely up to you.
I think it's probably easier if you are familiar.
With dogger 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.
