AliSQL – Alibabas Open-Source-MySQL-Fork mit integrierter Vektor- und DuckDB-Engine

 (github.com/alibaba)
10 Punkte von GN⁺ 2026-02-05 | 1 Kommentare | Auf WhatsApp teilen
  • Ein von der Alibaba Group entwickelter Open-Source-Branch auf MySQL-Basis, der OLTP- und OLAP-Funktionen in einer Datenbank-Engine vereint
  • Mit integrierter DuckDB-Spalten-Engine für bis zu 200-fach höhere Performance bei analytischen Abfragen
  • Unterstützt HNSW-basierte Vektorsuche und verarbeitet AI-/ML-Embeddings mit bis zu 16.383 Dimensionen
  • 100 % kompatibel mit bestehenden MySQL-Tools und -Treibern, sofort ohne zusätzliche Einarbeitung nutzbar
  • Eine in großen Produktionsumgebungen von Alibaba Cloud erprobte Technologie, die als integrierte Datenbank für AI- und Analyse-Workloads Aufmerksamkeit erhält

Überblick über AliSQL

  • AliSQL ist ein von der Alibaba Group entwickelter Enterprise-Branch von MySQL, der die DuckDB-OLAP-Engine und native Vektorsuche integriert
    • Ein in der Produktionsumgebung von Alibaba beim Betrieb von Millionen von Datenbanken erprobtes System
  • Vereint die InnoDB-OLTP-Stabilität von MySQL mit der hohen Analysegeschwindigkeit von DuckDB
  • Auf alle Funktionen kann über die bestehenden MySQL-Schnittstellen zugegriffen werden

Wichtige Leistungseigenschaften und Merkmale

  • Die DuckDB Storage Engine ist eine spaltenorientierte OLAP-Engine, unterstützt automatische Komprimierung und ist für Analyse-Workloads optimiert
    • Bietet gegenüber InnoDB eine bis zu 200-fach höhere Verarbeitungsgeschwindigkeit bei analytischen Abfragen
  • Vector Index (VIDX) unterstützt auf Basis des HNSW-Algorithmus Vektorspeicherung und Approximate Nearest Neighbor Search (ANN)
    • Unterstützt COSINE- und EUCLIDEAN-Distanzberechnung und kann Vektoren mit bis zu 16.383 Dimensionen verarbeiten
  • Behält 100%ige MySQL-Kompatibilität bei, sodass bestehendes SQL, Treiber und Tools unverändert genutzt werden können

Zukünftige Entwicklungs-Roadmap

  • Bis zum 4. Quartal 2025 Abschluss der DuckDB-Engine, des Vector Index und der Open-Source-Veröffentlichung
  • Für die Zeit nach 2026 geplante Funktionen
    • DDL-Optimierung: Instant DDL, parallele B+-Baum-Erstellung, Non-Blocking Locks
    • RTO-Optimierung: schnelle Crash-Recovery, minimales RTO
    • Replication Boost: paralleles Binlog Flush, Binlog in Redo, Optimierung für große Transaktionen

Anwendungsbeispiele

  • Erstellung und Abfrage von DuckDB-Analysetabellen
    • Nach dem Erstellen einer Tabelle mit der DuckDB-Engine wird eine Abfrage zur monatlichen Umsatzaggregation im Vergleich zu InnoDB bis zu 200-mal schneller verarbeitet
  • Vektorsuche für AI-Anwendungen
    • Nach dem Erstellen einer Tabelle mit einer 768-dimensionalen Vektorspalte wird über einen HNSW-Index eine Ähnlichkeitssuche auf Basis der Kosinus-Distanz ausgeführt

Open Source und Community

  • Open-Source-Veröffentlichung im Dezember 2025; Entwicklung, Betrieb und Wartung werden federführend vom Alibaba Cloud Database Team übernommen
  • Veröffentlicht unter der GPL-2.0-Lizenz, also mit demselben Lizenzmodell wie MySQL
  • Bug-Reports und Feature-Vorschläge sind über GitHub Issues möglich
  • Kommerzieller Service in Alibaba Cloud RDS als DuckDB-basierte Analyseinstanz verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-05
