Resumo executivo

O MotherDuck amplia o desempenho analítico do DuckDB para a cloud recursos colaborativos, oferecendo um desempenho quatro vezes mais rápido que o BigQuery e economia de custos em relação data tradicionais por meio de uma estrutura de preços sem servidor e com cobrança por uso. Após o anúncio da nova cloud europeia do MotherDuck, ficamos impressionados com seu desempenho e preços atraentes. O MotherDuck já pode ser integrado às suas camadas de produção para acelerar o atendimento de casos data e, ao mesmo tempo, reduzir custos. Veja o benchmark de desempenho.

Introdução

No cenário em rápida evolução da data , um novo participante está desafiando a ordem estabelecida dosdata cloud . MotherDuck, construído com base no DuckDB, promete oferecer desempenho de nível empresarial com a simplicidade e a economia que data modernas tanto desejam. Mas será que esse pato consegue realmente competir com os gigantes já estabelecidos?

Submetemos o MotherDuck a testes rigorosos em comparação com concorrentes consagrados para verificar se ele faz jus ao hype. O que descobrimos desafia o status quo atual das bases de dados analíticas e sugere uma mudança fundamental na forma como abordamos data cloud. Esta é a história de como uma base de dados incorporada aprendeu a voar e por que ela pode muito bem revolucionar sua data .

Para atender a esse cliente em constante evolução, os varejistas precisam se adaptar rapidamente.

Um pato em fase de incubação

MotherDuck se descreve como umdata cloud DuckDB com capacidade para terabytes, voltado para análises e BI voltados ao cliente”. Para entender o que torna essedata cloud especial, precisamos primeiro examinar DuckDB, o sistema de banco de dados de código aberto que vem revolucionando discretamente a data nos últimos anos. Em termos simples, o DuckDB é um sistema de banco de dados SQL OLAP in-memory. Para quem não vive e respira jargão de banco de dados, vamos explicar o que isso realmente significa:

OLAP significa Processamento Analítico Online. Pense nisso como um banco de dados projetado para processar grandes quantidades de data responder rapidamente a questões comerciais complexas. Ao contrário dos bancos de dados tradicionais, que se destacam na localização de registros individuais (como consultar o pedido de um cliente), os bancos de dados OLAP são construídos para analisar milhões de linhas e realizar cálculos complexos em segundos. Eles alcançam essa velocidade armazenando data colunas, em vez de linhas, tornando extremamente rápido analisar tendências, calcular médias ou somar vendas em conjuntos de dados inteiros. Essa é a mesma abordagem usada por data modernos, como o BigQuery ou o Snowflake. Por outro lado, temos os bancos de dados OLTP (Processamento de Transações Online), como PostgreSQL, SQLite ou MySQL. Esses são os motores que alimentam suas aplicações, lidando com milhares de leituras e gravações individuais por segundo para manter seu aplicativo funcionando sem problemas. Saiba mais sobre OLAP x OLTP.

Para compreender o quão revolucionária é realmente a abordagem do DuckDB, precisamos dar um passo atrás e analisar como chegamos até aqui. Em meados da década de 1990, quando gigantes da web como o Yahoo e a Amazon surgiram com força total, eles se depararam com um obstáculo que viria a remodelar todo o data . Essas empresas estavam afogadas em data — o que mais tarde chamaríamos de “big data— e seus sistemas existentes simplesmente não conseguiam acompanhar o ritmo. A solução? Infraestruturas monolíticas e caras, capazes de lidar com essa escala. Mas, à medida que os custos de hardware despencaram na década de 2000, surgiu uma nova filosofia: em vez de comprar máquinas maiores, por que não usar muitas máquinas menores e mais baratas? Esse pensamento deu origem a sistemas distribuídos como o MapReduce e o Apache Hadoop, tecnologias projetadas para distribuir cargas de trabalho por clusters de hardware comum. A Amazon aproveitou essa tendência, transformando essas tecnologias distribuídas em serviços e lançando o Amazon Web Services, a primeira grande cloud . Durante anos, esse se tornou o manual padrão: quando você se deparava com um data , distribuía-o por mais máquinas (Fundamentals of Data , Joe Reis & Matt Housley).

