AliSQL - le fork open source de MySQL par Alibaba, avec intégration des moteurs vectoriel et DuckDB

 (github.com/alibaba)
10 points par GN⁺ 2026-02-05 | 1 commentaires | Partager sur WhatsApp
  • Branche open source basée sur MySQL développée par Alibaba Group, avec un moteur de base de données unifiant les fonctions OLTP et OLAP
  • Intègre le moteur colonnaire DuckDB pour offrir des performances jusqu’à 200 fois supérieures sur les requêtes analytiques
  • Prend en charge la recherche vectorielle basée sur HNSW et le traitement d’embeddings IA/ML jusqu’à 16 383 dimensions
  • 100 % compatible avec les outils et drivers MySQL existants, utilisable immédiatement sans apprentissage supplémentaire
  • Technologie validée dans l’environnement de production à grande échelle d’Alibaba Cloud, mise en avant comme une base de données unifiée pour les charges de travail IA et analytiques

Présentation d’AliSQL

  • AliSQL est une branche enterprise de MySQL développée par Alibaba Group, qui intègre le moteur OLAP DuckDB et des fonctions natives de recherche vectorielle
    • Système validé par l’exploitation de millions de bases de données dans l’environnement de production d’Alibaba
  • Combine la stabilité OLTP d’InnoDB de MySQL et les performances analytiques élevées de DuckDB
  • Toutes les fonctionnalités sont accessibles via les interfaces MySQL existantes

Performances et caractéristiques principales

  • Le DuckDB Storage Engine est un moteur OLAP colonnaire, avec compression automatique et optimisation pour les charges de travail analytiques
    • Offre une vitesse de traitement des requêtes analytiques jusqu’à 200 fois plus rapide qu’InnoDB
  • Vector Index (VIDX) prend en charge le stockage vectoriel et la recherche approximative des plus proches voisins (ANN) sur la base de l’algorithme HNSW
    • Prend en charge les calculs de distance COSINE et EUCLIDEAN, et peut traiter des vecteurs jusqu’à 16 383 dimensions
  • Maintient une compatibilité MySQL à 100 %, permettant de réutiliser SQL, drivers et outils existants tels quels

Feuille de route de développement

  • D’ici le 4e trimestre 2025 : finalisation du moteur DuckDB, de Vector Index et de la publication open source
  • Fonctionnalités prévues à partir de 2026
    • Optimisation DDL : DDL instantané, création parallèle d’arbres B+, verrous non bloquants
    • Optimisation RTO : reprise après crash rapide, RTO minimal
    • Replication Boost : flush Binlog parallèle, Binlog in Redo, optimisation des transactions volumineuses

Exemples d’utilisation

  • Création et requêtes sur des tables analytiques DuckDB
    • Après création d’une table avec le moteur DuckDB, une requête d’agrégation des ventes mensuelles est traitée jusqu’à 200 fois plus vite qu’avec InnoDB
  • Recherche vectorielle pour les applications d’IA
    • Après création d’une table incluant une colonne vectorielle de 768 dimensions, exécution d’une recherche de similarité basée sur la distance cosinus via un index HNSW

Open source et communauté

  • Publication en open source en décembre 2025 ; développement, administration et maintenance assurés principalement par l’équipe Alibaba Cloud Database
  • Distribué sous licence GPL-2.0, identique au modèle de licence de MySQL
  • Signalement de bugs et propositions de fonctionnalités possibles via GitHub Issues
  • Service commercial proposé sur Alibaba Cloud RDS sous forme d’instances analytiques basées sur DuckDB

À lire aussi

