Otimizador PostgreSQL
Motor de desempenho de produção para PostgreSQL

PostgreSQL (postgresql.conf) Hardware Tuner & Builder

Calcule e gere configurações otimizadas do postgresql.conf com base no hardware disponível (shared_buffers, work_mem, effective_cache_size, max_connections).

Execução no cliente com zero telemetria
Predefinições:
Entrada
Total System RAM (Memory)
GB RAM
Physical / Virtual CPU Cores
Núcleos
Conexões
clientes
~41MB work_mem/conexão
RAM: 32GB•CPU: 8 Núcleos•Workload: web•Storage: nvme
# ----------------------------------------------------------------------
# PostgreSQL 17 Hardware-Tuned Configuration
# Target Profile: WEB | RAM: 32GB | CPU: 8 Cores | Storage: NVME
# Generated: 2026-01-01T00:00:00.000Z via ToolsAA Client-Side Tuner
# ----------------------------------------------------------------------

# CONNECTIONS & NETWORKING
max_connections = 200
# Note: Transaction pooler (PgBouncer) is assumed in front of PostgreSQL.

# MEMORY ALLOCATION
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 1.6GB
work_mem = 41MB
wal_buffers = 16MB
huge_pages = try

# CHECKPOINT & WAL ENGINE
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
min_wal_size = 2GB
max_wal_size = 16GB
wal_compression = zstd
synchronous_commit = on

# QUERY PLANNER & DISK I/O TUNING
random_page_cost = 1.05
effective_io_concurrency = 300
default_statistics_target = 100
jit = off

# PARALLEL QUERY WORKERS
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# TELEMETRY & DIAGNOSTICS
track_io_timing = on
track_functions = pl
log_min_duration_statement = 1000   # Log queries exceeding 1000ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
shared_buffers: 8GB•work_mem: 41MB•effective_cache: 24GB
Shared Buffers Allocation
8GB

Cache de memória principal do PostgreSQL (~25% da RAM física total).

Effective Cache Size
24GB

Cache de disco estimada do SO disponível para varreduras de índice (~75% RAM).

Parallel Query Pool
8 Workers

4 workers paralelos por nó gather em 8 Núcleos

Execução Local Zero-Knowledge

Todo o processamento, análise e geração de código ocorrem estritamente na memória do seu navegador. Zero uploads para servidores externos.

Motor Reativo de Submilissegundos

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Referência técnica e guia de arquitetura

Guia do Desenvolvedor: Otimizador e Gerador de Hardware para PostgreSQL (postgresql.conf) — Guia de referência

Calcule e gere configurações otimizadas do postgresql.conf com base no hardware disponível (shared_buffers, work_mem, effective_cache_size, max_connections).

Parâmetros principais e controles

shared_buffersstring (memory_size)

Buffer de memória compartilhada dedicado do PostgreSQL para cache de páginas de tabelas e índices.

Padrão: 25% da memória RAM total (ex.: 4 GB em um servidor de 16 GB)
work_memstring (memory_size)

Memória alocada para ordenações internas e tabelas hash por nó de consulta antes de despejar em arquivos temporários em disco.

Padrão: ((RAM Total - shared_buffers) / (max_connections * 3)) ~ 16 MB - 64 MB
effective_cache_sizestring (memory_size)

Estimativa utilizada pelo planejador de consultas sobre a memória disponível para cache de disco (PostgreSQL + cache do sistema operacional).

Padrão: 50% - 75% da RAM total do sistema (ex.: 12 GB em 16 GB de RAM)
maintenance_work_memstring (memory_size)

Quantidade máxima de memória utilizada por tarefas de manutenção como VACUUM, CREATE INDEX e chaves estrangeiras.

Padrão: 5% - 10% da RAM total (até 2 GB)
max_connectionsinteger

Número máximo de conexões concorrentes de clientes suportadas pela instância do PostgreSQL.

Padrão: 100 (Padrão) / 20-50 usando PgBouncer

Dicas profissionais e melhores práticas

Evite definir max_connections com

Evite definir max_connections com valores elevados (> 200) diretamente no postgresql.conf. Use o PgBouncer em modo de transação para manter as conexões ativas baixas e permitir uma alocação de work_mem substancialmente mais alta com segurança.

Em discos SSD/NVMe modernos

Em discos SSD/NVMe modernos, reduza o parâmetro random_page_cost do padrão 4.0 para 1.1 e defina effective_io_concurrency como 200. Isso informa ao planejador que acessos aleatórios são rápidos, incentivando o uso de varreduras por índice.

Defina checkpoint_completion_target =

