Processando big data no MacBook mais barato

• O mais recente MacBook Neo foi avaliado para medir quão bem lida com cargas de trabalho de banco de dados usando os benchmarks ClickBench e TPC-DS SF300
• O experimento usou um modelo com chip Apple A18 Pro de 6 núcleos, 8GB de memória e SSD de 512GB, com testes executados nas versões v1.5.0 e v1.4.4 LTS do DuckDB
• No ClickBench, o MacBook Neo apresentou resultados mais rápidos que instâncias em nuvem em execuções frias, algo atribuído à alta velocidade de acesso do SSD NVMe local
• No teste TPC-DS SF300, houve disk spilling de até 80GB em algumas consultas, mas todas as queries foram concluídas em 79 minutos, de forma estável
• Embora tenha limitações para tarefas cotidianas de big data, o teste mostra que ele é plenamente utilizável como notebook cliente para DuckDB

---

Especificações do MacBook Neo e objetivo do teste

• O MacBook Neo lançado pela Apple foi apresentado para estudantes e escritores, mas a equipe do DuckDB resolveu validar seu desempenho dentro da filosofia de “big data no notebook”
  • O modelo vendido na Europa não inclui carregador e vem apenas com o notebook e um cabo USB-C
  • As opções disponíveis são somente SSD de 256GB ou 512GB, e o teste foi feito com o modelo de 512GB
• Ele vem com 8GB de memória e chip Apple A18 Pro (6 núcleos)
  • O iPhone 16 Pro, que usa o mesmo chip, já havia concluído o TPC-H SF100 em menos de 10 minutos em um teste anterior

Benchmark ClickBench

• O ClickBench é um benchmark de banco de dados analítico que executa 43 consultas em uma tabela única com 100 milhões de linhas
  • Os dados ocupam 14GB em formato Parquet e 75GB em CSV
• O DuckDB v1.5.0 foi portado e executado no macOS, com o limite de memória ajustado para 5GB para reduzir a dependência de swap
• Comparativos usados:
  • MacBook Neo (2P+4E cores, 8GB RAM)
  • AWS c6a.4xlarge (16 vCPU, 32GB RAM)
  • AWS c8g.metal-48xl (192 vCPU, 384GB RAM)

Resultados e análise

• Resultados da execução fria:
  • O MacBook Neo concluiu todas as consultas em menos de 1 minuto, com mediana de 0,57 s, mostrando o melhor desempenho
  • As instâncias em nuvem tiveram resultados mais lentos devido à latência do armazenamento em rede
• Resultados da execução quente:
  • O tempo total de execução do MacBook Neo melhorou cerca de 10%
  • O c8g.metal-48xl foi o mais rápido no geral, mas o MacBook Neo superou o c6a.4xlarge pela mediana
  • O tempo total de execução foi cerca de 13% mais lento que o do c6a.4xlarge

Benchmark TPC-DS

• Foi usada a versão DuckDB v1.4.4 LTS, com limite de memória de 6GB
• SF100:
  • Tempo mediano por consulta de 1,63 s, com total de 15,5 minutos
• SF300:
  • Tempo mediano por consulta de 6,90 s
  • Ocorreu disk spilling de até 80GB
  • A query 67 levou 51 minutos, e todas as consultas foram concluídas em menos de 79 minutos

Pontos a considerar na compra

• Para processamento contínuo de big data, o I/O de disco (1,5GB/s) e os 8GB de memória são fatores limitantes
  • Modelos Air e Pro (3–6GB/s) ou notebooks baseados em outros sistemas operacionais podem ser mais adequados
• Porém, quando o DuckDB roda na nuvem e a máquina local é usada como cliente, o MacBook Neo é suficientemente útil
  • Ele também consegue lidar de forma estável com processamento local esporádico de dados

Conclusão

• Mesmo sendo um notebook de entrada, o MacBook Neo consegue completar workloads de dados em grande escala com DuckDB
• Mesmo em comparação com ambientes em nuvem, as vantagens do SSD local aparecem com clareza
• Ele é avaliado como um dispositivo de especificação mínima capaz de oferecer portabilidade e desempenho experimental para desenvolvedores e analistas de dados

[GN⁺]

Comentários do Hacker News

• Eu queria tentar fazer um “trabalho de desenvolvimento de verdade” com esse pequeno MacBook Neo
  Criei vários apps iOS com um M1 MacBook Air e passei por dois processos de aquisição de startup
  Também editava vídeos de corrida em 4K de 30–45 minutos no FCP sem problemas, e o Neo mostra desempenho melhor que aquele Air

  • Antigamente eu desenvolvia backend em PHP e frontend em jQuery em um notebook usado com teclado norueguês
    Os projetos que fiz nele acabaram me ajudando a conseguir meu primeiro emprego como desenvolvedor, e foi naquele dia que conheci o Hacker News pela primeira vez
    No fim, o que importa é capacidade de execução, não hardware
  • Durante as férias, em vez de notebook, desenvolvi usando uma combinação de Galaxy S22 + adaptador HDMI + teclado Bluetooth
    Conectei à TV e fiz desenvolvimento em Elixir com neovim e termux, e os testes terminavam em 5 segundos
    Os builds em Rust eram lentos, mas, graças à portabilidade e à eficiência de bateria, foi uma experiência bem agradável
  • Ainda uso um Intel MacBook Pro (16GB) de 2019
    Aguenta bem Xcode builds, Docker, Claude Code e Codex rodando ao mesmo tempo
    Mas o barulho da ventoinha é nível turbina de avião, então encomendei um novo M5 Max 16" MBP (48GB)
    Como faço upgrade em ciclos de 7 anos, provavelmente vou usar este por muito tempo também
  • Passei 1 ano compilando apps iOS em um M1 Mac Mini (8GB)
    Durante os builds ele dava umas travadinhas, e ao alternar para o Firefox a troca de abas ficava lenta, mas era totalmente viável
    Fazendo o mesmo trabalho em um Intel MacBook Pro (16GB), tudo parecia muito mais suave e confortável
    A diferença percebida na responsividade do sistema era grande
  • As pessoas frequentemente subestimam 8GB de memória
    Graças à memória comprimida, na prática dá para acomodar 2–3x mais dados, e, com SSD NVMe, a leitura de swap também é rápida
    Na verdade, o que mais faz falta é não ter retroiluminação no teclado

