AliSQL - fork open source do MySQL da Alibaba com integração de vetores e DuckDB

• Um branch open source baseado em MySQL desenvolvido pelo Alibaba Group, com um mecanismo de banco de dados que integra recursos de OLTP e OLAP
• Incorpora o engine colunar DuckDB, oferecendo até 200x mais desempenho em consultas analíticas
• Suporta busca vetorial baseada em HNSW e processa embeddings de IA/ML com até 16.383 dimensões
• 100% compatível com ferramentas e drivers MySQL existentes, podendo ser usado imediatamente sem aprendizado adicional
• Tecnologia validada em ambientes de produção de larga escala da Alibaba Cloud, ganhando destaque como um banco de dados unificado para workloads de IA e análise

---

Visão geral do AliSQL

• AliSQL é um branch de nível enterprise do MySQL desenvolvido pelo Alibaba Group, integrando o engine OLAP DuckDB e recursos nativos de busca vetorial
  • Um sistema validado pela operação de milhões de bancos de dados no ambiente de produção da Alibaba
• Combina a estabilidade OLTP do InnoDB do MySQL com o desempenho analítico de alta velocidade do DuckDB
• Todos os recursos podem ser acessados pela interface MySQL existente

Principais desempenhos e características

• O DuckDB Storage Engine é um engine OLAP colunar com suporte a compactação automática, otimizado para workloads analíticos
  • Oferece velocidade de processamento de consultas analíticas até 200x maior em comparação ao InnoDB
• O Vector Index (VIDX) oferece armazenamento vetorial e busca aproximada de vizinhos mais próximos (ANN) com base no algoritmo HNSW
  • Suporta cálculo de distância COSINE e EUCLIDEAN e processa vetores de até 16.383 dimensões
• Mantém 100% de compatibilidade com MySQL, permitindo usar SQL, drivers e ferramentas existentes sem mudanças

Roadmap de desenvolvimento futuro

• Até o 4º trimestre de 2025, conclusão do engine DuckDB, Vector Index e lançamento open source
• Recursos planejados para depois de 2026
  • Otimização de DDL: DDL instantâneo, criação paralela de árvore B+, locks não bloqueantes
  • Otimização de RTO: recuperação rápida de falhas, RTO mínimo
  • Replication Boost: Binlog Flush paralelo, Binlog in Redo, otimização para transações de grande volume

Exemplos de uso

• Criação e consulta de tabelas analíticas com DuckDB
  • Após criar uma tabela com o engine DuckDB, executar uma consulta de agregação de vendas mensais pode ser até 200x mais rápido que com InnoDB
• Busca vetorial para aplicações de IA
  • Após criar uma tabela com uma coluna vetorial de 768 dimensões, realiza busca por similaridade com distância cosseno por meio de um índice HNSW

Open source e comunidade

• Lançamento open source em dezembro de 2025, com desenvolvimento, gestão e manutenção liderados pela equipe de Database da Alibaba Cloud
• Distribuído sob a licença GPL-2.0, o mesmo modelo de licenciamento do MySQL
• Permite envio de relatórios de bugs e sugestões de recursos via GitHub Issues
• Serviço comercial disponível no Alibaba Cloud RDS como instância analítica baseada em DuckDB

[GN⁺]

Comentários do Hacker News

• A abordagem de usar o DuckDB como engine de storage é interessante
  Dá para manter as conexões, o tooling e a estrutura de replicação existentes do MySQL como estão, enquanto só as queries analíticas são roteadas para um engine colunar
  Em termos operacionais, isso é muito mais simples do que subir um banco analítico separado e criar um pipeline de sincronização
  Ainda assim, o ponto central é como manter a consistência dos dados entre InnoDB e DuckDB

  • É apresentado um método para implementar nós Columnar Store (DuckDB) somente leitura usando o mecanismo de binlog do MySQL
    Mais detalhes estão organizados na documentação do AliSQL DuckDB
    Foram feitas várias otimizações em envio em lote de binlog, operações de escrita e outros pontos
  • Para resolver o problema de consistência de dados, é usada replicação baseada em GTID
    Quando log_bin está desligado, a transação do DuckDB é confirmada antes do registro do GTID e, na recuperação de falhas, é reaplicada de forma idempotente
    Quando log_bin está ligado, o Binlog é usado diretamente, e uma posição válida do Binlog é registrada no DuckDB para que, em caso de falha, seja feito rollback até essa posição
    Como resultado, se o gtid_executed da réplica corresponder ao da primária, os dados no DuckDB também permanecem consistentes

