Object Storage vs. Block Storage: quando usar cada um

Todo banco de dados relacional trava se você trocar o disco dele por um bucket S3. E toda tentativa de guardar 40 milhões de imagens de usuário num volume de bloco vira um pesadelo de gerenciamento de sistema de arquivos antes do primeiro milhão. O problema não é a ferramenta. É a arquitetura por trás dela.

Object storage e block storage resolvem problemas diferentes porque foram desenhados com trade-offs diferentes: um otimiza para escala horizontal e metadados ricos, o outro para latência baixa e acesso randômico. Confundir os dois na hora de arquitetar custa retrabalho de migração seis meses depois, quando o volume de dados já não cabe mais na decisão errada.

Este artigo cobre a diferença estrutural entre os dois modelos, os cenários técnicos onde cada um vence, e onde a resposta certa é usar os dois ao mesmo tempo.

Block storage: como funciona por baixo do capô

Block storage divide os dados em blocos de tamanho fixo, cada um com um endereço próprio. O sistema operacional enxerga esses blocos como se fossem um disco físico conectado à máquina, seja via iSCSI, Fibre Channel ou o driver de bloco que a cloud expõe para a VM.

Essa camada de abstração é o que permite instalar um sistema de arquivos por cima (ext4, XFS, NTFS) e tratar o volume como qualquer disco local. O kernel gerencia alocação, o sistema de arquivos gerencia hierarquia de diretórios, e a aplicação não sabe (nem precisa saber) que o disco é remoto.

Na prática, isso significa:

• Acesso randômico de baixa latência. Um banco de dados relacional pode escrever uma página de 8 KB no meio do arquivo sem reescrever o arquivo inteiro.
• Escala vertical. Você aumenta IOPS e throughput trocando o tipo de volume ou anexando mais discos à mesma VM, não distribuindo carga entre múltiplos nós.
• Anexação exclusiva. Um volume de bloco normalmente está preso a uma única VM por vez. Compartilhar o mesmo volume entre múltiplos hosts exige um sistema de arquivos cluster (GFS2, OCFS2), que a maioria das stacks não usa.

O Locaweb Cloud sustenta esse modelo com discos NVMe de até 8.000 IOPS e volumes adicionais dimensionados por GB, o que cobre o caso de uso mais comum: banco de dados que precisa de latência previsível independente de quanto ele cresce.

Rodar essa camada no core da internet brasileira muda o cálculo de latência de forma concreta. Um volume de bloco anexado a uma VM com peering local responde em dezenas de milissegundos para usuários no Brasil, contra uma rota que atravessa fronteira em provedores sem data center nacional.

Quando block storage é a escolha certa

• Bancos de dados relacionais (PostgreSQL, MySQL) e não relacionais que fazem escrita aleatória constante.
• Sistemas de arquivos de aplicação que exigem POSIX completo: locks, permissões Unix, hierarquia de diretórios.
• Filas de mensagens e sistemas com write-ahead log, onde a ordem de escrita em disco importa para a consistência.
• Boot volumes de VMs, onde o sistema operacional precisa de um disco que se comporte como disco.

Object storage: outra unidade, outra lógica

Object storage não divide dados em blocos. Ele trata cada arquivo como um objeto único, guardado com seus metadados e um identificador dentro de um namespace plano, o bucket. Não existe hierarquia de pastas de verdade: o que parece uma estrutura de diretórios (“imagens/2026/produto-123.jpg”) é, na prática, uma chave de string dentro do mesmo espaço plano.

Essa escolha de design tem duas consequências diretas:

• Não há edição parcial. Para mudar um byte do objeto, você reescreve o objeto inteiro. Não existe operação de “abrir, buscar posição X, escrever”. Isso descarta object storage para qualquer coisa que precise de escrita incremental.
• Escala horizontal quase sem limite. Como cada objeto é independente e acessado via API REST (GET, PUT, DELETE sobre HTTP), adicionar capacidade significa adicionar mais nós ao cluster de armazenamento, não mais disco à mesma máquina. Object storage compatível com S3, como o do Locaweb Cloud, entrega esse modelo sem exigir que você reescreva a lógica de acesso: o SDK e as chamadas já seguem o padrão que a maioria das ferramentas de backup, CDN e pipeline de dados espera.

Metadados ricos por objeto (data de criação, tags customizadas, controle de versão) tornam esse modelo naturalmente mais fácil de indexar e buscar em escala do que uma árvore de diretórios com milhões de arquivos.