Defina checkpoint_completion_target = 0.9 e aumente max_wal_size para 16 GB - 32 GB em bancos com alto volume de gravação para distribuir as operações de E/S uniformemente e evitar picos de sobrecarga.

Quando shared_buffers for de 8 GB ou

Quando shared_buffers for de 8 GB ou superior, ative as Huge Pages no Linux (vm.nr_hugepages) e configure huge_pages = try no postgresql.conf para reduzir perdas de cache TLB e consumo de memória do kernel.

Problemas comuns e solução de problemas

O OOM Killer do Linux encerra repentinamente processos de backend do PostgreSQL

Reduza o valor de work_mem ou limite max_connections. Lembre-se de que work_mem é alocado por nó de ordenação/hash em uma consulta, de modo que consultas complexas com vários joins consomem múltiplos blocos de work_mem.

FATAL: could not create shared memory segment: Cannot allocate memory

Verifique os parâmetros de kernel do Linux (sysctl vm.max_map_count) e a memória livre do sistema. Certifique-se de que shared_buffers não ultrapasse a RAM disponível ou restrições de cgroup em contêineres.

Logs do banco alertam que checkpoints estão ocorrendo com muita frequência (checkpoints are occurring too frequently)

Aumente max_wal_size (ex.: de 1 GB para 16 GB) e eleve checkpoint_timeout (ex.: de 5 min para 15 min) para evitar disparos prematuros causados pela saturação de segmentos WAL.

Perguntas frequentes (FAQ)

Por que shared_buffers costuma ser limitado a 25%-40% da memória RAM no Linux?▼

O PostgreSQL depende de uma arquitetura de cache duplo na qual o shared_buffers opera em conjunto com o page cache do kernel Linux. Valores acima de 40% costumam provocar duplicação de dados na memória, prejudicar o cache do sistema de arquivos e intensificar os picos de gravação dos checkpoints.

O parâmetro effective_cache_size aloca ou consome memória física real?▼

Não. O effective_cache_size é apenas um valor consultivo para o otimizador de consultas (planner). Ele ajuda a estimar se páginas de índices já residem na memória do sistema operacional sem alocar nenhum byte físico adicional.

Qual é a diferença entre work_mem e maintenance_work_mem?▼

work_mem é alocado dinamicamente para operações de ordenação e tabelas hash durante consultas comuns dos usuários. Já o maintenance_work_mem é exclusivo de operações administrativas como VACUUM, CREATE INDEX e REINDEX, podendo ser configurado com valores maiores devido ao baixo número de operações paralelas.

Como a configuração deve se diferenciar entre cargas OLTP e OLAP (Data Warehouse)?▼

Ambientes OLTP com alta concorrência exigem work_mem moderado e conexões restritas para manter baixa latência. Cargas OLAP com poucas consultas concorrentes se beneficiam de work_mem muito mais alto (ex.: 256 MB - 1 GB) e valores maiores de max_parallel_workers_per_gather para paralelizar agregações pesadas.

Ferramentas e utilitários relacionados

Todas as ferramentas →
Backup diário de banco de dadosDesenvolvimento

Crie e estruture unidades de temporizador systemd e serviços complementares prontos para produção com agendamento OnCalendar, intervalos OnBootSec, execução Persistent e atrasos aleatórios.

Abrir ferramenta→
Guia do Desenvolvedor do Gerador de Configuração TypeScript (tsconfig.json)Desenvolvimento

Gere configurações tsconfig.json modernas e robustas para Next.js, Node.js, Vite ou bibliotecas com modo estrito, aliases de caminho e resolução de módulos.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de DDL CREATE TABLE de JSON para ClickHouseDesenvolvimento

Converta documentos JSON de amostra em DDL SQL do ClickHouse com engine MergeTree, tipos UInt/Int/Float/String/DateTime e mapeamento de colunas Array/Nested.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de Esquema de Tabela Google BigQuery a partir de JSONDesenvolvimento

Infira e converta objetos JSON em esquemas de tabela JSON para o Google Cloud BigQuery com suporte a RECORD, STRING, INTEGER, NUMERIC e TIMESTAMP.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de DDL CREATE TABLE de JSON para SnowflakeDesenvolvimento

Converta payloads e esquemas JSON em instruções SQL CREATE TABLE para Snowflake de nível de produção com tipos VARIANT, VARCHAR, NUMBER, BOOLEAN e TIMESTAMP_NTZ.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de Variáveis e Locals Terraform HCL a partir de JSON / YAMLDesenvolvimento

Converta estruturas JSON e YAML em restrições de tipo de variáveis Terraform HCL (type = object({...})), valores padrão, blocos locals e definições terraform.tfvars.

Abrir ferramenta→