• Vejo a evolução dos bancos de dados SQL nos próximos 10 anos em três etapas

  1. integrar um engine OLAP ao engine OLTP existente e encaminhar as queries
  2. redesenhar para que os dois engines usem uma camada de storage compartilhada
  3. no fim, fundir completamente os engines, evoluindo para uma estrutura que compacta e arquiva automaticamente registros antigos e, quando necessário, os carrega de storage remoto
     Só a consulta de dados antigos ficaria um pouco mais lenta; no restante, a experiência de consulta seria totalmente unificada

• Fico curioso sobre quais seriam as diferenças em comparação com o pg_duckdb
  Graças ao mecanismo de extensões do Postgres, o pg_duckdb parece bem elegante

  • (comentário apagado)

• Fico curioso se esse sistema, como o SAP HANA, alimenta dados de cargas transacionais em tempo real para o DuckDB
  Se for assim, o trabalho complexo de sincronizar um data warehouse com Kafka ou Debezium diminuiria bastante
  Também queria ouvir a opinião do apavlo

• Parece que a era do HTAP chegou de vez
  É interessante ver esses bancos de dados híbridos sendo adotados cada vez mais
  Em especial, as melhorias de processamento transacional descritas na documentação do AliSQL DuckDB são impressionantes
  É ótimo que a sincronização entre tabelas base e tabelas analíticas seja rápida e garantida no nível de transação

  • Mas isso parece mais uma forma de agrupar dois bancos sob uma única interface do que um HTAP de verdade
    A garantia de consistência não é tão diferente da de sistemas como o Materialize
    Na verdade, tentativas assim existem há tempos, e já houve muitos casos de anexar engines de storage OLAP ao MySQL/Postgres

• Anexar um engine colunar embutido a um banco tradicional traz grandes vantagens em produtividade e simplicidade operacional
  Hoje uso a combinação PG + Tiger Data, mas no lado do MySQL não havia uma alternativa desse tipo
  Esta tentativa parece capaz de preencher essa lacuna

  • O MariaDB já tem o engine ColumnStore
    Recentemente, também foi adicionado o tipo de storage vetorial, então é interessante comparar o desempenho com a implementação da Alibaba
    Postgres é citado com frequência, mas o MariaDB também é bastante versátil
  • O ClickHouse oferece suporte nativo ao protocolo MySQL e também pode encapsular ou importar tabelas MySQL
    São necessárias duas conexões, mas funciona muito bem
  • Fico curioso se o Tiger Data pode ser usado como um simples column store
    Preciso apenas de contagens rápidas como no ClickHouse, mas é incômodo ter que passar por todo o processo de sincronização
    TimeSeries é otimizado para usos específicos, então é difícil aplicá-lo de forma mais geral
  • O TiDB também é uma opção
    Ele oferece suporte tanto a dados baseados em linhas quanto em colunas, mas é apenas compatível com MySQL, e a base de código é diferente
    Portanto, não é uma extensão completa do MySQL
  • O MariaDB já oferece suporte a tabelas colunares

• Fico curioso sobre quão fácil seria implantar isso em conjunto com o MySQL Operator

  • Ainda não tentei, mas pretendo testar a integração com o mysql-operator mais tarde

• À primeira vista, isso parece uma versão mais fortemente integrada do FDW do PSQL com DuckDB e Vector Storage
  Também lembra o Vespa, então é interessante entender por que escolheram uma extensão do MySQL em vez da abordagem FDW

  • Provavelmente porque já usavam milhões de linhas de código do MySQL

• O histórico de commits está estranho
  Há só 2 em 2022 e alguns poucos entre 2024 e 2026, mas o primeiro commit é “First commit, Support DuckDB Engine”

  • É bem provável que o desenvolvimento tenha ocorrido internamente, de forma privada, e que apenas os commits mínimos tenham sido organizados para divulgação pública
    A versão interna talvez fosse complicada, com referências a Jira, informações de produto e comentários em chinês
    Por isso, parecem ter criado um novo histórico de git limpo para publicação

• Fico curioso sobre como teria sido se o TiDB tivesse usado DuckDB em vez de ClickHouse

  • Se o DuckDB existisse por volta de 2020 como um open source estabilizado, tenho certeza de que o TiDB teria escolhido DuckDB em vez de ClickHouse