Mas eis o que é fascinante: enquanto todos estavam ocupados criando sistemas distribuídos, outra coisa acontecia discretamente nos bastidores. As mesmas forças que tornaram a computação distribuída econômica também tornaram as máquinas individuais incrivelmente poderosas. Seu laptop hoje se tornou incrivelmente poderoso, com mais RAM, processadores mais rápidos e melhor armazenamento. Os desenvolvedores por trás do DuckDB reconheceram essa oportunidade negligenciada: e se, em vez de sempre expandir horizontalmente, pudéssemos escalar verticalmente de forma mais inteligente? E se pudéssemos resolver muitos data sem a complexidade dos sistemas distribuídos?

Um dos mecanismos de banco de dados mais utilizados no mundo, o SQLite adota uma abordagem radicalmente diferente das bases de dados tradicionais. Enquanto o PostgreSQL e o MySQL funcionam como servidores separados aos quais os aplicativos se conectam por meio de uma rede, o SQLite é incorporado diretamente ao seu aplicativo como uma biblioteca leve. Não há servidor para configurar, nenhuma sobrecarga de rede e nenhuma configuração complexa, apenas funcionalidade pura de banco de dados local que é executada dentro do processo do seu aplicativo. Essa simplicidade, combinada com notável confiabilidade e velocidade, tornou o SQLite onipresente em tudo, desde aplicativos móveis até navegadores da web.

O DuckDB aplica essa mesma filosofia de integração às cargas de trabalho analíticas, provando que nem sempre é necessário um sistema distribuído para processar grandes conjuntos de dados. Assim como o SQLite revolucionou data local data , o DuckDB aproveita todo o poder da sua máquina local para tornar a análise simples novamente. A instalação leva apenas alguns segundos, não há dependências externas com as quais se preocupar e, de repente, você está executando consultas analíticas complexas em gigabytes de data iniciar uma única cloud .

O que torna o DuckDB particularmente atraente é a forma como ele atende às necessidades dos desenvolvedores. Precisa analisar um DataFrame do Python? O DuckDB pode consultá-lo diretamente. Quer processar um arquivo CSV? Sem problema. Essa integração perfeita, combinada com seu mecanismo colunar extremamente rápido, tornou o DuckDB um dos sistemas de banco de dados que mais crescem no setor de análise de dados. Os ganhos de desempenho costumam ser tão impressionantes que você chega a se perguntar por que estava usando sistemas distribuídos para começar. Se você quiser se aprofundar na filosofia técnica por trás dessa abordagem, recomendamos fortemente a leitura de Data Analíticos em Processo com o DuckDB” , do co-criador do DuckDB, Hannes Mühleisen.

Agora que você já entende o que é o DuckDB, vamos falar sobre suas limitações. Toda tecnologia tem suas vantagens e desvantagens. O DuckDB só pode ser executado em uma única máquina e aceita apenas uma conexão por vez. Em um mundo onde data criam soluções cloud que atendem a organizações inteiras, essa é uma restrição bastante significativa. Não é possível ter vários analistas consultando a mesma instância do DuckDB simultaneamente, e certamente não é possível compartilhar conjuntos de dados entre equipes da mesma forma que se faria com um data tradicional. Apesar de toda a sua velocidade e simplicidade, o DuckDB basicamente mantém seus data uma única máquina, acessíveis a apenas uma pessoa por vez. Então, como transformar esse banco de dados incrivelmente rápido, mas inerentemente de usuário único, em umdata cloud capaz de atender a uma organização inteira?

O pato que aprendeu a voar

