CSV vs JSON vs Excel: I've Wasted Hours Using the Wrong Format

Na última terça-feira, às 3h da manhã, assisti meu script em Python engasgar em um arquivo CSV de 47 MB pela terceira vez naquela semana. A mensagem de erro me zombou: "Falha na alocação de memória." Eu já era engenheiro de dados há oito anos naquele momento e ainda estava cometendo erros de novato com formatos de arquivo.

Aquela noite sem dormir custou à minha equipe seis horas de tempo de processamento e quase descarrilou nosso pipeline analítico trimestral. A pior parte? Eu sabia melhor. Eu apenas fiquei preguiçoso e alcancei o CSV porque era "simples." Essa decisão desencadeou uma confusão de problemas de codificação, problemas de memória e confusão de tipo de dados que poderiam ter sido evitados completamente.

Eu sou Marcus Chen, e passei a última década construindo pipelines de dados para tudo, desde startups de fintech até varejistas da Fortune 500. Eu processei bilhões de linhas em milhares de projetos e aprendi isso da maneira mais difícil: escolher o formato de dados errado não é apenas inconveniente—é caro. Realmente caro. Certa vez, calculei que escolhas inadequadas de formatos custaram à minha empresa anterior cerca de $180,000 anualmente em tempo de computação desperdiçado, horas de desenvolvedor e trabalhos em lote falhos.

Este artigo não é mais uma comparação técnica seca. É um guia de campo escrito a partir das trincheiras, onde decisões de formato têm consequências reais. Eu vou mostrar exatamente quando usar CSV, JSON ou Excel, respaldado por cenários específicos que encontrei e as métricas que importam. Ao final, você saberá como evitar os erros que coletivamente me custaram centenas de horas.

A Armadilha do CSV: Quando o Simples se Torna Complicado

Arquivos CSV te seduzem com sua simplicidade. Eles são legíveis por humanos, universalmente suportados e parecem a escolha segura. Durante meus primeiros três anos como analista de dados, eu usava CSV como padrão para quase tudo. Então, eu entrei em uma equipe de análise de saúde processando registros de pacientes, e o CSV quase nos destruiu.

O problema começou de forma inocente. Estávamos exportando 2,3 milhões de registros de visitas de pacientes de nosso banco de dados. O CSV parecia perfeito—leve, rápido de gerar, fácil de compartilhar com nossos parceiros de pesquisa. Em duas semanas, tivemos cinco problemas críticos que interromperam nossa análise.

Primeiro, o pesadelo da codificação. Nomes de pacientes continham caracteres de 47 idiomas diferentes. Nossas exportações de CSV eram padrão ASCII, distorcendo nomes como "José García" em "Jos? Garc?a" e destruindo completamente nomes em scripts em Mandarim, Árabe e Cirílico. Passamos quatro dias depurando antes de perceber que precisávamos de UTF-8 com BOM (Byte Order Mark) para compatibilidade com o Excel, mas UTF-8 sem BOM para nossos scripts em Python. Isso mesmo—precisávamos de duas variantes diferentes de CSV para diferentes ferramentas.

Segundo, o desastre de tipo de dados. CSV não tem conceito de tipos de dados. Tudo é texto até que você o analise. Nossa coluna "patient_id" continha valores como "00123" que o Excel generosamente converteu para "123," destruindo os zeros à esquerda que precisávamos para buscas no banco de dados. As datas eram ainda piores—"03/04/2023" poderia significar 4 de março ou 3 de abril dependendo das configurações regionais. Perdemos um fim de semana inteiro tentando descobrir por que 18% de nossos joins de data estavam falhando.

Terceiro, o caos do delimitador. Notas médicas continham vírgulas, ponto e vírgulas e tabulações. Tentamos delimitador por vírgula, depois por ponto e vírgula, depois por tabulação. Cada mudança quebrava o script de importação de alguém. No final, nos decidimos pelo delimitador pipe (|) porque aparecia em apenas 0,003% de nossos campos de texto, mas até lá já havíamos perdido 12 horas e gerado seis versões de arquivo incompatíveis.

Aqui está o que eu aprendi: o CSV funciona brilhantemente para dados simples e planos com tipos consistentes e sem caracteres especiais. É perfeito para exportar 50.000 linhas de transações de vendas com IDs numéricos limpos, datas em formato ISO (YYYY-MM-DD) e sem campos de texto mais longos do que uma frase. No momento em que você adiciona complexidade—dados aninhados, tipos mistos, caracteres internacionais ou blocos de texto grandes—o CSV se torna uma responsabilidade.

