O maior recurso do DuckDB também era seu maior gargalo
O DuckDB conquistou sua reputação como um poderoso banco de dados analítico baseado em arquivo. Assim como o SQLite, ele é executado de forma embarcada em um aplicativo, eliminando a necessidade de configurar um servidor separado. Esse design o tornou extremamente atraente para cargas de trabalho analíticas leves e em processo.
No entanto, essa natureza embarcada trouxe uma ressalva importante: a concorrência. Cada processo de aplicativo mantém em memória seu próprio estado em cache do banco de dados. Embora seja eficiente para um único processo, essa arquitetura significa que apenas um processo pode gravar em um arquivo de banco de dados por vez. O DuckDB não conseguia manter sincronizados os estados em cache de vários processos.
Imagine uma equipe que executa vários serviços, dashboards e aplicativos, todos precisando acessar e atualizar os mesmos dados analíticos. Com o DuckDB tradicional, ela enfrentava um dilema: construir por conta própria uma camada de compartilhamento complexa para coordenar as gravações ou escolher um banco de dados totalmente diferente.
Esse gargalo obrigou muitos a contornar os principais pontos fortes do DuckDB. Alguns usuários chegaram a executar o DuckDB dentro do PostgreSQLQL para obter acesso compartilhado. Justamente o recurso que tornou o DuckDB tão acessível — sua natureza embarcada e sem servidor — tornou-se sua maior limitação em ambientes colaborativos.
O Quack dá ao DuckDB uma porta de entrada, não um novo mecanismo de armazenamento
O Quack, introduzido em caráter experimental em maio, dá ao DuckDB uma porta de entrada. Uma instância do DuckDB abre o arquivo do banco de dados e atua como o servidor. Outras instâncias do DuckDB se conectam a ela por HTTP simples, enviando suas leituras e gravações. Isso permite que vários aplicativos interajam com o banco de dados de forma concorrente.
É fundamental que o servidor continue sendo o único processo a acessar diretamente o arquivo do banco de dados. Essa arquitetura evita os riscos da gravação irrestrita de arquivos por vários processos, em que caches concorrentes poderiam levar à corrupção. Em vez disso, os clientes compartilham o acesso por meio de um coordenador, garantindo a integridade dos dados e ampliando a acessibilidade.
A equipe do DuckDB observou que muitos usuários já criavam wrappers personalizados ou até executavam o DuckDB dentro do PostgreSQLQL para obter acesso compartilhado leve. O Quack, agora um recurso consolidado no DuckDB 2.0, oferece uma solução nativa e oficialmente suportada para esse caso de uso comum. Ele permite que desenvolvedores habilitem o acesso de vários clientes sem recorrer a soluções improvisadas, muitas vezes frágeis.
Essa nova capacidade de servidor não muda a identidade central do DuckDB como banco de dados analítico baseado em arquivo. Ela apenas acrescenta uma opção robusta e nativa de acesso coordenado. Por exemplo, o DuckDB pode transferir 60 milhões de linhas entre duas máquinas em menos de 5 segundos usando o Quack, superando significativamente o protocolo do PostgreSQLQL, que levou mais de 2,5 minutos para a mesma tarefa. Embora gravações minúsculas se estabilizem em cerca de 5.500 por segundo com 8 threads, isso é suficiente para vários serviços que compartilham um dashboard.
Sessenta milhões de linhas em cinco segundos é o dado que chama a atenção
A demonstração mais marcante do Quack envolve as velocidades de transferência de dados. Em um vídeo da Better Stack, a equipe do DuckDB enviou 60 milhões de linhas entre duas máquinas em menos de cinco segundos usando o Quack. Para comparação, o protocolo do PostgreSQLQL levou mais de dois minutos e meio (mais de 150 segundos) para a mesma operação.
Esse benchmark destaca a vantagem do Quack para cargas de trabalho analíticas. Ao contrário dos protocolos tradicionais de bancos de dados orientados a linhas, o Quack transfere diretamente por HTTP cargas nativas do DuckDB em vetores de colunas. Isso evita a sobrecarga considerável de converter dados orientados a colunas em formatos linha a linha e depois reconvertê-los, o que é típico de muitos protocolos de rede de bancos de dados.
O ganho de velocidade é significativo em transferências analíticas, nas quais mover grandes conjuntos de dados com eficiência é fundamental. Embora impressionante, lembre-se de que este é um benchmark relatado. O desempenho no mundo real pode variar conforme:
- Sua carga de trabalho específica
- As condições da rede
- As configurações de hardware
- Os formatos das consultas
Para um aprofundamento sobre como o Quack alcança esse resultado, incluindo seus princípios de projeto, consulte a documentação oficial em Quack: The DuckDB Client-Server Protocol. Esse protocolo é um divisor de águas, mas é essencial entender seus pontos fortes e limitações específicos para o seu caso de uso.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
O teto de 5.500 gravações indica quando parar
O Quack se destaca na movimentação de grandes conjuntos de dados analíticos, mas é fundamental entender seus limites em cargas transacionais. Benchmarks mostram o modo servidor do DuckDB superando o PostgreSQLQL em pequenas gravações até cerca de oito threads simultâneas. A partir daí, o desempenho se estabiliza perto de 5.500 gravações por segundo.
Esse teto existe porque o servidor DuckDB, embora permita vários clientes, ainda depende de um único processo para realizar todas as gravações em arquivo. Pense nele como um único caixa altamente eficiente atendendo muitos clientes; ele só consegue processar um certo número de transações por segundo.
Essa arquitetura é ideal para análises compartilhadas, dashboards e serviços que se beneficiam de um hub DuckDB central e simples, especialmente quando a movimentação rápida de grandes volumes de dados é uma prioridade. Ela simplifica a ingestão de dados e as consultas complexas entre aplicativos.
No entanto, sistemas transacionais de alta frequência, nos quais cada gravação precisa ser processada de imediato e de forma concorrente, considerarão esse gargalo de processo único limitante. Para cenários exigentes de OLTP (Online Transaction Processing), o PostgreSQLQL ou outro banco de dados OLTP dedicado continua sendo a escolha mais apropriada. O DuckDB 2.0 também inclui outras melhorias de armazenamento e de consultas, mas o design do Quack é a consideração principal para gravações concorrentes.
Perguntas frequentes
O que é o Quack no DuckDB 2.0?
Quack é o protocolo cliente-servidor do DuckDB. Ele permite que instâncias cliente enviem consultas e gravações por HTTP a um processo DuckDB que detém o arquivo do banco de dados.
Vários aplicativos podem gravar no mesmo banco de dados DuckDB?
Sim. Com o Quack, vários clientes podem enviar trabalho a uma única instância de servidor, que é o único processo a acessar diretamente o arquivo do banco de dados.
O DuckDB 2.0 substitui o PostgreSQL?
Não. O modo servidor do DuckDB é adequado para análises compartilhadas e cargas de gravação moderadas; o PostgreSQL costuma ser a melhor opção para cargas transacionais exigentes e de alta concorrência.
Qual é a velocidade do DuckDB Quack?
O vídeo relata a transferência de 60 milhões de linhas entre duas máquinas em menos de cinco segundos. A taxa de transferência de pequenas gravações, segundo o relato, se estabiliza em cerca de 5.500 gravações por segundo.