1 commentaires

 
GN⁺ 2026-02-05
Commentaires sur Hacker News

  • L’approche consistant à utiliser DuckDB comme moteur de stockage est intéressante
    Elle permet de conserver telles quelles les connexions MySQL existantes, l’outillage et l’architecture de réplication, tout en routant uniquement les requêtes analytiques vers un moteur en colonnes
    Sur le plan opérationnel, c’est bien plus simple que de déployer une base analytique séparée et de construire un pipeline de synchronisation
    La question clé reste toutefois de savoir comment maintenir la cohérence des données entre InnoDB et DuckDB

    • Présente une méthode pour implémenter des nœuds Columnar Store (DuckDB) en lecture seule à l’aide du mécanisme de binlog de MySQL
      Les détails sont résumés dans la documentation AliSQL DuckDB
      Diverses optimisations ont été réalisées pour le transfert par lots du binlog, les opérations d’écriture, etc.
    • Utilise une réplication basée sur GTID pour résoudre les problèmes de cohérence des données
      Lorsque log_bin est désactivé, la transaction DuckDB est validée avant l’enregistrement du GTID, puis réappliquée de manière idempotente lors de la reprise après incident
      Lorsque log_bin est activé, le binlog est utilisé directement, et une position de binlog valide est enregistrée dans DuckDB afin de pouvoir revenir à cette position en cas d’échec
      En conséquence, si le gtid_executed de la réplique correspond à celui du primaire, les données DuckDB sont elles aussi cohérentes

  • Voit l’évolution des bases de données SQL sur les 10 prochaines années en trois étapes

    1. intégrer un moteur OLAP au moteur OLTP existant et transférer les requêtes
    2. repenser les deux moteurs pour qu’ils utilisent une couche de stockage commune
    3. fusionner finalement complètement les moteurs, avec une architecture capable de compresser et d’archiver automatiquement les anciens enregistrements, puis de les recharger depuis un stockage distant si nécessaire
      Seule la consultation des anciennes données serait légèrement plus lente, tandis que tout le reste offrirait une expérience de requête totalement unifiée

  • Se demande quelles seraient les différences par rapport à pg_duckdb
    Grâce au mécanisme d’extension de Postgres, pg_duckdb semble assez élégant

    • (commentaire supprimé)

  • Se demande si ce système, à l’image de SAP HANA, alimente DuckDB en temps réel avec les données des charges transactionnelles
    Si c’est le cas, cela réduirait fortement la complexité des synchronisations d’entrepôts de données via Kafka ou Debezium
    Souhaiterait aussi avoir l’avis d’apavlo

  • On a l’impression que l’ère du HTAP est vraiment en train d’arriver
    Il est intéressant de voir ces bases de données hybrides être adoptées progressivement
    Les améliorations du traitement transactionnel décrites dans la documentation AliSQL DuckDB sont particulièrement impressionnantes
    Le fait de garantir rapidement la synchronisation entre tables de base et tables analytiques, au niveau transactionnel, est remarquable

    • Mais il s’agit moins d’un véritable HTAP que d’une forme où deux bases sont regroupées derrière une seule interface
      Les garanties de cohérence ne diffèrent pas énormément de systèmes comme Materialize
      En réalité, ce type de tentative existe depuis longtemps, et il y a déjà eu de nombreux cas d’ajout de moteurs de stockage OLAP à MySQL/Postgres

  • Ajouter un moteur en colonnes embarqué à une base traditionnelle présente de grands avantages en matière de productivité et de simplicité opérationnelle
    J’utilise actuellement une combinaison PG + Tiger Data, et il n’existait pas de véritable alternative de ce type côté MySQL
    Cette tentative pourrait combler ce manque

    • MariaDB dispose déjà du moteur ColumnStore
      Un type de stockage vectoriel y a récemment été ajouté, ce qui rend la comparaison des performances avec l’implémentation d’Alibaba intéressante
      On parle souvent de Postgres, mais MariaDB est elle aussi assez polyvalente
    • ClickHouse prend en charge nativement le protocole MySQL, et peut aussi encapsuler ou importer des tables MySQL
      Il faut certes deux connexions, mais cela fonctionne plutôt bien
    • Se demande s’il est possible d’utiliser Tiger Data comme simple column store
      Il n’a besoin que de count rapides comme avec ClickHouse, mais devoir passer par tout le processus de synchronisation est contraignant
      TimeSeries est optimisé pour des usages spécifiques, ce qui le rend moins adapté à un usage général
    • TiDB est également une option
      Il prend en charge à la fois les données orientées lignes et orientées colonnes, mais il est seulement compatible MySQL sans partager la même base de code
      Ce n’est donc pas une extension complète de MySQL
    • MariaDB prend déjà en charge les tables en colonnes

  • Se demande à quel point il serait facile de déployer cette fonctionnalité avec MySQL Operator

    • Ne l’a pas encore essayé, mais prévoit de tester plus tard une intégration avec mysql-operator

  • À première vue, cela ressemble à une version plus étroitement intégrée des FDW de PSQL avec DuckDB et Vector Storage
    Cela rappelle aussi Vespa, d’où l’intérêt de comprendre pourquoi ils ont choisi une extension MySQL plutôt qu’une approche FDW

    • Probablement parce qu’ils utilisaient déjà des millions de lignes de code MySQL

  • L’historique des commits semble étrange
    Il n’y a que deux commits en 2022 et quelques-uns entre 2024 et 2026, alors que le premier commit est « First commit, Support DuckDB Engine »

    • Il est probable que le développement ait eu lieu en interne et en privé, puis que seuls les commits minimaux aient été nettoyés pour la publication
      La version interne contenait peut-être des références Jira, des informations produit, des commentaires en chinois, etc.
      Ils semblent donc avoir recréé un historique git propre pour la version publique

  • Se demande ce qu’il se serait passé si TiDB avait utilisé DuckDB au lieu de ClickHouse

    • Si DuckDB avait existé comme open source stable vers 2020, TiDB aurait certainement choisi DuckDB plutôt que ClickHouse