AliSQL - el fork open source de MySQL de Alibaba con integración de motores vectoriales y DuckDB

 (github.com/alibaba)
10 puntos por GN⁺ 2026-02-05 | 1 comentarios | Compartir por WhatsApp
  • Una rama open source basada en MySQL desarrollada por Alibaba Group, con un motor de base de datos que integra capacidades OLTP y OLAP
  • Incorpora el motor columnar DuckDB y ofrece hasta 200 veces más rendimiento en consultas analíticas
  • Soporta búsqueda vectorial basada en HNSW y procesa embeddings de IA y ML de hasta 16,383 dimensiones
  • 100% compatible con las herramientas y drivers existentes de MySQL, por lo que puede usarse de inmediato sin aprendizaje adicional
  • Tecnología validada en entornos de producción a gran escala de Alibaba Cloud, destacada como una base de datos unificada para cargas de trabajo de IA y analítica

Resumen de AliSQL

  • AliSQL es una rama de nivel empresarial de MySQL desarrollada por Alibaba Group que integra el motor OLAP DuckDB y capacidades nativas de búsqueda vectorial
    • Un sistema validado operando millones de bases de datos en el entorno de producción de Alibaba
  • Combina la estabilidad OLTP de InnoDB de MySQL con el alto rendimiento analítico de DuckDB
  • Todas las funciones están disponibles a través de la interfaz existente de MySQL

Rendimiento y características principales

  • El DuckDB Storage Engine es un motor OLAP columnar que admite compresión automática y está optimizado para cargas de trabajo analíticas
    • Ofrece una velocidad de procesamiento de consultas analíticas de hasta 200 veces más rápida que InnoDB
  • Vector Index (VIDX) admite almacenamiento vectorial y búsqueda aproximada de vecinos más cercanos (ANN) basada en el algoritmo HNSW
    • Soporta cálculo de distancia COSINE y EUCLIDEAN, y puede procesar vectores de hasta 16,383 dimensiones
  • Mantiene 100% de compatibilidad con MySQL, por lo que se pueden usar sin cambios el SQL, los drivers y las herramientas existentes

Hoja de ruta de desarrollo

  • Para el cuarto trimestre de 2025, se completará la publicación open source del motor DuckDB y de Vector Index
  • Funciones planeadas para después de 2026
    • Optimización de DDL: Instant DDL, creación paralela de árboles B+ y bloqueos no bloqueantes
    • Optimización de RTO: recuperación rápida ante fallos y RTO mínimo
    • Replication Boost: Binlog Flush paralelo, Binlog in Redo y optimización de transacciones de gran volumen

Ejemplos de uso

  • Creación y consulta de tablas analíticas con DuckDB
    • Tras crear una tabla con el motor DuckDB, una consulta de agregación de ventas mensuales puede ejecutarse 200 veces más rápido que con InnoDB
  • Búsqueda vectorial para aplicaciones de IA
    • Después de crear una tabla con una columna vectorial de 768 dimensiones, se puede realizar búsqueda de similitud basada en distancia coseno mediante un índice HNSW

