Noções Básicas de Postgres Gerenciado
O PostgreSQL Gerenciado (RDS, Cloud SQL, Aurora, Neon, Supabase) transfere a aplicação de patches, backups e mecanismos de failover para o provedor. Você ainda é responsável pelo design do esquema, desempenho de consultas, gerenciamento de conexões, lista de permissões de extensões e controle de acesso. Trate o gerenciado como menos trabalho operacional, não menos engenharia de banco de dados.
Receita
Responsabilidade compartilhada (típica):
Provedor: hypervisor, disco, backups automatizados, patches de versão menor, mecanismo de failover HA
Você: consultas, índices, migrações, roles, pools de conexão, extensões, custo, validação de RPO/RTO
-- Seu trabalho no primeiro dia, independentemente do provedor
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT version();
SHOW max_connections;Quando recorrer a isto:
- Projetos novos (Greenfield) escolhendo gerenciado vs. Patroni auto-hospedado
- Integração de engenheiros que assumem que o RDS otimiza consultas lentas automaticamente
- Pacote de conformidade documentando a divisão de responsabilidades
Exemplo de Trabalho
Checklist de provisionamento do RDS PostgreSQL 18.4 da perspectiva da equipe de aplicação.
# Mentalidade Terraform (conceitual)
Engine: postgres
EngineVersion: "18.4"
InstanceClass: db.r7g.large
MultiAZ: true
StorageEncrypted: true
BackupRetentionPeriod: 14
DeletionProtection: true-- Após o endpoint estar disponível: responsabilidades da aplicação
CREATE ROLE app_api LOGIN PASSWORD 'from-secrets-manager';
GRANT CONNECT ON DATABASE orders TO app_api;
-- índices, RLS, pg_stat_statements revisados semanalmente
-- Grupo de parâmetros (seu ticket para DBA/plataforma):
-- log_min_duration_statement = 500
-- shared_preload_libraries = pg_stat_statements# Conexão via TLS
psql "host=prod.xxxx.us-east-1.rds.amazonaws.com sslmode=verify-full sslrootcert=rds-ca.pem"O que isso demonstra:
- O provedor cria a instância, criptografia de armazenamento, infraestrutura Multi-AZ
- A equipe cria roles, esquema, índices e monitora consultas
- TLS e bundle CA são requisitos do lado do cliente
- Grupos de parâmetros são como você ajusta o logging e as extensões
Mergulho Profundo
Matriz de Responsabilidade
| Área | Provedor gerenciado | Sua equipe |
|---|---|---|
| Patches de SO/kernel | Sim | Não |
| Atualizações menores do Postgres | Janela agendada | Testar compatibilidade da aplicação |
| Atualizações maiores | Caminho assistido | Teste de migração, verificações de extensão |
| Backups base | Automatizados | Testes de restauração |
| Failover | Mecanismo | Reconexão da aplicação, configuração do pooler |
| Consultas lentas | Não corrigidas automaticamente | EXPLAIN, índices, estatísticas |
| Extensões | Lista de permissões | Solicitar + testar |
| Rede | Posicionamento VPC | Grupos de segurança, link privado |
| Custo | Horas de instância | Dimensionamento correto, crescimento de armazenamento |
O que o Gerenciado Não Corrige
- Consultas N+1 de ORM
- Índices ausentes em tabelas de 50 milhões de linhas
- Exaustão de
max_connectionssem PgBouncer - Inchaço de slot de replicação lógica de consumidores mal configurados
- Erros no modelo de dados
Arquitetura de Conexão
App -> PgBouncer (recomendado) -> endpoint gerenciado -> primário (+ standby)
Use endpoints de leitura do provedor para réplicas com roteamento ciente de lag.
Armadilhas
- Assumir que Multi-AZ corrige bugs da aplicação - failover ainda perde transações em andamento sem retentativa. Correção: escritas idempotentes e reconexão do pooler.
- Usar grupo de parâmetros padrão -
max_connections, logging ework_memfrequentemente incorretos para a carga de trabalho. Correção: grupo de parâmetros personalizado por ambiente. - Acessibilidade pública habilitada - Postgres exposto à internet. Correção: sub-rede privada + VPN/bastion apenas.
- Usuário master semelhante a superusuário na aplicação - RDS
postgresou admin no DSN. Correção: roles específicas da aplicação com grants. - Ignorar o teto de autoescalonamento de armazenamento - o máximo de disco ainda é atingido. Correção: prever o crescimento; alertar em 80%.
- Desalinhamento de extensão staging vs prod - falha na implantação por falta de
vector. Correção: manifesto de extensão no repositório de migrações.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Patroni Auto-hospedado | Necessita de extensões exóticas, ajuste de kernel | Equipe pequena sem DBA |
| Operadores Kubernetes (CloudNativePG) | Nativo de K8s, GitOps | Quer totalmente hands-off de patches |
| Serverless (Neon) | Branching de desenvolvimento, carga variável | Carga pesada previsível de OLTP é mais barata no RDS |
| Aurora | Escala AWS + failover rápido | Requisito multi-cloud |
FAQs
Gerenciado é mais barato que VMs?
Frequentemente sim em escala pequena/média quando o trabalho é incluído. Cargas de trabalho grandes e estáveis podem preferir instâncias reservadas ou auto-hospedadas.
Quem aplica patches menores do Postgres?
O provedor agenda; você escolhe a janela de manutenção e testa extensões.
Posso usar SSH na instância?
Geralmente não no RDS/Cloud SQL. Use logs, métricas e apenas SQL.
Controle pg_hba?
Limitado - rede + grupos de segurança + autenticação IAM substituem muito do hba na nuvem.
Backup é suficiente para DR?
Backups do provedor ajudam; você ainda executa testes de restauração e documenta RPO/RTO.
Réplicas de leitura são gerenciadas?
Sim, como um clique de botão; você configura o roteamento e o SLO de lag.
Conformidade BAA/HIPAA?
Assine o acordo do provedor; você ainda configura criptografia, acesso, auditoria.
Lock-in de fornecedor?
Migração lógica via pg_dump/replicação é possível, mas custosa; abstraia o pooler e o driver.
Paridade Dev/staging?
Mesma versão principal e conjunto de extensões; classe de instância menor é aceitável.
Quando sair do gerenciado?
Extensões raras, arquivamento WAL personalizado ou custo em escala grande e estável.
Relacionado
- AWS RDS & Aurora Postgres - Específicos da AWS
- Google Cloud SQL & AlloyDB - Específicos do GCP
- Neon & Supabase - Padrões serverless
- ADR de Seleção de Nuvem - Matriz de decisão
- Melhores Práticas de Postgres Gerenciado - Checklist operacional
Versões de 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+.