É aqui que o MotherDuck entra em cena. O MotherDuck é um data sem servidor que preenche a lacuna entre o desempenho bruto do DuckDB e as necessidades de colaboração data modernas. O MotherDuck cria o que eles chamam de data de análise individualizado data , oferecendo a cada usuário sua própria instância de alto desempenho do DuckDB, ao mesmo tempo em que mantém a capacidade de compartilhar data a organização. Veja como funciona a arquitetura:

Nosdata tradicionais cloud , seu laptop é apenas um terminal passivo. Todo o trabalho pesado é feito em servidores remotos pelos quais você paga por hora. Mas a questão é a seguinte: seu MacBook provavelmente é mais rápido do que uma instância data que custa entre US$ 20 e US$ 60 por hora. O MotherDuck tenta aproveitar esse poder computacional com duas abordagens inovadoras: 

  • Análise baseada em navegador que leva o processamento diretamente ao usuário.
  • Execução dupla que combina de forma inteligente o poder de processamento do seu computador local com cloud para oferecer resultados mais rapidamente do que qualquer uma das abordagens conseguiria sozinha.

Antes de nos aprofundarmos nesses dois métodos, gostaria de salientar que o poder computacional do MotherDuck realmente se destaca quando aplicado à sua camada de ouro. Para quem não está familiarizado com o termo, a camada de ouro é o conjunto final data prontos para uso comercial, data limpos, agregados e enriquecidos. Essencialmente, são os conjuntos de dados refinados que alimentam suas análises, relatórios e aprendizado de máquina. Esses são os data orientam suas decisões comerciais mais críticas, o que torna o desempenho aqui absolutamente crucial. Todos os stakeholders já sofreram com painéis dolorosamente lentos, e todos os membros data já ficaram olhando para a roda giratória da morte enquanto esperavam que consultas complexas fossem concluídas. O MotherDuck enfrenta essa frustração de frente.

Análise no navegador

Esta solução aproveita o design leve e portátil do DuckDB, permitindo que ele seja executado diretamente no seu navegador por meio do WebAssembly (Wasm). Pense no Wasm como uma tecnologia que permite que softwares complexos sejam executados nativamente no seu navegador: sem plug-ins, sem downloads, apenas poder computacional onde você mais precisa. Com o DuckDB rodando no lado do cliente, você pode executar consultas analíticas complexas sem a rotina habitual de enviar solicitações a um servidor e aguardar respostas. O data ocorre diretamente no seu navegador, eliminando a latência da rede e reduzindo totalmente as dependências de infraestrutura. Você mesmo pode experimentar essa magia testando o o DuckDB no seu navegador.

Embora não vamos nos aprofundar na implementação técnica aqui, vale a pena destacar que o DuckDB-Wasm se destaca. Uma pesquisa detalhada neste este artigo mostra que ele supera significativamente as soluções existentes baseadas em navegador, como a versão Wasm do SQLite ou o Lovefield, um banco de dados baseado em JavaScript. Essa demonstração técnica inteligente sinaliza uma mudança fundamental na forma como pensamos sobre a localização do processamento analítico.

O MotherDuck oferece essa arquitetura baseada em Wasm, conforme explicado por Mehdi Ouazza em este artigo. Essa abordagem é particularmente poderosa para análises de camada de ouro. Sua data passa a trabalhar com data limpos e prontos para uso comercial, data se preocupar com a infraestrutura de back-end; o processamento ocorre localmente para máxima velocidade; e você alcança alguns dos tempos de resposta mais rápidos possíveis, eliminando totalmente a latência da rede. Além disso, você evita os altos custos computacionais quedata tradicionais cloud adoram cobrar por cada consulta. É uma proposta atraente: análises mais rápidas, custos mais baixos e arquitetura mais simples, tudo em um só lugar.

 

Execução dupla

