VPS pra Banco PostgreSQL Pesado no Brasil 2026: Configuração e Tuning

O que mata PostgreSQL em VPS comum

PostgreSQL é banco maduro e tolerante, mas sofre com dois problemas característicos de VPS barato:

Problema 1: CPU steal alto (overcommit do provedor)

VPS barato com overcommit absurdo (mais vCPUs vendidas que cores físicos do servidor) faz query SQL travar imprevisivelmente. Sintoma clássico: EXPLAIN ANALYZE mostra plano OK, mas o tempo real varia muito (500 ms num momento, 3.000 ms noutro). Causa: PostgreSQL está esperando CPU física que o vizinho no host está usando.

Em Linux, isso aparece em top na coluna %st (steal time). Acima de 5-10% sustentado é overcommit absurdo — sua aplicação paga pelo recurso e não recebe.

VPS Audaks tem vCPU dedicada de verdade — sem disputa com vizinho, latência consistente. Pra banco que precisa de SLA, isso é base certa.

Problema 2: I/O lento (SSD SATA mascarado de "SSD")

PostgreSQL é I/O-bound em maioria dos workloads. Cada commit é uma escrita síncrona no WAL; cada SELECT em tabela grande faz leitura aleatória de disco. SSD SATA tem latência aleatória ~80-150 µs e ~90.000 IOPS 4K — fica curto pra OLTP.

NVMe Gen3 enterprise tem latência ~50 µs e ~500.000 IOPS 4K — diferença real. Em transação típica, query OLTP que demorava 200 ms no SATA passa a 50 ms no NVMe.

VPS Audaks usa NVMe enterprise por padrão (Samsung PM, Micron 7450 conforme estoque), com RAID em controladora dedicada. Detalhe técnico em SSD vs NVMe no servidor dedicado.

Tuning essencial pra PostgreSQL em produção

Memória

Quatro parâmetros que mais importam:

• shared_buffers: 25% da RAM disponível pro banco (não 25% da RAM total se o servidor roda outras coisas). Padrão de 128 MB é absurdamente baixo.
• effective_cache_size: 50-75% da RAM. PostgreSQL usa pra calcular custo de query — não aloca RAM, só estima.
• work_mem: memória por operação de sort/hash. 4-32 MB conforme query típica. Cuidado: multiplica por conexão simultânea — em pico, 100 conexões com work_mem 32 MB já são 3,2 GB.
• maintenance_work_mem: pra CREATE INDEX, VACUUM, ALTER TABLE. 256 MB-1 GB ok. Generoso aqui acelera maintenance.

WAL e checkpoint

WAL (Write-Ahead Log) é responsável pela durabilidade. Tuning crítico em ambiente com escrita intensa:

• wal_buffers: 16 MB pra maioria, até 64 MB pra escrita pesada
• max_wal_size: 4-8 GB em produção; padrão 1 GB força checkpoint frequente
• checkpoint_timeout: 15-30 minutos pra balancear durabilidade e performance
• checkpoint_completion_target: 0.9 pra espalhar I/O de checkpoint

Conexões e pooling

PostgreSQL não foi feito pra muita conexão direta — cada conexão consome ~10 MB RAM e processo dedicado. Acima de ~100 conexões simultâneas, vale usar pooler:

• PgBouncer em modo transaction — padrão consolidado pra aplicação web
• Odyssey ou PgPool-II pra cenário mais complexo
• Aplicação conecta no pooler, pooler mantém pool de N conexões reais ao banco

Sem pooler, app que abre 500 conexões direto no PostgreSQL vai consumir 5 GB de RAM só com overhead — recurso desperdiçado.

Autovacuum agressivo em tabela com escrita

MVCC do PostgreSQL gera tuples mortos a cada UPDATE/DELETE. Sem VACUUM regular, tabela incha (table bloat), índice perde performance, queries ficam lentas. Tuning:

• autovacuum_vacuum_scale_factor: padrão 0.2 (20% da tabela) é alto pra tabela grande. Use 0.05-0.1 em tabela com escrita intensa.
• autovacuum_analyze_scale_factor: igual, 0.05-0.1 pra tabela grande
• autovacuum_max_workers: 4-6 pra servidor com 8+ cores
• autovacuum_naptime: 30s-1min pra cenário com churn alto

Pra tabela muito grande (>100M linhas) com escrita pesada, considere pg_repack pra desfragmentar online sem lock pesado.

Dimensionamento prático por volume de dado e carga

PostgreSQL leve (<10 GB de dado, <100 conexões)

