Caso real: de QlikView a DuckDB e Parquet com paridade total e zero licenças
Este é o caso que mostramos nas apresentações, com os números que podem ser verificados. Está em produção desde 2026 numa empresa com vários centros de venda, cujo nome não divulgamos por acordo de confidencialidade. O que se segue é o que foi feito, como foi validado e o que mudou para quem usa os dashboards todos os dias.
O ponto de partida
A empresa tinha as suas análises de vendas, stock e pagamentos em QlikView. Os scripts de carga tinham anos de regras acumuladas: vendas com e sem IVA, valor de stock por centro, valor pago pelo cliente, valor médio por transação. Os dashboards eram usados pelas direções de cada centro e pela direção geral, com regras de acesso por perfil.
Três coisas pesavam na decisão:
- O QlikView 12.90 fica sem suporte a 31 de outubro de 2026, e a Qlik já não vende licenças novas de QlikView isolado.
- O custo crescia com os utilizadores. Cada pessoa nova com acesso ao dashboard era uma licença.
- Algumas agregações eram lentas. Uma análise por produto, feita diretamente em PostgreSQL, demorava cerca de 6 minutos.
O requisito foi claro desde o início: os utilizadores tinham de ver o mesmo dashboard, com os mesmos números, e o QlikView só se desligava quando isso estivesse provado.
O que foi construído
Arquitetura Medallion em PostgreSQL, com dbt. Cada script de carga e transformação do QlikView foi mapeado para uma camada da arquitetura Medallion. As tabelas, as chaves e as regras de negócio transitaram para SQL normal, documentado, com testes de dbt a correr em cada build. Os metadados e a linhagem ficaram no OpenMetadata.
Tabelas de reconciliação. Para cada métrica, uma tabela compara o valor calculado na nova arquitetura com o valor do QlikView, por centro e por mês. Foi esta tabela que guiou a migração: enquanto houvesse diferenças, não se avançava.
Uma geração Parquet por build. Cada build da arquitetura exporta os dados em ficheiros Parquet, em colunas, comprimidos. É um formato aberto, legível por qualquer ferramenta.
Um serviço DuckDB. Um serviço analítico carrega a geração Parquet ativa em memória e responde às agregações. É aqui que o tempo de resposta muda.
O dashboard dinâmico. Dimensões e métricas escolhidas num painel lateral, linha de totais, linhas para métricas que não se repartem por uma dimensão, relatórios guardados, exportação para Excel e CSV. Quem usava QlikView reconhece-o. As permissões por perfil e os filtros por centro são aplicados na API, não no browser.
Como foi validada a paridade
A validação foi feita entidade a entidade e mês a mês, de janeiro a agosto de 2026, para quatro famílias de métricas:
| Métrica | Granularidade | Resultado |
|---|---|---|
| Vendas com IVA e sem IVA | Por centro, por mês | Reconciliado com o QlikView |
| Valor de stock | Por centro, por mês | Reconciliado com o QlikView |
| Valor pago pelo cliente | Por centro, por mês | Reconciliado com o QlikView |
| Valor médio por transação | Por centro, por mês | Reconciliado com o QlikView |
As diferenças encontradas durante o processo tinham duas origens: regras de arredondamento diferentes entre o script QlikView e o SQL, e registos com datas fora do período que um dos lados filtrava e o outro não. Cada caso foi decidido com a empresa e documentado. No fim, as tabelas de reconciliação ficaram a zero.
O que mudou
| Aspeto | Antes | Depois |
|---|---|---|
| Agregação por produto | Cerca de 6 minutos em PostgreSQL | Segundos, no DuckDB sobre Parquet, enquanto o utilizador espera |
| Licenças | Por utilizador, no QlikView | Nenhumas. PostgreSQL, DuckDB e Parquet são open source |
| Posse dos dados | Ficheiros .qvd e .qvw | Tabelas em PostgreSQL e ficheiros Parquet |
| Quem mantém | Competências QlikView | SQL, dbt, .NET e React |
| Novas métricas | Pedido ao fornecedor ou ao consultor | Acrescentadas pela equipa interna em SQL |
O QlikView ficou ligado durante toda a migração. Não houve big bang, não houve fim de semana de corte, e nenhum utilizador teve de aprender uma ferramenta nova.
O que este caso prova e o que não prova
Prova que uma aplicação QlikView com anos de regras pode ser mapeada para componentes abertos com os mesmos números e melhor tempo de resposta, sem licenças por utilizador. Prova que a reconciliação mês a mês é o método certo para ganhar a confiança de quem usa os dashboards.
Não prova que todas as aplicações migram com o mesmo esforço. O inventário inicial é o que diz quantas tabelas, campos e regras existem, e quais pedem decisão. É por isso que o primeiro passo é sempre esse.
Veja nos seus próprios dados
A apresentação da QuickBytes corre sobre uma das suas aplicações reais, QlikView, Qlik Sense ou Power BI, não sobre uma amostra. Assinamos um NDA mútuo antes de qualquer partilha de dados, e quem faz a apresentação são engenheiros seniores, não comerciais. Agende 30 minutos.
Se ainda está a avaliar as opções, leia primeiro QlikView fim de suporte: o que muda em 2026 e as três opções que tem.