Essa arquitetura também muda como você pensa em durabilidade. Em vez de depender de RAID num único array de disco, o object storage replica cada objeto entre múltiplos nós do cluster automaticamente. Perder um nó não significa perder dado, porque a cópia redundante já está em outro lugar da malha, um design que favorece consistência de longo prazo sobre velocidade de escrita individual.

Quando object storage é a escolha certa

• Armazenamento de mídia: imagens, vídeos, arquivos de usuário que são gravados uma vez e lidos muitas vezes (padrão write-once-read-many).
• Backups e snapshots, onde imutabilidade e versionamento importam mais que latência de escrita.
• Data lakes e pipelines de analytics, que leem grandes volumes de arquivo sequencialmente, não byte a byte.
• Assets estáticos servidos via CDN, onde o object storage funciona como origin compatível com S3 direto atrás do CDN.

A tabela que resume a decisão

O caso mais comum: você precisa dos dois

A pergunta raramente é “object ou block”. Na maioria das arquiteturas de produção que rodam no Locaweb Cloud, a resposta é as duas coisas, cada uma no lugar certo.

Um e-commerce típico roda o catálogo de produtos e as transações num banco relacional sobre block storage, com IOPS suficiente para não gargalar no checkout. As imagens de produto, os vídeos de review e os backups diários do próprio banco vão para object storage, onde o custo por GB é menor e a escala não depende de redimensionar disco.

Isso não é gambiarra de arquitetura. É reconhecer que o job de armazenar uma transação financeira e o job de servir uma foto de produto têm requisitos de latência, consistência e escala que pedem ferramentas diferentes. Migrar o catálogo de imagens de um volume de bloco para object storage, por exemplo, normalmente reduz custo de armazenamento sem tocar em performance percebida, porque a foto não precisa da mesma latência de escrita que uma linha de pedido precisa.

O resultado, quando as duas camadas são bem separadas desde o início, é uma base sólida de infraestrutura: o banco cresce em IOPS sem arrastar o custo do catálogo de mídia junto, e o catálogo de mídia escala em volume sem competir por latência com o checkout.

Erros comuns na hora de escolher

Colocar banco de dados em object storage. Alguns times tentam contornar isso montando object storage como sistema de arquivos via FUSE. Funciona em teste, quebra sob carga real: a latência de cada operação de escrita explode porque o protocolo por trás é HTTP, não um driver de bloco.

Guardar milhões de arquivos pequenos em block storage sem pensar no sistema de arquivos. Um volume de bloco com ext4 degrada em performance de listagem de diretório muito antes de chegar no limite de espaço, quando o número de arquivos por pasta passa de algumas centenas de milhares. Se o volume de arquivos pequenos vai crescer, object storage é a base mais sólida desde o início, não um refactor para depois.

Ignorar o padrão de acesso. A decisão certa depende de como o dado é lido, não só de quanto ele pesa. Um arquivo de 2 GB acessado uma vez por mês para auditoria tem perfil de object storage. Um arquivo de 2 GB que recebe escrita aleatória o tempo todo (um banco de dados, por exemplo) tem perfil de block storage, independente do tamanho.

Rodando os dois no mesmo provedor

Migrar workload entre os dois modelos custa menos quando ambos rodam na mesma infraestrutura, sob a mesma cobrança em reais e a mesma rede interna de baixa latência.

O Locaweb Cloud é a decisão estratégica para performance de aplicações justamente porque coloca block storage NVMe e object storage compatível com S3 na mesma VPC, sem taxa de egress entre eles.

Isso importa na prática de deploy: mover o backup do banco (block) para o bucket de arquivamento (object) não atravessa a internet pública, então não soma latência nem custo de saída de dados.

Para quem avalia nuvem nacional ou internacional para esse tipo de arquitetura híbrida, a rede interna compartilhada entre os dois tipos de storage costuma pesar mais na decisão do que o preço por GB isolado.

A decisão começa antes do storage, na unidade de infraestrutura onde a aplicação roda. Vale entender primeiro o que é servidor e como escolher o provedor certo: a VM é a base sobre a qual você anexa o volume de bloco, e o object storage entra como camada complementar, não substituta.

O Locaweb Cloud equipa quem constrói esse tipo de arquitetura: block storage e object storage na mesma VPC, sem reescrever a camada de dados a cada ordem de grandeza de usuários.

FAQ – Perguntas frequentes sobre object storage e block storage