Outra maneira de aproveitar o MotherDuck em sua camada de dados de ouro é por meio de sua capacidade de execução dupla, que combina de forma inteligente o poder de processamento local com cloud . Em vez de obrigar toda data a compartilhar os mesmos recursos computacionais, o MotherDuck oferece a cada usuário seu próprio “duckling”: uma instância de computação individual e sem servidor que se adapta às suas necessidades.

O verdadeiro poder da execução dupla se destaca quando você trabalha com data por diferentes fontes. Imagine que você precise consultar data no MotherDuck, combiná-los com arquivos no S3 e juntá-los a um conjunto de dados armazenado localmente em seu laptop. cloud tradicionais obrigariam você a fazer o upload de tudo para um único local antes de poder executar consultas entre fontes. A execução híbrida do MotherDuck é mais inteligente. Ela analisa sua consulta, mantém apenas os data necessários data cada fonte e realiza junções inteligentes entre locais, economizando seu tempo e custos data .

Nos bastidores, o otimizador do MotherDuck divide sua consulta em um DAG (grafo acíclico direcionado) de operações, estima o custo de executar cada nó localmente em comparação com remotamente e gerencia data automaticamente. Você apenas escreve o SQL; o MotherDuck determina a estratégia de execução ideal. Essa abordagem redefine fundamentalmente cloud . Não precisamos mais ficar presos à escolha entre a simplicidade local e cloud , cada uma com sua própria complexidade em relação data e à orquestração do fluxo de trabalho. Com o MotherDuck, você obtém o melhor dos dois mundos: execute localmente quando sua máquina puder lidar com isso, escale para a cloud necessário e compartilhe sem esforço em todo o processo. É uma solução sem servidor que reduz os custos cloud , pois você paga apenas pelo que realmente computa.

Mas é aqui que fica interessante: compartilhar data muito fácil. Lembra-se de como a natureza de usuário único do DuckDB tornava a colaboração complicada? Se um data criasse uma análise incrível, ele teria que exportar tudo e fazer o upload para um sistema de armazenamento compartilhado apenas para permitir que os colegas de equipe tivessem acesso a ela. Com o MotherDuck, compartilhar é tão simples quanto clicar em um botão ou executar uma única linha de código para criar um snapshot sem cópia com controles de acesso adequados. Sem data , sem duplicação de armazenamento, apenas colaboração instantânea.

Saiba mais sobre a execução de consultas duplas/híbridas no artigo da MotherDuck apresentado na Conferência sobre Pesquisa Data Inovadores (CIDR). Você também pode assistir a esta palestra sobre o dbt Coalesce de Jordan Tigani, cofundador e CEO da MotherDuck.

Patos na natureza

Vimos como o MotherDuck elimina uma carga significativa de trabalho data , ao mesmo tempo em que oferece recursos analíticos poderosos para sua camada de dados primários. Mas a teoria tem seus limites. Queríamos colocar o MotherDuck à prova contra os principais players no setordata cloud . Analisando o RelatórioData de 2025 publicado pela Metabase, descobrimos algo surpreendente: o PostgreSQL continua sendo a escolha de banco de dados mais popular, mesmo para cargas de trabalho analíticas, seguido pelo Snowflake e pelo BigQuery entre as empresas pesquisadas. Isso nos deu nossos alvos de comparação.

Decidimos comparar o MotherDuck com o PostgreSQL hospedado no Google Cloud no BigQuery, utilizando o Apache Superset como nossa ferramenta de BI preferida. O Superset fez sentido por várias razões: é de código aberto, amplamente adotado e possui compatibilidade nativa com o MotherDuck, assim como com a maioria dos outros bancos de dados importantes. Nosso ambiente de teste consistiu no Apache Superset implantado no Google Cloud Engine, conectado a três back-ends diferentes: BigQuery, PostgreSQL no Cloud e MotherDuck.

