Melhores Práticas do psql

Hábitos seguros para SQL interativo, clientes GUI e verificações scriptadas contra PostgreSQL de produção.

Como Usar Esta Lista

• Integre todos os engenheiros que tocam dados de produção com as seções A e B primeiro.
• Aplique B e C através de concessões de permissões (roles) - a cultura sozinha falha às 2 da manhã.
• Reaudite trimestralmente quando novas ferramentas de BI ou jump hosts aparecerem.

A - Segurança de Conexão

• Acesso padrão à produção através de réplicas de leitura. A primária é apenas para escritas e migrações controladas.
• Use funções somente leitura (app_ro) para exploração. Sem INSERT/UPDATE/DELETE em caminhos humanos de produção.
• Defina application_name para identificar humanos. PGAPPNAME=psql-alice em perfis de jump box.
• Exija TLS para psql remoto. sslmode=verify-full quando a CA for gerenciável.
• Nunca armazene senhas de produção no histórico do shell. Use ~/.pgpass com permissões 600 ou um CLI de cofre (vault).

B - Disciplina de Consulta

• Sempre use LIMIT em SELECTs exploratórios sem limites. Combine com ORDER BY quando a ordem for importante.
• Habilite \timing para investigações de desempenho. Siga com EXPLAIN em staging antes de ANALYZE em produção.
• Evite SELECT * em tabelas largas em produção. Nomeie colunas explicitamente; linhas JSONB são caras.
• Use BEGIN READ ONLY para exploração multi-statement. Previne escritas acidentais na mesma sessão.
• Defina statement_timeout em funções humanas. 30s-120s é típico para SQL ad-hoc.

C - Scripting e Automação

• Use -v ON_ERROR_STOP=1 em todos os scripts CI psql. Sucesso parcial é pior que falha explícita.
• Prefira \copy em vez de COPY de caminho de servidor para operadores. Menos privilégios de arquivo de superusuário.
• Envolva scripts DDL em transações quando seguro. Conheça exceções: CREATE INDEX CONCURRENTLY não pode.
• Registre o nome do script via PGAPPNAME. Aparece em pg_stat_activity durante testes de fumaça de deploy.
• Controle de versão de todos os scripts SQL não triviais. fix.sql ad-hoc no laptop não é um runbook.

D - Clientes GUI

• Codifique por cores servidores de produção vs staging em pgAdmin/DBeaver. Vermelho/verde ou prefixos de host distintos.
• Desabilite edições de grade com auto-commit em perfis de produção. Funções somente leitura como aplicação de backup.
• Banir conexões de superusuário salvas em laptops. Credenciais de "break-glass" vivem em um cofre com TTL.
• Roteie usuários GUI através das mesmas políticas de timeout que o psql. idle_in_transaction_session_timeout é obrigatório.
• Exporte grandes conjuntos de dados com COPY, não com exportação por clique na GUI. Evite OOM (Out Of Memory) do cliente em erros de um milhão de linhas.

E - Normas da Equipe

• Ensine meta-comandos do psql antes do onboarding apenas GUI. \d, \conninfo, \timing reduzem cliques mágicos.
• Documente versões de clientes aprovadas no onboarding. Discrepâncias de versão principal cliente/servidor quebram dump/restore.
• Revise incidentes após escritas em ambiente errado. Atualize aliases e cores do jump box, não apenas culpe.
• Sanitize dumps antes do restore em desenvolvimento. pg_dump de produção para laptop é um caminho de violação de dados.
• Combine SQL analítico com padrões de revisão de EXPLAIN. Veja a documentação de revisão de consultas para portões de merge.

FAQs

Relacionados

• Noções Básicas de psql - conectar, timing, LIMIT
• pgAdmin & DBeaver - salvaguardas GUI
• Melhores Práticas de Permissões - design de roles

Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.