Os Limites Práticos do DuckDB em Hardware de Consumo

O DuckDB não é só rápido: ele é projetado para não travar sua RAM. Em vez de carregar tudo na memória, ele processa dados em blocos, faz spill para disco quando necessário e limita o uso padrão a 80% da RAM física, o que explica por que, mesmo com 50 milhões de linhas, consome só 1,2 GB em um notebook de 16 GB. Essa arquitetura de streaming permite consultas interativas mesmo em hardware modesto, mas revela uma tensão técnica real: funções de janela exigem ordenação e manutenção de estado entre linhas, o que dificulta a vetorização total. As otimizações lançadas em 2023 (v0.9.0) e 2025 melhoraram isso, mas não eliminaram a curva de degradação, ela só foi empurrada para além de 10 milhões de linhas.

A nova versão 1.5.0, lançada no mesmo dia da notícia (9/3/2026), traz suporte nativo a VARIANT e GEOMETRY, mas não resolve o gargalo de janelas. Em vez disso, reforça o foco do projeto: não competir com data warehouses distribuídos, mas entregar o melhor possível dentro de um único processo, com zero setup e integração nativa com formatos como Parquet e Iceberg (agora com escrita completa). Isso torna o DuckDB menos um substituto do Spark e mais um acelerador de etapas críticas em pipelines locais, como validação de qualidade antes do load ou análise exploratória de subconjuntos amostrados.

Para engenheiros de dados e analistas que operam em ambientes com restrições orçamentárias ou de infraestrutura, saber onde o DuckDB entrega interatividade, e onde começa a exigir trade-offs, evita surpresas em produção. Se sua pipeline depende de ROW_NUMBER() ou LAG() em tabelas de 30M+ linhas, você ainda precisará de pré-agregação, materialização ou migração para ambiente com mais RAM ou paralelismo distribuído. Mas se seu fluxo gira em torno de GROUP BY rápidos, percentis em subconjuntos ou JOINs entre CSVs e Parquets locais, o DuckDB opera com a eficiência de um motor embarcado, sem servidores, sem licenças, sem operação.