Estruturamos nossos testes em duas fases. Primeiro, executamos o benchmark TPC-H: um benchmark padronizado de apoio à tomada de decisões que nos mostraria o desempenho do MotherDuck em um ambiente controlado e teórico. Em seguida, aproximamo-nos da realidade, testando como a integração entre o Superset e o MotherDuck se comparava aos data tradicionais em cenários reais de painéis de controle.

Teste de desempenho TPC-H

O TPC-H é o padrão para testar o desempenho de bancos de dados analíticos. Trata-se de um benchmark de apoio à tomada de decisões projetado para examinar grandes volumes de data, executar consultas complexas e fornecer respostas a questões críticas de negócios em diversos setores. Você pode encontrar a especificação completa na documentação oficial. O benchmark consiste em 22 consultas que simulam cargas de trabalho analíticas do mundo real, desde simples agregações até complexas junções entre várias tabelas.

Executamos cada consulta individualmente no SQL Lab do Superset para os três bancos de dados: MotherDuck, BigQuery e PostgreSQL. Também testamos as consultas diretamente na GUI do MotherDuck para eliminar a latência cliente-servidor e porque, francamente, qualquer empresa que utilize o MotherDuck provavelmente teria seus data trabalhando na interface inspirada em notebooks do MotherDuck, em vez do SQL Lab do Superset. Além disso, o aplicativo do MotherDuck pode aproveitar a arquitetura WebAssembly que discutimos anteriormente, e estávamos curiosos para ver como essa execução baseada em navegador se sairia em comparação com os modelos tradicionais de servidor-cliente. Para garantir um teste justo, o cache do Superset foi desativado em todos os benchmarks.

Para este teste de desempenho, utilizamos o fator de escala TPC-H 10 (SF-10), que gera um conjunto de dados de 10 GB. Escolhemos o fator de escala 10 porque 10 GB representa um tamanho realista de conjunto de dados para as cargas de trabalho analíticas da maioria das empresas, grande o suficiente para revelar diferenças significativas de desempenho sem exigir uma infraestrutura de escala empresarial. Veja a seguir como os data pelas principais tabelas:

Utilizamos a extensão DuckDB TPC-H para gerar os data e, em seguida, os enviamos sem complicações para o MotherDuck. O processo levou apenas alguns minutos, graças aos recursos data do MotherDuck.

Aqui estão os resultados do TPC-H SF-10 em segundos. A coluna amarela mostra os resultados da interface de usuário nativa do aplicativo MotherDuck, enquanto as outras colunas representam o desempenho obtido através do SQL Lab do Superset (SST):

O MotherDuck oferece consistentemente um desempenho inferior a um segundo em todas as consultas: 21 das 22 consultas realizadas pelo Superset são concluídas em menos de um segundo, sendo que todas as consultas são concluídas em menos de um segundo quando executadas diretamente pelo aplicativo do MotherDuck. O BigQuery apresenta um desempenho respeitável, mas tem uma média cerca de 4 vezes mais lento que o MotherDuck em todo o conjunto de benchmarks. O PostgreSQL apresenta um quadro totalmente diferente, com desempenho significativamente mais lento e dificuldades evidentes em agregações e junções complexas. Isso era previsível, já que o PostgreSQL foi projetado fundamentalmente para cargas de trabalho OLTP, em vez de processamento analítico, mas o incluímos em nossa comparação porque continua sendo amplamente utilizado por empresas para tarefas analíticas. Vale a pena notar que o PostgreSQL poderia alcançar um desempenho muito melhor com técnicas de otimização adequadas, como indexação, particionamento ou visualizações materializadas, mas, mesmo assim, continuaria lutando contra sua arquitetura baseada em linhas. A diferença de desempenho destaca exatamente por que existem sistemas OLAP desenvolvidos especificamente para esse fim, como o MotherDuck: quando você está executando consultas analíticas complexas em conjuntos de dados substanciais, a arquitetura importa enormemente.

Embora o TPC-H mostre o desempenho bruto das consultas, o verdadeiro teste é como isso se traduz na experiência real do usuário em ferramentas de inteligência de negócios.