Hacker-News-Kommentare

  • Der Ansatz, DuckDB als Storage Engine zu verwenden, ist interessant.
    Bestehende MySQL-Verbindungen, Tooling und Replikationsstrukturen können unverändert beibehalten werden, während nur analytische Abfragen an eine spaltenbasierte Engine weitergeleitet werden.
    Operativ ist das viel einfacher, als eine separate analytische DB aufzusetzen und eine Synchronisations-Pipeline zu bauen.
    Der entscheidende Punkt ist allerdings, wie die Datenkonsistenz zwischen InnoDB und DuckDB aufrechterhalten wird.

    • Es wird vorgestellt, wie sich mit dem binlog-Mechanismus von MySQL schreibgeschützte Columnar-Store-(DuckDB)-Nodes implementieren lassen.
      Details sind in der AliSQL-DuckDB-Dokumentation zusammengefasst.
      Dabei wurden verschiedene Optimierungen für Batch-Übertragung per Binlog, Schreiboperationen usw. vorgenommen.
    • Zur Lösung des Datenkonsistenzproblems wird GTID-basierte Replikation genutzt.
      Wenn log_bin deaktiviert ist, wird die DuckDB-Transaktion vor dem Schreiben des GTID-Records committet und bei der Fehlerbehebung idempotent erneut angewendet.
      Wenn log_bin aktiviert ist, wird das Binlog direkt verwendet, und in DuckDB wird eine gültige Binlog-Position gespeichert, sodass im Fehlerfall bis zu dieser Position zurückgerollt werden kann.
      Im Ergebnis sind die DuckDB-Daten konsistent, wenn gtid_executed der Replica mit dem Primary übereinstimmt.

  • Die Entwicklung von SQL-Datenbanken in den nächsten zehn Jahren wird in drei Stufen gesehen.

    1. Bestehende OLTP-Engines integrieren OLAP-Engines und leiten Abfragen weiter.
    2. Beide Engines werden so neu entworfen, dass sie eine gemeinsame Storage-Layer verwenden.
    3. Am Ende werden die Engines vollständig zusammengeführt, mit einer Architektur, die alte Datensätze automatisch komprimiert und archiviert und sie bei Bedarf aus Remote-Storage lädt.
      Nur das Abfragen alter Daten wird etwas langsamer, während ansonsten ein vollständig integriertes Query-Erlebnis geboten wird.

  • Es ist interessant, wie sich das im Vergleich zu pg_duckdb unterscheiden würde.
    Dank des Erweiterungsmechanismus von Postgres wirkt pg_duckdb ziemlich elegant.

    • (gelöschter Kommentar)

  • Es stellt sich die Frage, ob dieses System wie SAP HANA Daten aus Transaktions-Workloads in Echtzeit nach DuckDB einspeist.
    Falls ja, würde das die komplexe Arbeit mit der Synchronisierung eines Data Warehouse über Kafka oder Debezium deutlich reduzieren.
    Dazu würde ich auch gern die Meinung von apavlo hören.

  • Es wirkt, als hätte das HTAP-Zeitalter nun wirklich begonnen.
    Interessant ist, dass solche hybriden Datenbanken zunehmend übernommen werden.
    Besonders beeindruckend sind die in der AliSQL-DuckDB-Dokumentation beschriebenen Verbesserungen bei der Transaktionsverarbeitung.
    Es ist stark, dass die Synchronisierung zwischen Basistabellen und analytischen Tabellen schnell und auf Transaktionsebene garantiert wird.

    • Allerdings ist das eher keine echte HTAP-Lösung, sondern eher eine Bündelung von zwei DBs unter einer gemeinsamen Oberfläche.
      Die Konsistenzgarantien unterscheiden sich nicht grundlegend von Systemen wie Materialize.
      Tatsächlich gab es solche Versuche schon früher, und es gab viele Fälle, in denen an MySQL/Postgres OLAP-Storage-Engines angebunden wurden.

  • Einer traditionellen DB eine eingebettete spaltenorientierte Engine hinzuzufügen, bringt große Vorteile bei Produktivität und operativer Einfachheit.
    Derzeit wird die Kombination PG + Tiger Data genutzt, aber auf der MySQL-Seite gab es keine solche Alternative.
    Dieser Versuch könnte genau diese Lücke schließen.

    • MariaDB hat bereits die ColumnStore-Engine.
      Vor Kurzem wurde auch ein Vector-Storage-Type hinzugefügt, wodurch ein Performance-Vergleich mit der Alibaba-Implementierung interessant wäre.
      Oft wird über Postgres gesprochen, aber auch MariaDB ist ziemlich vielseitig.
    • ClickHouse unterstützt das MySQL-Protokoll nativ und kann MySQL-Tabellen auch wrappen oder importieren.
      Es braucht zwar zwei Verbindungen, funktioniert aber ziemlich gut.
    • Es stellt sich die Frage, ob sich Tiger Data als einfacher Column Store verwenden lässt.
      Benötigt wird nur ein schnelles Count wie bei ClickHouse, aber der gesamte Synchronisationsprozess ist umständlich.
      TimeSeries ist für bestimmte Einsatzzwecke optimiert und daher für allgemeine Nutzung schwerer einzusetzen.
    • Auch TiDB ist eine Option.
      Es unterstützt sowohl zeilenbasierte als auch spaltenbasierte Daten, ist aber nur MySQL-kompatibel und nicht auf derselben Codebasis aufgebaut.
      Deshalb ist es keine vollständige MySQL-Erweiterung.
    • MariaDB unterstützt bereits spaltenorientierte Tabellen.

  • Es ist interessant, wie einfach sich diese Funktion in Kombination mit dem MySQL Operator bereitstellen lässt.

    • Bisher wurde das noch nicht ausprobiert, aber später ist geplant, die Integration mit mysql-operator zu testen.

  • Auf den ersten Blick wirkt es wie eine enger integrierte Version von PSQL-FDW mit DuckDB und Vector Storage.
    Es erinnert auch etwas an Vespa, und es ist interessant, warum statt des FDW-Ansatzes eine MySQL-Erweiterung gewählt wurde.

    • Wahrscheinlich, weil bereits Millionen Zeilen MySQL-Code im Einsatz waren.

  • Die Commit-Historie wirkt seltsam.
    Es gibt 2022 zwei Commits und 2024 bis 2026 nur ein paar weitere, und der erste Commit lautet „First commit, Support DuckDB Engine“.

    • Wahrscheinlich wurde zunächst intern und nicht öffentlich entwickelt, und für die Veröffentlichung wurden nur die nötigsten Commits aufbereitet.
      Die interne Version könnte mit Jira-Referenzen, Produktinformationen und chinesischen Kommentaren überladen gewesen sein.
      Deshalb wurde offenbar eine saubere öffentliche Git-Historie neu erstellt.

  • Es ist interessant, wie TiDB ausgesehen hätte, wenn statt ClickHouse DuckDB verwendet worden wäre.

    • Wenn DuckDB um 2020 herum als stabilisiertes Open-Source-Projekt verfügbar gewesen wäre, dann hätte TiDB mit Sicherheit DuckDB statt ClickHouse gewählt.