O caso, em números
No dia 9 de agosto de 2026, executamos uma manutenção completa no banco de dados PostgreSQL que sustenta o ERP de uma indústria do segmento têxtil. O resultado final, medido pela própria ferramenta:
- 46,1 GB de espaço em disco recuperados
- 188 tabelas otimizadas — 100% de sucesso, 0 erros
- 5,6 milhões de fragmentos eliminados (5.628.623, para ser exato)
- 1.944 índices reconstruídos — todos os índices da base
- 2 horas e 38 minutos de ponta a ponta, num domingo de manhã
- Nenhuma interrupção para quem estava usando o sistema
O que é fragmentação de banco de dados?
Imagine o banco de dados como um grande armário de arquivo. Toda vez que o sistema altera um registro — uma nota fiscal emitida, um pedido faturado, uma baixa no estoque — o PostgreSQL não apaga a versão anterior na hora: ele guarda a cópia nova em outra gaveta e apenas marca a antiga como "espaço vago", para ser reaproveitado no futuro.
Com meses e anos de uso diário, essas sobras se acumulam. São os fragmentos: espaços vazios espalhados no meio dos dados úteis. A tabela ocupa cada vez mais disco para guardar a mesma quantidade de informação — e o banco precisa abrir muito mais gavetas para encontrar o que você pediu. O mesmo acontece com os índices, que funcionam como o índice remissivo de um livro: quando as páginas estão fora de ordem, o índice engrossa e a consulta demora.
"Fragmentação não é vírus nem dado corrompido: é o desgaste natural de um banco de dados que trabalha todos os dias — e nunca recebe manutenção."
O que encontramos
Logo na primeira varredura, o diagnóstico mostrou um cenário comum em empresas que nunca fizeram manutenção preventiva no banco:
- 179 tabelas acima do limite considerado saudável de fragmentação
- A grande maioria nunca tinha passado por manutenção — algumas convivendo com o problema há anos
- A campeã: uma tabela de mapeamento interno do sistema com 98% de fragmentação— mais de 2 milhões de fragmentos numa tabela de poucos megabytes
- Tabelas centrais da operação — itens de nota fiscal e itens de pedidos — com dezenas de gigabytes e centenas de milhares de fragmentos cada uma
Na prática: uma parte enorme do disco do servidor estava ocupada por espaço vazio, e cada consulta precisava trabalhar mais do que deveria para responder.
Os resultados, tabela a tabela
Os números abaixo são reais, medidos pela própria ferramenta durante a execução. Para proteger a identidade do cliente, usamos a descrição de negócio de cada tabela:
- Itens de nota fiscal: de 22 GB para 9,1 GB (−58%) — 351 mil fragmentos removidos
- Itens de pedidos: de 16 GB para 6 GB (−62%) — 834 mil fragmentos removidos
- Movimentações operacionais: de 12 GB para 5,9 GB (−51%)
- Tabela de preços: de 743 MB para 63 MB (−92%)
- Mapeamento interno do sistema: de 543 MB para 4 MB (−99%) — era a tabela 98% fragmentada
Somando todas as tabelas tratadas, foram 46,1 GB devolvidos ao disco — espaço que o banco ocupava apenas com sobras que ninguém usava mais.
Por que isso importa para o administrador
Espaço recuperado é só a parte mais visível do resultado. Um banco de dados sem fragmentação traz benefícios diretos para a operação:
- Consultas e relatórios tendem a abrir mais rápido — o banco varre menos dados para responder a mesma pergunta
- Backups menores e mais rápidos — menos gigabytes para copiar, guardar e, eventualmente, restaurar numa emergência
- Menos risco de travamento nos horários críticos — fechamento do mês, faturamento, inventário
- Adia investimentos em hardware — 46 GB a menos de uso de disco postergam a compra de storage ou de um servidor novo
- Manutenção vira rotina previsível, e não uma emergência descoberta na pior hora
Vale ser transparente: o ganho de velocidade varia de caso a caso — o que os números acima mostram com precisão é a redução de espaço e de fragmentação. Mas um banco enxuto é um banco que trabalha menos para entregar o mesmo resultado. Se o seu sistema anda lento, vale ler também por que meu sistema/ERP fica lento? Causas e soluções.
Como foi feito sem parar a empresa
A manutenção foi executada pelo pg-werk, nossa ferramenta de otimização para PostgreSQL, e seguiu um princípio simples: nunca assumir que o trabalho acabou — sempre conferir de novo. Ela trabalha em ciclos: varre a base, trata o que está acima do limite e varre novamente.
- Ciclo 1: 179 tabelas tratadas
- Ciclo 2: apenas 7 ainda acima do limite
- Ciclo 3: restaram 2
- Ciclo 4: nada mais acima do limite — fim da execução
Na sequência, todos os 1.944 índices da base foram reconstruídos, para garantir que as consultas voltassem a usar caminhos enxutos. Durante todo o processo, o sistema continuou no ar: em 7 momentos outra conexão disputou a mesma tabela que estava em manutenção — todas foram detectadas e contornadas automaticamente, sem que nenhuma ficasse pendente. Quem usou o ERP naquela manhã não percebeu nada.
Como a WERK Tecnologia pode ajudar
Essa mesma manutenção pode ser programada e recorrente com opg-werk: ele analisa o banco em modo somente leitura, mostra o que encontrou e só age com a sua autorização — com relatório completo do que foi feito. Você pode fazer uma análise grátis por 7 dias e ver o estado real do seu banco antes de decidir qualquer coisa.
Se preferir deixar a manutenção com especialistas, a WERK também atua comadministração e monitoramento contínuo de bancos de dados para empresas de Pomerode, Vale Europeu e região.