No Master Control, os backups são automaticamente armazenados na nuvem, independentemente do dispositivo do técnico ou do cliente, o que significa que o dispositivo do técnico não precisa estar conectado. Técnicos autorizados podem facilmente recuperar esses backups pelo painel de controle, mesmo que a máquina original do cliente não esteja disponível.
Uma dúvida comum refere-se ao espaço de nuvem utilizado. Em um artigo anterior (leia AQUI), explicamos o cálculo do espaço de armazenamento e como a compactação permite que 30 GB possam armazenar até aproximadamente 360 GB, dependendo do conteúdo copiado.
Neste artigo, abordaremos a questão que gera mais dúvidas: o comportamento dos bancos de dados diante dessa compactação.
A compactação em bancos de dados apresenta um comportamento diferente em relação a outros tipos de arquivos. Isso ocorre porque os dados são estruturados de forma específica, muitas vezes já otimizados para reduzir redundâncias, o que limita o ganho de compressão. Assim, enquanto documentos ou imagens podem ter uma redução significativa de espaço, os bancos de dados tendem a oferecer resultados mais variáveis nesse processo.
Existem muitas diferenças importantes entre bancos de dados quando se trata de compactação, especialmente por ferramentas de terceiros como o Master Control. Neste artigo, utilizaremos como exemplo quatro representantes de diferentes categorias de compactação: Firebird, MongoDB, PostgreSQL e SQL Server.
Firebird #
O Firebird, banco de dados relacional leve e bastante utilizado em sistemas de gestão, costuma apresentar as melhores taxas de compressão externa entre os principais SGBDs. No Master Control, não é incomum alcançar reduções de 70% a 90%, podendo superar esses números em cenários com grande volume de dados textuais. Essa eficiência ocorre porque o Firebird armazena informações principalmente em arquivos .fdb, que, apesar de conterem dados, índices e metadados, não contam com mecanismos internos de compressão nativa, deixando espaço para que ferramentas externas explorem ao máximo a redução de redundâncias. Como resultado, textos, registros tabulares e informações estruturadas em blocos se beneficiam de maneira significativa. Por outro lado, quando há muitos dados binários ou fragmentação excessiva, a taxa de compressão pode ser menor, mas ainda assim tende a superar a observada em bancos como SQL Server e PostgreSQL. Esse comportamento faz do Firebird um dos bancos que mais aproveitam compactação externa, oferecendo excelente relação entre espaço contratado na nuvem e quantidade efetiva de dados armazenados.
MongoDB #
O MongoDB, por ser um banco de dados NoSQL orientado a documentos, apresenta um comportamento de compressão distinto quando comparado a soluções como Firebird e SQL Server. Em geral, seus arquivos possuem uma taxa de compressão externa menor que a do Firebird, mas superior à do SQL Server, resultando no Master Control em um índice moderado, normalmente entre 40% e 70%, dependendo do tipo de dado, sendo textos JSON mais favoráveis à compactação que dados binários ou blobs. Essa variação ocorre em função da própria estrutura de armazenamento: o MongoDB utiliza arquivos no formato .wt (WiredTiger) ou, em versões mais antigas, .ns, .0, .1, etc., que podem conter dados binários, índices e metadados. Além disso, como o mecanismo WiredTiger já emprega compressão interna (Snappy ou Zlib) por padrão, o ganho adicional obtido com ferramentas externas tende a ser menor. Outro fator importante é a presença de índices ou a fragmentação dos arquivos, que também podem reduzir a eficiência da compactação.
O PostgreSQL #
O PostgreSQL, banco de dados relacional de código aberto, também apresenta particularidades no comportamento de compressão quando submetido a ferramentas externas. Em comparação, seus arquivos costumam atingir taxas de compressão mais próximas às do SQL Server do que às do Firebird, geralmente variando entre 30% e 70% no Master Control, a depender do perfil dos dados armazenados. Isso acontece porque o PostgreSQL utiliza arquivos em formato .dat dentro de sua estrutura de diretórios, os quais podem conter dados, índices, tabelas temporárias e catálogos do sistema. Diferente do MongoDB com WiredTiger, o PostgreSQL não aplica compressão interna nativa nos dados em disco, mas permite o uso de TOAST (The Oversized-Attribute Storage Technique) para armazenar colunas muito grandes com opções de compressão. Esse mecanismo pode reduzir o tamanho físico de determinados campos, mas também limita o ganho adicional quando submetido a compressão externa. Além disso, o volume de índices, a fragmentação e o uso intenso de dados binários influenciam diretamente a eficiência do processo, fazendo com que o resultado varie bastante conforme o tipo de aplicação.
SQL Server #
O SQL Server, por ser um banco de dados relacional robusto e amplamente utilizado em ambientes corporativos, tende a apresentar uma das menores taxas de compressão externa entre os principais SGBDs. No Master Control, é comum que a redução fique entre 20% e 40%, variando conforme o volume e o tipo de dados armazenados. Isso se deve, em grande parte, à sua estrutura de arquivos — principalmente os arquivos .mdf (dados), .ndf (secundários) e .ldf (logs) — que concentram informações altamente organizadas, com índices, metadados e registros transacionais. Outro ponto importante é que o SQL Server já oferece recursos nativos de compressão de dados e de índices (como o algoritmo ZSTD no SQL Server 2025), além de mecanismos como a compressão de backup interna, o que diminui consideravelmente os ganhos quando se aplica uma compactação externa adicional. Dados textuais costumam comprimir melhor, mas a presença de dados binários, grande número de índices e logs extensos reduz a eficiência do processo. Assim, embora o SQL Server proporcione segurança e desempenho, em termos de compressão externa seus resultados geralmente são mais modestos que os obtidos em bancos como Firebird ou MongoDB.
Comparativo geral #
| Percentual de compressão | Observações | ||
|---|---|---|---|
| Firebird | Alta | 70–90% | Arquivo monolítico, pouco fragmentado |
| MongoDB | Média | 40–70% | Já usa compressão interna |
| PostgreSQL | Média | 30–70% | Estrutura modular com suporte a compressão seletiva via TOAST |
| SQL Server | Baixa | 20–40% | Arquivos complexos e fragmentados |
É importante ressaltar que essas taxas de compactação se aplicam diretamente às ações no banco de dados, e não a arquivos de backup que já tenham sido gerados pelo sistema.
Resumindo, o Firebird tende a ser o mais eficiente em compactação por ferramentas de terceiros, alcançando taxas significativamente superiores às do SQL Server. Isso o torna uma opção interessante para aplicações que exigem portabilidade, baixo consumo de disco e backups mais compactos. O MongoDB, por sua vez, ocupa uma posição intermediária: não alcança a mesma eficiência do Firebird, mas costuma oferecer resultados melhores que os do SQL Server.
Gostou do artigo? Veja então as novidades em nosso SITE, compartilhe o artigo com seus amigos e siga a Master Remote no LinkedIn, Youtube, Instagram e Facebook. Além disso, aproveite para explorar outros artigos ao lado e fique por dentro das últimas novidades sobre tecnologia para atendimento ao cliente e cibersegurança.
VOCÊ PODE AINDA SE INTERESSAR POR:
