App Dev → DBA Path

Uma progressão estruturada de desenvolvedor de aplicativos para engenheiro de banco de dados no PostgreSQL 18.4 - índices, MVCC e sua primeira revisão de migração com marcos que você pode autoavaliar trimestralmente.

Receita

App Dev → DBA Path (típico 18-36 meses)
  Fase 1 (0-6 meses):  Fluência em autor de consulta + EXPLAIN
  Fase 2 (6-12 meses): MVCC, bloqueios, migrações seguras
  Fase 3 (12-18 meses): Revisor secundário + simulação em staging
  Fase 4 (18-24 meses): Shadow de on-call + propriedade de HA/PITR
  Staff (24+ meses):     Governança de frota, RTO/RPO, atualizações importantes

Quando usar este caminho:

• Engenheiro de backend quer uma trilha de carreira formal em banco de dados
• A equipe carece de DBA dedicado, mas precisa de profundidade interna
• Plano de mentoria para lacunas na Matriz de Habilidades

Exemplo de Trabalho

Fase 1: Índices e EXPLAIN

-- Aprender a regra de prefixo mais à esquerda da árvore b
CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at DESC);
 
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders
WHERE tenant_id = $1
ORDER BY created_at DESC
LIMIT 20;

Marco: Três PRs mesclados com evidência de EXPLAIN aprovados sem solicitações de reescrita.

Estudo: Índices B-tree, Habilidade de Revisão de EXPLAIN

Fase 2: MVCC e Bloqueios

-- Ver visibilidade xmin/xmax (conceitual)
SELECT xmin, xmax, ctid FROM orders WHERE id = $1;
 
-- Modos de bloqueio durante a migração
SELECT mode, granted FROM pg_locks WHERE relation = 'orders'::regclass;

Marco: Pontuar uma migração de risco médio corretamente usando a Habilidade de Segurança de Migração antes do DBA.

Estudo: Arquitetura PostgreSQL, DDL de Zero Downtime

Fase 3: Primeira Revisão de Migração

## Checklist do revisor (sua primeira revisão secundária)
- [ ] Risco de bloqueio rotulado
- [ ] CONCURRENTLY onde necessário
- [ ] SQL de Rollback presente
- [ ] EXPLAIN se a consulta mudar
- [ ] Aprovar ou solicitar alterações com comentários SQL específicos

Marco: Revisar cinco PRs de migração; zero incidentes de produção rastreados até DDL aprovado.

Estudo: Revisão de Código para SQL

Fase 4: Operações

# Participação em simulação de failover
patronictl list
psql -c "SELECT pg_is_in_recovery();"

Marco: Liderar a função de scribe em uma simulação de failover em staging; documentar RTO em um ticket.

Estudo: Habilidade de Simulação de Failover, Noções Básicas de PITR

Mergulho Profundo

Tabela de Transferência de Habilidades

Pareamento de Mentoria

Semana A: Aprendiz escreve migração; mentor revisa com a rubrica da Habilidade de Revisão de EXPLAIN
Semana B: Aprendiz revisa PR de colega de equipe de app; mentor audita a qualidade da revisão
Semana C: Incidente conjunto simulado em alerta de staging

Anti-Padrões

• Pular para HA sem profundidade de EXPLAIN - diagnostica incorretamente tempestades de consultas como problemas de failover
• Coleta de certificados sem shadow de on-call - teoria sem pressão
• Apenas ler, nunca revisar - a habilidade de revisão precisa de repetição

Armadilhas

• Títulos sem escopo - título de "DBA" mas sem política de acesso de produção leva a heroísmo inseguro. Correção: rotação formal e guardrails.
• Ignorar o domínio da aplicação - os melhores engenheiros de banco de dados mantêm o contexto do produto. Correção: permanecer incorporado em um esquadrão de serviço.
• Pular CLI do Linux - não consegue triar incidentes de disco cheio. Correção: Noções Básicas de CLI do Linux para DBAs na fase 2.
• Modelo mental apenas de ORM - perde índices parciais e interações de gatilho de restrição. Correção: escrever SQL bruto mensalmente.

Alternativas

FAQs

Relacionados

• Noções Básicas de Onboarding - configuração do primeiro dia
• Matriz de Habilidades - grade de júnior a staff
• Mentoria de Equipes de App - perspectiva de liderança
• Crescimento de Carreira DBA → Staff - trilha de staff
• Pareamento em PRs de Consulta - revisão prática

Versões de Stack: Esta página foi escrita para equipes OLTP do PostgreSQL 18.4 com migrações Flyway e HA Patroni ou RDS.