Checklist de Regras para Projetos Postgres

25 regras de verificação para esquemas, consultas, migrações e operações. Use no início do projeto, em auditorias trimestrais e antes de lançamentos importantes.

Como Usar Este Checklist

• Trabalhe de cima para baixo em novos projetos; pule seções já certificadas.
• Verifique os itens nos templates de PR para alterações que afetam o banco de dados.
• Itens falhos se tornam tickets com proprietário e data de vencimento - não anotações de reunião.

Esquema e Nomenclatura (1-5)

• 1. snake_case para tabelas, colunas e constraints. Sem camelCase em objetos SQL.
• 2. Nomes de tabela singulares ou plurais - escolha um para toda a equipe. Documente em ADR; nunca misture user e orders.
• 3. Chaves primárias nomeadas id ou {table}_id consistentemente. bigint/identity substituto preferido.
• 4. timestamptz para todos os instantes; nunca timestamp without time zone para eventos. Bugs de fuso horário são caros.
• 5. Chaves estrangeiras em relacionamentos que o aplicativo depende. Integridade referencial em DDL, não em esperança.

Índices e Consultas (6-10)

• 6. EXPLAIN (ANALYZE, BUFFERS) em novas consultas de API antes do merge. Sem scans sequenciais ilimitados em tabelas grandes.
• 7. Toda consulta de produção tem um limite de linhas ou agregação. APIs não fazem SELECT * de milhões de linhas.
• 8. Colunas de índice correspondem às predições WHERE e JOIN mais à esquerda. Ordem composta documentada em PR.
• 9. Índices parciais onde as consultas sempre filtram status/tenant. Escritas menores, mais rápidas e mais baratas.
• 10. Remova índices não utilizados anualmente. Candidatos de pg_stat_user_indexes.idx_scan = 0 revisados.

Migrações (11-15)

• 11. SQL versionado em git; sem DDL manual em produção. Hotfixes preenchidos em arquivos de migração no mesmo dia.
• 12. lock_timeout definido em scripts de migração. Falhe rápido, não bloqueie o tráfego.
• 13. DDL de tabelas grandes usa padrões CONCURRENTLY e NOT VALID. Veja o guia de zero downtime.
• 14. Expanda/contrate para alterações que quebram compatibilidade. Sem DROP COLUMN na mesma release com risco de rollback do aplicativo.
• 15. CI migra banco de dados vazio em todo PR. Permissões e ordenação validadas automaticamente.

Segurança e Acesso (16-20)

• 16. O aplicativo nunca usa superusuário. Funções de "break-glass" registradas e raras.
• 17. Função de aplicativo com privilégio mínimo; migrador separado. Função de proprietário é NOLOGIN.
• 18. RLS em dados de tenant em esquema compartilhado com FORCE. Indexe tenant_id nas políticas.
• 19. Autenticação SCRAM-SHA-256; sem trust em TCP. Rede pg_hba.conf com negação padrão.
• 20. TLS exigido para conexões remotas. hostssl em hba para sub-redes do aplicativo.

Operações (21-25)

• 21. Execute a versão minor atual do major suportado. PostgreSQL 13 EOL passado - plano de upgrade existe.
• 22. Backups testados com simulação de restauração trimestralmente. Backup sem restauração é pensamento positivo.
• 23. pg_stat_statements ou insights de consulta equivalentes habilitados. Principais consultas revisadas mensalmente.
• 24. Autovacuum monitorado; sem sessões longas idle-in-transaction. Horizonte xmin visível nos dashboards.
• 25. Pool de conexões (PgBouncer) antes de aumentar max_connections acima de 200. Matemática do pool documentada.

Quando Terminar

• Arquive os resultados do checklist no wiki da equipe ou em um ticket de auditoria.
• Agende um sprint de remediação para falhas de operações e segurança primeiro.
• Reexecute após um upgrade de versão principal ou alteração de isolamento de tenant.

Relacionado

• Regras de Nomenclatura e Estilo - profundidade de nomenclatura
• Regras de Índice e Consulta - padrões de consulta
• Regras de Segurança de Migração - timeouts de implantação
• Regras de Segurança - regras de controle de acesso

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