That's a tricky question. Personally, I find that while reading about something is a good way to gain a vague understanding of how something works, to actually integrate it, I need to actually get a system set up and then just dig around and see how things interact.

What could work is something akin to a Wikipedia dive. Pick a system to set up and make note of as many concepts along the way as you can; For example, setting up a Postgres database involves networking (what does a "listen address" actually mean?), different kinds of authentication (eg. pg_hba md5, trust, and peer authentication options), OS users and database users (easy to get those two confused), among other things. One could also wonder why there's a database superuser, and what makes the system such that using it for application access it is a bad idea?

Then try thinking about potential ways of how all these things could interact to break a system. This can give you a lot of insight into how to secure systems against attackers.

For example, setting up Postgres to not authenticate users is not necessarily detrimental to the overall security of a system if everything is local and single-user, but makes the system extremely weak if any component on the host is exploitable from the outside.

So even if you really don't want to use passwords, you should at the very least use peer authentication where the database allows only specified OS users to connect such that any attacker must at least be able to access the system as one of those users.

Lastly, if you put a non-authenticating system on a network, it should not be surprising that anyone who happens to be able to poke at your network address can just waltz in without resistance. You'll at the very least want strong passwords, possibly with brute force detection to detect people trying to guess credentials. The IPv4 internet is only about 4 billion addresses, and automatically scanning through them for listening services is routine for attackers. :)