Open source y comunidad

  • Publicación open source en diciembre de 2025; el equipo de Alibaba Cloud Database lidera el desarrollo, la gestión y el mantenimiento
  • Distribuido bajo licencia GPL-2.0, con el mismo esquema de licenciamiento que MySQL
  • Se pueden reportar errores y proponer funciones a través de GitHub Issues
  • Alibaba Cloud RDS ofrece un servicio comercial como instancia analítica basada en DuckDB

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-05
Comentarios de Hacker News

  • Es interesante el enfoque de usar DuckDB como motor de almacenamiento
    Permite mantener intactas las conexiones, herramientas y la estructura de replicación existentes de MySQL, mientras solo las consultas analíticas se enrutan a un motor columnar
    Operativamente, es mucho más simple que levantar una base de datos analítica aparte y construir un pipeline de sincronización
    Aun así, el punto clave es cómo mantener la consistencia de datos entre InnoDB y DuckDB

    • Se presenta un método para implementar nodos de Columnar Store de solo lectura (DuckDB) aprovechando el mecanismo de binlog de MySQL
      Los detalles están resumidos en la documentación de AliSQL DuckDB
      Se realizaron diversas optimizaciones en la transferencia por lotes del binlog, operaciones de escritura y otros aspectos
    • Para resolver el problema de consistencia de datos, se usa replicación basada en GTID
      Cuando log_bin está desactivado, la transacción de DuckDB se confirma antes de registrar el GTID, y durante la recuperación ante fallos se vuelve a aplicar de forma idempotente
      Cuando log_bin está activado, se usa directamente el Binlog, y se registra en DuckDB una posición válida de Binlog para hacer rollback hasta ese punto en caso de fallo
      Como resultado, si gtid_executed de la réplica coincide con el del primario, los datos en DuckDB también son consistentes

  • Ven la evolución de las bases de datos SQL en los próximos 10 años en tres etapas

    1. integrar un motor OLAP en el motor OLTP existente y reenviar consultas
    2. rediseñar ambos motores para que usen una capa de almacenamiento compartida
    3. al final, fusionar completamente los motores, evolucionando hacia una estructura que comprime y archiva automáticamente los registros antiguos y los recupera del almacenamiento remoto cuando hace falta
      Solo las consultas sobre datos antiguos serían un poco más lentas; en todo lo demás ofrecería una experiencia de consulta completamente unificada

  • Tienen curiosidad por saber qué diferencias habrá frente a pg_duckdb
    Gracias al mecanismo de extensiones de Postgres, pg_duckdb se ve bastante limpio

    • (comentario eliminado)

  • Se preguntan si este sistema, como SAP HANA, alimenta en tiempo real a DuckDB con los datos de las cargas transaccionales
    Si es así, se reduciría muchísimo la complejidad de sincronizar un data warehouse con Kafka o Debezium
    También les gustaría conocer la opinión de apavlo

  • Parece que la era de HTAP ya llegó de verdad
    Es interesante ver cómo se adoptan cada vez más este tipo de bases de datos híbridas
    En particular, impresionan las mejoras de procesamiento transaccional explicadas en la documentación de AliSQL DuckDB
    Es notable que garantice una sincronización rápida y a nivel de transacción entre las tablas base y las tablas analíticas

    • Pero esto se parece más a una unión de dos bases de datos bajo una sola interfaz que a un HTAP real
      La garantía de consistencia no es tan distinta de la de sistemas como Materialize
      En realidad, este tipo de intentos existe desde hace tiempo, y ha habido muchos casos de añadir motores de almacenamiento OLAP a MySQL/Postgres

  • Añadir un motor columnar embebido a una base de datos tradicional ofrece grandes ventajas en productividad y simplicidad operativa
    Actualmente usan una combinación de PG + Tiger Data, y del lado de MySQL no había una alternativa así
    Este intento podría llenar ese vacío

    • MariaDB ya tiene el motor ColumnStore
      Recientemente también agregó el tipo de almacenamiento vectorial, así que será interesante comparar su rendimiento con la implementación de Alibaba
      Se menciona mucho a Postgres, pero MariaDB también es bastante versátil
    • ClickHouse ofrece soporte nativo para el protocolo MySQL, y también puede envolver o importar tablas MySQL
      Se necesitan dos conexiones, pero funciona bastante bien
    • Se preguntan si Tiger Data puede usarse como un simple almacén columnar
      Solo necesitan conteos rápidos como en ClickHouse, pero tener que pasar por todo el proceso de sincronización es incómodo
      TimeSeries está optimizado para casos de uso específicos, así que es difícil usarlo de forma general
    • TiDB también es una opción
      Soporta tanto datos basados en filas como en columnas, pero aunque es compatible con MySQL, su base de código es distinta
      Así que no es una extensión completa de MySQL
    • MariaDB ya soporta tablas columnares

  • Se preguntan qué tan fácil sería desplegar esta función combinándola con MySQL Operator

    • Aún no lo han intentado, pero planean probar más adelante una integración con mysql-operator

  • A primera vista, parece una versión que integra de forma más estrecha el FDW de PSQL con DuckDB y Vector Storage
    También da una sensación similar a Vespa, así que resulta interesante por qué eligieron una extensión de MySQL en lugar del enfoque FDW

    • Probablemente porque ya estaban usando millones de líneas de código de MySQL

  • El historial de commits se ve raro
    Solo hay 2 en 2022 y unos pocos entre 2024 y 2026, y el primer commit dice “First commit, Support DuckDB Engine”

    • Lo más probable es que se haya desarrollado primero de forma privada internamente y que luego solo hayan ordenado un mínimo de commits para hacerlo público
      La versión interna pudo haber estado llena de referencias a Jira, información del producto y comentarios en chino
      Por eso parece que crearon un historial de git limpio específicamente para la publicación

  • Se preguntan cómo habría sido TiDB si hubiera usado DuckDB en lugar de ClickHouse

    • Si DuckDB hubiera existido alrededor de 2020 como un open source estable, están seguros de que TiDB habría elegido DuckDB en vez de ClickHouse