• Quando dou aula, classifico os dados assim — se cabem inteiramente na memória de uma máquina, são Small data; se cabem no disco, são Medium data; acima disso, são Big data
  Recentemente, ao modernizar um app Python de 20 anos, deixei o backend substituível por polars ou duckDB, e a velocidade aumentou de 40x a 80x
  Isso levou só dois dias

  • Hoje em dia dá para colocar até 64TB de RAM DDR5 em um único sistema, então, se não for escala de data lake, quase tudo vira Small data
  • Fiquei curioso sobre o motivo de uma diferença de velocidade tão grande com polars
    Quando usado corretamente ele é rápido, mas, se for mal utilizado, o desempenho pode cair bastante
  • Um link clássico, mas ainda válido: Your Data Fits in RAM
    Mesmo sendo caro, a maioria dos problemas ainda cabe na RAM
  • Graças ao NVMe, o acesso a disco ficou tão rápido que a definição de ‘Medium data’ também ficou ambígua
    A infraestrutura de Big Data no estilo dos anos 2000 agora parece ultrapassada

• Vi o post de benchmark mobile do DuckDB e isso reduziu minha confiança
  Comparar um app em Swift com um app CLI pareceu comparar maçãs com bananas

  • Mas aquele experimento estava rodando um app CLI local em smartphone
    Não era uma comparação entre iPhone e Android, e sim com um sistema de artigo de pesquisa sobre processamento vetorizado de consultas

• Isso também é uma crítica ao desempenho de computação da AWS

  • A AWS usou armazenamento em rede EBS, então a latência é muito maior que em um barramento PCIe local
    Especialmente em cargas com acesso aleatório, isso faz uma grande diferença
  • Mesmo assim, a AWS não era mais rápida que o notebook?
    Só porque o disco em rede era lento, é difícil criticar a AWS como um todo
    A AWS também tem instâncias com SSD local
  • Mas a nuvem continua cara demais
    Meu notebook com M1 Max supera a maioria das instâncias em nuvem
    O preço de banda pode ter diferença de até 10 mil vezes, e agora a maior parte da geração de desenvolvedores só conhece cloud SaaS
    Vi essa mudança acontecer em tempo real
  • Na verdade, o artigo dizia o contrário
    “Se você faz trabalho de Big Data todos os dias no notebook, o Neo não é adequado”
    “Mas, se você roda DuckDB na nuvem e usa o notebook como cliente, ele é excelente” era a ideia principal

• Sou um ecologista pobre, mas consigo fazer todo o meu trabalho em R e Word neste pequeno computador
  Estou muito satisfeito com a qualidade de construção bem-acabada pelo preço

  • Você pesquisa moluscos por acaso?
    É uma pena que a maioria dos programas de pesquisa de moluscos financiados pelo governo na nossa região tenha acabado
  • Mas você já comprou? Eu achava que ainda estava em pré-venda

• Eu realmente adoro o DuckDB
  Fiz uma PoC na AWS Lambda para processar dados armazenados em GZ no S3,
  e substituí 400 linhas de código C# por 10 linhas
  É uma ferramenta open source impressionante

  • Acho que é um dos melhores presentes open source que surgiram nos últimos anos

• As pessoas que dizem “o que dá para fazer com 8GB em 2026?” deveriam muito ler um texto como este

• Gostaria que mais empresas fizessem esse tipo de demonstração de desempenho em hardware comum
  É útil mostrar quanto de carga ele realmente consegue suportar

• Na hora de benchmark, deveriam ter usado uma instância com NVMe local (c8gd.4xlarge)

  • Boa observação, então refiz os testes com c8gd.4xlarge (950GB NVMe) e c5ad.4xlarge (configuração RAID 0)
    Também comparei com os resultados do meu MacBook M1 Max local (64GB, 10 núcleos)
    No fim, o M1 Max continua mais rápido que as instâncias em nuvem
    Com um M5 Pro/Max mais recente, a diferença deve ser ainda maior
  • Mas o NVMe local da AWS é armazenamento volátil, então é preciso subir os dados de novo toda vez
    Ainda assim, para fins de benchmark, isso é até o ideal
  • Só que, em caso de queda total de energia na região, ainda não está claro se a persistência dos dados é garantida
    Se você quiser durabilidade total, ainda vai precisar de WAL streaming

• Foi bom ver alguém identificar de imediato que a instância em nuvem usava disco de rede
  Nesse caso, fiquei curioso para saber por que não refizeram o benchmark com instâncias de armazenamento local (c8id.2xlarge, c8id.4xlarge)

[dkang]

Parece que apareceu um comentário perguntando se o identificador da ecóloga pobre era clamlady porque ela pesquisava moluscos (achei que “clam” podia ter sido uma tradução equivocada, então entrei para ver o original por curiosidade).