Os números de desempenho contam a história. Para um arquivo de 10MB com 100.000 linhas de dados numéricos simples, a análise do CSV leva cerca de 0,8 segundos em Python com pandas. Mas adicione campos de texto com aspas e vírgulas escapadas, e isso pula para 3,2 segundos. Adicione detecção de codificação e você está em 5,1 segundos. Para processamento em lote de milhares de arquivos, esses segundos se acumulam em horas.

Os Custos Ocultos do JSON: Quando a Flexibilidade se Torna Excesso

Após meus desastres com CSV, me inclinei fortemente para o JSON. Resolveu tudo o que o CSV não conseguia lidar: dados aninhados, tipos explícitos, suporte a Unicode e uma especificação clara. Durante dois anos, fui um evangelista do JSON. Então, construí um painel de análise em tempo real para uma plataforma de e-commerce, e o JSON me ensinou algumas lições caras.

"Escolher o formato de dado errado não é apenas uma decisão técnica—é uma decisão financeira. Eu vi empresas queimarem seis cifras anualmente porque os desenvolvedores usavam CSV por hábito."

O projeto parecia direto: ingerir dados de fluxo de cliques de 200.000 usuários ativos diários, processá-los em tempo real e exibir métricas em um painel. Cada evento de clique era um objeto JSON com cerca de 30 campos, incluindo propriedades de usuários aninhadas, detalhes de produtos e metadados de sessão. Dados bonitos, estruturados e autodescritivos.

O primeiro problema nos atingiu na terceira semana: explosão de tamanho do arquivo. Nossos arquivos CSV equivalentes tinham em média 2,1MB por hora de dados. As versões em JSON? 8,7MB. Isso é 4,1x maior para as mesmas informações. O culpado era a verbosidade do JSON—cada nome de campo repetido para cada registro. No CSV, "user_id" aparece uma vez no cabeçalho. No JSON, aparece 50.000 vezes se você tiver 50.000 registros.

Isso não era apenas um problema de armazenamento. Estávamos transferindo esses arquivos entre serviços pela rede. A 8,7MB por hora vezes 24 horas vezes 30 dias, estávamos movendo 6,3GB mensalmente em vez de 1,5GB. Nossos custos de transferência de dados da AWS saltaram de $47 para $201 por mês. Multiplique isso por 15 microsserviços e adicionamos $2.310 em custos de infraestrutura mensais ao escolher JSON.

O segundo problema foi o desempenho da análise. A análise de JSON é computacionalmente cara porque requer a construção de uma árvore de objetos em memória. Para nossos dados de fluxo de cliques, analisar um arquivo JSON de 100MB levou 12,3 segundos em Python usando a biblioteca json padrão. O equivalente em CSV? 3,1 segundos com pandas. Quando você processa arquivos a cada cinco minutos, essa diferença de 9,2 segundos por arquivo totaliza 26,5 horas de tempo de computação mensal.

Mas aqui é onde fica interessante: o JSON brilha em cenários específicos que o CSV não pode tocar. Quando me mudei para uma startup de fintech construindo uma API de pagamento, o JSON se tornou indispensável. Estávamos lidando com cargas úteis de webhook com dados de transação profundamente aninhados—métodos de pagamento contendo endereços de cobrança contendo coordenadas geográficas. Tentar achatar isso em CSV exigiria mais de 40 colunas, a maioria delas vazias para qualquer transação dada.

O verdadeiro poder do JSON está em APIs e arquivos de configuração. Para nossos webhooks de pagamento, a natureza autodescritiva do JSON significava que nossos consumidores de API podiam analisar respostas sem consultar a documentação. A estrutura aninhada combinava perfeitamente com nosso modelo de domínio. E quando precisávamos adicionar novos campos, podíamos fazê-lo sem quebrar integrações existentes—algo impossível com formatos CSV posicionais.

A regra que eu desenvolvi: use JSON para intercâmbio de dados entre sistemas, especialmente APIs, e para arquivos de configuração onde a legibilidade humana e a flexibilidade importam mais do que tamanho ou velocidade. Evite JSON para armazenamento de dados em grande escala ou processamento em lote onde você está movendo a mesma estrutura repetidamente. Nesses casos, o imposto de verbosidade se torna proibitivo.

Excel: O Formato que Todos Amam Odiar (Mas Precisam em Segredo)

Passei anos descartando arquivos do Excel como "não formatos de dados reais." Eram o que os usuários de negócios criavam quando não sabiam melhor. Então eu me tornei líder de equipe de dados em uma empresa de análise de varejo e aprendi que arquivos do Excel (.xlsx) são muitas vezes o único formato que realmente funciona no mundo real.

O alerta veio durante um projeto com nossa equipe de merchandising. Eles precisavam de relatórios semanais de vendas divididos por região, categoria e SKU, com formatação condicional para destacar produtos com baixo desempenho. Eu construí um belo pipeline automatizado que gerava arquivos CSV e