VPS Audaks 2 vCPU + 4 GB RAM + 40 GB NVMe. Roda aplicação web típica com ORM, sem dor. Faixa: R$ 80-150/mês.

PostgreSQL médio (10-50 GB, 100-300 conexões com pooling)

VPS 4 vCPU + 8 GB RAM + 80 GB NVMe. Vale instalar PgBouncer pra pooling. Backup automatizado pra Object Storage. Faixa: R$ 250-450/mês.

PostgreSQL pesado (50-200 GB, 300-1.000 conexões com pooling)

VPS 8 vCPU + 16 GB RAM + 160 GB NVMe. PgBouncer obrigatório. Considere réplica de leitura em VPS separado. Backup contínuo (WAL archiving). Faixa: R$ 700-1.500/mês.

PostgreSQL muito pesado (200 GB+, banco crítico)

Hora de considerar servidor dedicado ou DBaaS gerenciado Audaks. Dedicado com NVMe enterprise em RAID 10 + RAM grande + CPU mais cores. DBaaS se você não tem DBA dedicado.

Monitoramento essencial

PostgreSQL em produção precisa de monitoramento contínuo. Stack consolidada:

• pg_stat_statements habilitado pra ver top queries por tempo total
• pgBadger pra análise de log periódica
• Prometheus + postgres_exporter + Grafana pra métrica em tempo real
• pg_top ou SELECT * FROM pg_stat_activity pra ver sessões ativas
• Alerta em: replicação atrasada, conexão saturada, lock prolongado, espaço em disco, tempo de query > threshold

Backup confiável é parte do banco em produção

Backup PostgreSQL sério tem três níveis:

• pg_basebackup + WAL archiving pra point-in-time recovery
• Backup no Object Storage com Object Lock pra imutabilidade anti-ransomware
• Réplica streaming em VPS/servidor separado pra failover rápido

pg_dump puro é OK pra ambiente pequeno e dev, mas em produção com dado crítico, padrão é pg_basebackup + WAL contínuo + restore validado em ambiente de teste mensal.

Quando partir pra dedicado ou DBaaS

VPS atende PostgreSQL até certo ponto. Sinais claros de que chegou hora de partir pra próximo nível:

• Dado ativo passa de 200 GB com necessidade de NVMe grande customizado
• Mais de 1.000 conexões simultâneas mesmo com pooling agressivo
• Workload requer RAM além de 32 GB pra cache eficiente
• Compliance ou cliente exige isolamento físico
• Você passa mais de 5-10h/mês cuidando do banco e quer terceirizar

Pra primeira situação, dedicado em servidor próprio resolve. Pra última, DBaaS é o caminho — você foca em aplicação, Audaks cuida de PostgreSQL.

Audaks: VPS com NVMe + vCPU dedicada pra PostgreSQL

VPS Audaks tem NVMe enterprise por padrão, vCPU dedicada de verdade (sem overcommit absurdo), IP fixo, Linux pré-configurado com PostgreSQL via marketplace ou apt install. Pra ambiente maior, oferecemos DBaaS PostgreSQL gerenciado ou servidor dedicado com configuração customizada.

Leia também: DBaaS PostgreSQL e MySQL Gerenciado — quando vale, SSD vs NVMe no servidor dedicado 2026.

Perguntas frequentes

Audaks tem PostgreSQL pré-instalado no VPS?

Marketplace 1-clique tem stack PostgreSQL + cliente padrão. Pra instalação customizada, VPS vem com Ubuntu/Debian/Rocky e você instala via apt/dnf — mesmo padrão de qualquer ambiente Linux.

Suporta extensions específicas (pgvector, TimescaleDB, PostGIS)?

Em VPS self-hosted, qualquer extension funciona (você instala). Em DBaaS gerenciado, suportamos as principais (pg_stat_statements, pg_trgm, uuid-ossp, pgcrypto, PostGIS). Outras sob configuração.

Como configurar replicação streaming entre 2 VPS?

Padrão PostgreSQL — primário com wal_level=replica, secundário com standby.signal. Audaks tem rede privada baixa latência entre VPS na mesma região, base ideal pra replicação síncrona ou assíncrona.

Backup pra Object Storage funciona como?

WAL-G ou pgBackRest pra streaming contínuo pro Object Storage S3-compatible Audaks. Object Lock garante imutabilidade contra ransomware.

Posso migrar PostgreSQL de outro provedor pra Audaks?

Sim. Padrão: pg_basebackup + replicação lógica até cutover, ou pg_dump+restore pra cenário pequeno. Migração assistida gratuita pra cliente novo.