Desempenho do painel

Vimos que o desempenho foi excelente para data que trabalham com SQL em seu data , mas queríamos testar se essa melhoria se traduziria nos painéis de controle, onde as partes interessadas da empresa realmente interagem com os data. Afinal, consultas SQL extremamente rápidas não servem de muito se os painéis de controle ainda demoram uma eternidade para carregar.

Para testar isso, utilizamos um conjunto de dados realista de comércio eletrônico do Kaggle contendo 67,5 milhões de linhas em 9 GB de data, o tipo de escala com que muitas empresas trabalham para suas análises mensais de clientes. Usando essa única tabela, criamos um painel abrangente que testaria a capacidade de cada sistema de lidar com cargas de trabalho reais de inteligência de negócios:

Testei o painel exaustivamente em várias execuções, aplicando diversos filtros, medindo os tempos de carregamento, desativando o cache e monitorando os tempos de resposta por meio das ferramentas de desenvolvedor do meu navegador. Após vários ciclos de teste para garantir resultados consistentes, eis as métricas de desempenho do painel em segundos:

Nossos testes de carregamento de painéis revelam as implicações práticas do desempenho do banco de dados na experiência do usuário. O MotherDuck oferece uma capacidade de resposta excepcional dos painéis, com um tempo médio de carregamento de apenas 3,35 segundos, permitindo análises verdadeiramente interativas nas quais os usuários podem explorar data e sem atritos. Em contrapartida, o BigQuery leva 8,55 segundos para carregar o mesmo painel. Esse tempo ainda é aceitável para relatórios programados, mas gera atrasos perceptíveis que podem desestimular a análise exploratória. O tempo de carregamento de 216 segundos do PostgreSQL (>3 minutos) torna-o completamente impraticável para uso em painéis. Essa vantagem de desempenho do MotherDuck pode transformar fundamentalmente a forma como os usuários corporativos interagem com data. Quando os painéis carregam em segundos, em vez de minutos, a adoção pelos usuários dispara, os analistas podem iterar rapidamente sobre insights e a análise se torna uma vantagem competitiva, em vez de um gargalo.

Comparação de preços

A MotherDuck combina armazenamento com pagamento conforme o uso , otimizado para análises interativas. Como ele é escalonado em uma única máquina, em vez de ser distribuído por um cluster, evita custos indiretos que acabariam sendo cobrados dos usuários. Uma sessão com dezenas de consultas pode custar apenas US$ 0,05–US$ 0,10, enquanto uma equipe que executa milhares de consultas mensalmente pode gastar apenas US$ 20–US$ 40. Em contrapartida, bancos de dados sempre ativos podem custar de US$ 300 a US$ 500 por mês apenas para permanecerem em operação, e cloud costumam cobrar de US$ 5 a US$ 10 por TB analisado. Com seu design escalável, o MotherDuck mantém os preços simples, previsíveis e econômicos.

O MotherDuck pode parecer inicialmente mais caro devido à sua taxa de organização e ao modelo de preços de computação diferente. No entanto, ambos os sistemas utilizam modelos de preços que favorecem padrões de uso distintos: o BigQuery se destaca no processamento de grandes lotes, enquanto o MotherDuck é otimizado para análises interativas. Para nosso benchmark TPC-H, a execução de 22 consultas no SF-10 custou US$ 0,03 para o MotherDuck, contra US$ 0,60 a US$ 1,00 para o BigQuery. Ao levar em conta a sobrecarga de infraestrutura — nossa configuração do PostgreSQL exigia € 14/dia apenas para permanecer online —, a abordagem sem servidor do MotherDuck frequentemente oferece um custo total de propriedade superior para cargas de trabalho analíticas interativas.

