O Comando Do Sistema Gerenciador De Banco De Dados Postgresql

Comandos essenciais para gerenciar o PostgreSQL no sistema

O PostgreSQL é um SGBD relacional que roda como serviço no sistema operacional. Diferente de alguns bancos que exigem configuração complexa de rede desde o início, ele já vem pronto para uso local com authentication via peer no Unix socket. O serviço funciona sob um usuário dedicado — normalmente postgres — e os comandos são divididos entre utilitários de linha de comando e funções SQL nativas. No dia a dia, o comando mais usado não é SQL puro, mas sim psql ou pg_ctl. O primeiro entra no shell interativo. O segundo controla o serviço. Um exemplo real: você pode iniciar o cluster com E depois conectar com

O que muita gente não sabe é que o PostgreSQL armazena os dados em um diretório chamado data directory, e esse caminho precisa existir antes do primeiro start. Se você tentar iniciar sem um cluster inicializado, o serviço falha silenciosamente e volta código 1. A solução é rodar initdb primeiro: Isso cria a estrutura de arquivos, o pg_hba.conf e o postgresql.conf. Sem isso, não há nada para o serviço gerenciar. Depois de conectado, os comandos de criação seguem o padrão SQL padrão, mas com particularidades do PostgreSQL. Criar um banco é simples:

Criar um usuário com permissões específicas: O que diferencia o PostgreSQL de outros SGBDs é o controle granular de permissões em nível de esquema, tabela e até coluna. O comando GRANT funciona de forma diferente dependendo se você está em nível de banco, schema ou objeto individual. Um problema comum que encontrei na prática foi o VACUUM não rodando automaticamente como esperado. Em uma base com alta taxa de UPDATE e DELETE, os dados mortos se acumulam e o disco cresce sem motivo aparente. A solução foi agendar um VACUUM ANALYZE via cron:

Outro comando útil é o pg_stat_activity, que mostra conexões ativas e queries em execução: Isso resolve rapidamente problemas de conexões travadas que parecem impossíveis de identificar olhando apenas para o log do serviço. O PostgreSQL oferece ferramentas dedicadas para backup lógico. O comando pg_dump exporta um banco inteiro para um arquivo SQL ou formato customizado:

O formato -F c é o customizado, que permite restore seletivo de tabelas específicas. Para restaurar: O problema é que pg_dump não captura dados de usuários e roles se você rodar sem a flag --role. Em ambientes multi-tenant onde as roles são parte crítica da arquitetura, perder essa informação no restore causa erro de permissão imediatamente. O arquivo pg_hba.conf controla acesso de rede e autenticação. Uma configuração típica permite acesso local via peer e acesso remoto via md5 ou scram-sha-256:

Mudar esse arquivo exige recarregar a configuração com pg_ctl reload ou o comando SQL SELECT pg_reload_conf(). Sem isso, as alterações só fazem efeito no próximo restart do serviço, o que causa downtime em produção. O PostgreSQL tem um comportamento específico que pode surpreender: ele não suporta ALTER TABLE ADD COLUMN NOT NULL sem reconstruir a tabela inteira em alguns casos. Em tabelas com milhões de linhas, isso pode levar horas e travar outras operações. A solução é adicionar a coluna sem a constraint e depois atualizar os dados existentes. Também não recomendo usar PostgreSQL para workloads puramente transacionais de alta frequência sem tuning adequado. Ele brilha em consultas complexas com JOINs pesados e relatórios analíticos, mas pode ficar lento em INSERTs massivos sequenciais se o WAL não estiver configurado corretamente. Nesse cenário, um banco orientado a INSERT como o MongoDB ou até MySQL com engine MyISAM pode ser mais eficiente.

Comandos úteis de monitoramento

Além do pg_stat_activity, o PostgreSQL oferece extensões como pg_stat_statements que rastream tempo de execução por query. Instalar é simples:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Depois consultar com:

SELECT query, calls, total_exec_time, mean_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Isso mostra as queries mais pesadas em tempo de execução, não apenas as que mais chamam. Uma query que roda 10 vezes mas gasta 5 segundos cada é mais crítica que uma que roda 1000 vezes mas gasta 1 milissegundo.

Gerenciamento de serviços com systemd

Em sistemas modernos com systemd, o PostgreSQL geralmente instala um serviço pronto. Os comandos padrão são:

sudo systemctl status postgresql
sudo systemctl start postgresql
sudo systemctl enable postgresql

O enable garante que o serviço inicie automaticamente no boot. Alguns provedores de nuvem usam unidades personalizadas que carregam configurações de ambiente específicas, então verificar o status com systemctl status postgresql antes de qualquer manutenção evita surpresas.