O PostgreSQL nao tem entidades separadas de "usuario" e "grupo": existe um unico role universal. A instrucao CREATE ROLE cria tanto a pessoa que faz login quanto o grupo que guarda os privilegios para os demais. A unica diferenca esta nos atributos que voce anexa.
Um role de login e um role de grupo
Um role com o atributo LOGIN pode se conectar ao servidor, que e o que costumamos chamar de "usuario". Um role sem LOGIN nao pode se conectar e geralmente serve como container de privilegios, ou seja, um "grupo".
CREATE ROLE analyst LOGIN PASSWORD 'secret';
CREATE ROLE app_readonly NOLOGIN;
CREATE USER e apenas um sinonimo de CREATE ROLE ... LOGIN. Entao CREATE USER analyst e CREATE ROLE analyst LOGIN fazem exatamente a mesma coisa; nao existe nenhum "tipo de usuario" separado por baixo.
Vamos dar ao grupo acesso de leitura ao nosso esquema:
GRANT SELECT ON users, orders, employees TO app_readonly;
Pertinencia a roles e heranca
Um role passa a ser membro de um grupo com GRANT role TO member. Dai em diante o atributo INHERIT decide tudo: se ele estiver ativo (o padrao), o membro usa automaticamente os privilegios do grupo.
GRANT app_readonly TO analyst;
SELECT country, count(*) FROM users GROUP BY country;
Se o role for criado com NOINHERIT, os privilegios do grupo nao se aplicam automaticamente; voce precisa "vesti-los" de forma explicita com SET ROLE:
CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret';
GRANT app_readonly TO deploy_bot;
SET ROLE app_readonly;
SELECT amount FROM orders WHERE status = 'paid';
RESET ROLE;
Pegadinha: atributos como SUPERUSER, CREATEDB e LOGIN NUNCA sao herdados por pertinencia. Um membro de um grupo superusuario nao se torna superusuario. Apenas os privilegios comuns (SELECT, INSERT e assim por diante) sao herdados, nunca os atributos do role.
Atributos do role
Os atributos definem o que um role pode fazer no nivel de todo o cluster. Os mais comuns:
LOGIN / NOLOGIN controla se o role pode se conectar ao servidor.
SUPERUSER / NOSUPERUSER decide se o role ignora todas as verificacoes de permissao. Distribua com muita parcimonia.
CREATEDB permite ao role criar bancos de dados.
CREATEROLE permite ao role criar e alterar outros roles.
PASSWORD e VALID UNTIL definem a senha e sua data de expiracao.
CREATE ROLE etl_owner LOGIN
CREATEDB
PASSWORD 'secret'
VALID UNTIL '2026-12-31';
Voce pode alterar os atributos depois com ALTER ROLE, que tambem e o jeito pratico de revogar poderes perigosos:
ALTER ROLE analyst CONNECTION LIMIT 5;
ALTER ROLE etl_owner NOCREATEDB;
O modelo de "usuarios e grupos"
Um padrao pratico: crie alguns roles de grupo para conjuntos de privilegios, crie as pessoas como roles de login e conecte-os por pertinencia. Mudar o acesso depois e um unico GRANT / REVOKE, nao editar permissoes tabela a tabela para cada individuo.
CREATE ROLE readers NOLOGIN;
CREATE ROLE writers NOLOGIN;
GRANT SELECT ON users, orders TO readers;
GRANT SELECT, INSERT, UPDATE ON orders TO writers;
GRANT readers TO writers;
CREATE ROLE maria LOGIN PASSWORD 'secret';
CREATE ROLE pavel LOGIN PASSWORD 'secret';
GRANT readers TO maria;
GRANT writers TO pavel;
Quando o Pavel sai da equipe de escrita, voce executa REVOKE writers FROM pavel e o acesso e retirado de todas as tabelas de uma vez.
Diferencas entre os bancos:
- MySQL nao tinha roles antes da 8.0; agora tem
CREATE ROLE e CREATE USER, mas sao comandos distintos, e o role ainda precisa ser ativado com SET ROLE ou SET DEFAULT ROLE.
- ClickHouse suporta
CREATE ROLE, CREATE USER e GRANT, mas o modelo de privilegios e mais plano, sem heranca profunda por cadeias de roles.
A regra base: anexe os privilegios aos grupos, torne as pessoas membros dos grupos e reserve SUPERUSER apenas para os administradores da plataforma.
O PostgreSQL nao tem entidades separadas de "usuario" e "grupo": existe um unico role universal. A instrucao
CREATE ROLEcria tanto a pessoa que faz login quanto o grupo que guarda os privilegios para os demais. A unica diferenca esta nos atributos que voce anexa.Um role de login e um role de grupo
Um role com o atributo
LOGINpode se conectar ao servidor, que e o que costumamos chamar de "usuario". Um role semLOGINnao pode se conectar e geralmente serve como container de privilegios, ou seja, um "grupo".-- a login role: an actual person or service CREATE ROLE analyst LOGIN PASSWORD 'secret'; -- a group role: no login, just holds privileges CREATE ROLE app_readonly NOLOGIN;CREATE USERe apenas um sinonimo deCREATE ROLE ... LOGIN. EntaoCREATE USER analysteCREATE ROLE analyst LOGINfazem exatamente a mesma coisa; nao existe nenhum "tipo de usuario" separado por baixo.Vamos dar ao grupo acesso de leitura ao nosso esquema:
GRANT SELECT ON users, orders, employees TO app_readonly;Pertinencia a roles e heranca
Um role passa a ser membro de um grupo com
GRANT role TO member. Dai em diante o atributoINHERITdecide tudo: se ele estiver ativo (o padrao), o membro usa automaticamente os privilegios do grupo.-- analyst now inherits everything app_readonly can do GRANT app_readonly TO analyst; -- as analyst, this just works thanks to inheritance: SELECT country, count(*) FROM users GROUP BY country;Se o role for criado com
NOINHERIT, os privilegios do grupo nao se aplicam automaticamente; voce precisa "vesti-los" de forma explicita comSET ROLE:CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret'; GRANT app_readonly TO deploy_bot; -- without SET ROLE the SELECT below is denied SET ROLE app_readonly; SELECT amount FROM orders WHERE status = 'paid'; RESET ROLE;Pegadinha: atributos como
SUPERUSER,CREATEDBeLOGINNUNCA sao herdados por pertinencia. Um membro de um grupo superusuario nao se torna superusuario. Apenas os privilegios comuns (SELECT,INSERTe assim por diante) sao herdados, nunca os atributos do role.Atributos do role
Os atributos definem o que um role pode fazer no nivel de todo o cluster. Os mais comuns:
LOGIN/NOLOGINcontrola se o role pode se conectar ao servidor.SUPERUSER/NOSUPERUSERdecide se o role ignora todas as verificacoes de permissao. Distribua com muita parcimonia.CREATEDBpermite ao role criar bancos de dados.CREATEROLEpermite ao role criar e alterar outros roles.PASSWORDeVALID UNTILdefinem a senha e sua data de expiracao.CREATE ROLE etl_owner LOGIN CREATEDB PASSWORD 'secret' VALID UNTIL '2026-12-31';Voce pode alterar os atributos depois com
ALTER ROLE, que tambem e o jeito pratico de revogar poderes perigosos:ALTER ROLE analyst CONNECTION LIMIT 5; ALTER ROLE etl_owner NOCREATEDB;O modelo de "usuarios e grupos"
Um padrao pratico: crie alguns roles de grupo para conjuntos de privilegios, crie as pessoas como roles de login e conecte-os por pertinencia. Mudar o acesso depois e um unico
GRANT/REVOKE, nao editar permissoes tabela a tabela para cada individuo.-- groups by responsibility CREATE ROLE readers NOLOGIN; CREATE ROLE writers NOLOGIN; GRANT SELECT ON users, orders TO readers; GRANT SELECT, INSERT, UPDATE ON orders TO writers; -- writers should also be able to read GRANT readers TO writers; -- people CREATE ROLE maria LOGIN PASSWORD 'secret'; CREATE ROLE pavel LOGIN PASSWORD 'secret'; GRANT readers TO maria; GRANT writers TO pavel;Quando o Pavel sai da equipe de escrita, voce executa
REVOKE writers FROM pavele o acesso e retirado de todas as tabelas de uma vez.Diferencas entre os bancos:
CREATE ROLEeCREATE USER, mas sao comandos distintos, e o role ainda precisa ser ativado comSET ROLEouSET DEFAULT ROLE.CREATE ROLE,CREATE USEReGRANT, mas o modelo de privilegios e mais plano, sem heranca profunda por cadeias de roles.A regra base: anexe os privilegios aos grupos, torne as pessoas membros dos grupos e reserve
SUPERUSERapenas para os administradores da plataforma.