basic question about user-/role concept in postgres-databases

Question

I hope this question is specific enough to be allowed and not doomed as opinion-based:

I'm fairly new at administrating postgres databases. My basic approach was to create a new user / role for each real-world user. I thought it would be advantageous for use-cases, where users simultaneously access the same database. However, I realised this has some disadvantages in terms of granting access-right to future tables.

I am now suspecting that my concept (separate user-account for each real-word user ) is not the "usual way". I could imagine, that it is sufficient to have just a generic user / role, and each real-world user uses that same generic role to connect, create, read, write, modify data and tables?

Can postgres handle such a setup just fine even in the case of concurrent read/write-actions? Is this second concept (one user-account for many users) just fine and frequently applied?

Thanks in advance for your help (or for pointing out appropriate www-sources I have missed).

Answer 1

There are basically two choices:

1. Your application does the user and permission management itself. Then it typically has a single “application user” in the database.

2. Your application has per-user or per-group database users and handles user and permission management with database means.

Both solutions are fine. The second solution is maybe less commendable if you have lots of users; also, connection pooling usually works better with the first technique.

If you use database users like in the second solution, you should use NOLOGIN roles (user groups) in PostgreSQL to carry the permissions, and you assign the named users to the groups as appropriate. That way you don't have to GRANT and REVOKE a lot of permissions whenever you add or remove a user or change a user's role in the application.

To answer your question, there are no restrictions on concurrency with different database users.