Em escala empresarial, a relação custo-benefício varia de acordo com os padrões de uso. O BigQuery se torna mais econômico para o processamento em lote de volumes muito altos, enquanto o MotherDuck mantém sua vantagem para análises interativas e fluxos de trabalho exploratórios. A conclusão principal: escolha seu modelo de preços com base na forma como sua equipe realmente trabalha com data, e não apenas nos custos unitários brutos.

Observação: Todos os exemplos de preços se baseiam na região europe-west4 e devem ser considerados meramente ilustrativos, e não exatos, uma vez que os custos reais dependem fortemente dos padrões específicos de uso e data .

Conclusão

O MotherDuck representa uma mudança fundamental na forma como pensamos sobre bancos de dados analíticos, desafiando a suposição de que são necessários sistemas complexos e distribuídos para lidar com data pesadas. Ao adotar a filosofia de integração do DuckDB e estendê-la à cloud, o MotherDuck oferece os recursos colaborativos de que data modernas precisam, mantendo ao mesmo tempo o desempenho bruto que torna o DuckDB excepcional.

Os resultados de nossos testes comparativos revelam um quadro convincente: o MotherDuck superou consistentemente tanto o BigQuery quanto o PostgreSQL por margens significativas, oferecendo desempenho de consultas em menos de um segundo em conjuntos de dados de 10 GB e tempos de carregamento de painéis que permitem análises verdadeiramente interativas. A vantagem de desempenho em relação ao BigQuery e a vantagem ainda maior em relação ao PostgreSQL em cenários de painéis não se resume apenas a consultas mais rápidas, mas à transformação da análise em uma experiência mais interativa e exploratória que incentiva a tomada de decisões data.

Talvez o mais importante seja que o MotherDuck alcança esse desempenho ao mesmo tempo em que reduz drasticamente a complexidade e os custos da infraestrutura. Enquanto cloud tradicionais cloud exigem uma infraestrutura sempre ativa que custa centenas de dólares por mês, o modelo sem servidor do MotherDuck cobra apenas pelo uso efetivo, o que muitas vezes reduz os custos. O modelo de pagamento por computação se alinha perfeitamente à forma como os analistas realmente trabalham: executando várias consultas em sessões de exploração, em vez de solicitações isoladas e esporádicas.

As implicações vão além do simples desempenho e custo. O modelo de execução dupla do MotherDuck e seus recursos de análise baseados em navegador apontam para um futuro em que a fronteira entre cloud local e cloud se torna cada vez mais difusa. Em vez de obrigar as equipes a escolher entre a simplicidade local e cloud , o MotherDuck oferece ambas, direcionando de forma inteligente os cálculos para onde for mais adequado.

O que realmente me impressionou durante os testes foi a simplicidade de uso e configuração do MotherDuck. O modelo de execução dupla me permitiu consultar data localmente quanto na cloud , sem qualquer dificuldade, enquanto a configuração da conexão entre o Superset e o MotherDuck foi extremamente simples.

Para organizações que buscam modernizar suas capacidades analíticas a partir da camada de dados brutos, a MotherDuck oferece uma proposta muito atraente: desempenho de nível empresarial, fluxos de trabalho colaborativos e eficiência de custos, tudo isso sem os custos operacionais associados à infraestrutura tradicional data . Em um mundo onde as decisões data determinam cada vez mais a vantagem competitiva, a capacidade de explorar data em frações de segundo não é apenas um recurso desejável; está se tornando essencial.

Pronto para conferir a apresentação da MotherDuck? Você pode começar com um teste gratuito de 21 dias ou com o plano gratuito de 10 GB para testá-lo com seus próprios conjuntos de dados e cargas de trabalho. Se você estiver procurando orientação para saber se o MotherDuck se adapta à sua data específica ou precisar de ajuda com a implementação, entre em contato com nossa equipe em Artefact; teremos prazer em avaliar suas necessidades analíticas e ajudá-lo a fazer a transição para uma infraestrutura de análise mais eficiente e econômica.