AliSQL - fork MySQL open source dari Alibaba, integrasi mesin vektor dan DuckDB

• Cabang open source berbasis MySQL yang dikembangkan oleh Alibaba Group, dengan mesin database yang mengintegrasikan fungsi OLTP dan OLAP
• Menanamkan mesin kolumnar DuckDB untuk memberikan kinerja hingga 200x lebih cepat pada kueri analitik
• Mendukung pencarian vektor berbasis HNSW dan menangani embedding AI·ML hingga 16.383 dimensi
• 100% kompatibel dengan alat·driver MySQL yang ada, sehingga bisa langsung digunakan tanpa pembelajaran tambahan
• Teknologi yang telah tervalidasi di lingkungan produksi skala besar Alibaba Cloud, dan menonjol sebagai database terpadu untuk workload AI·analitik

---

Ikhtisar AliSQL

• AliSQL adalah cabang MySQL kelas enterprise yang dikembangkan oleh Alibaba Group, mengintegrasikan mesin OLAP DuckDB dan fitur pencarian vektor native
  • Sistem yang telah terverifikasi melalui pengoperasian jutaan database di lingkungan produksi Alibaba
• Menggabungkan stabilitas OLTP InnoDB dari MySQL dengan kinerja analitik berkecepatan tinggi dari DuckDB
• Semua fitur dapat diakses melalui antarmuka MySQL yang sudah ada

Kinerja dan fitur utama

• DuckDB Storage Engine adalah mesin OLAP kolumnar yang mendukung kompresi otomatis dan dioptimalkan untuk workload analitik
  • Memberikan kecepatan pemrosesan kueri analitik hingga 200x lebih cepat dibanding InnoDB
• Vector Index (VIDX) mendukung penyimpanan vektor dan approximate nearest neighbor search (ANN) berbasis algoritma HNSW
  • Mendukung perhitungan jarak COSINE dan EUCLIDEAN, serta dapat memproses vektor hingga 16.383 dimensi
• Tetap mempertahankan kompatibilitas MySQL 100%, sehingga SQL, driver, dan alat yang ada bisa digunakan apa adanya

Roadmap pengembangan ke depan

• Hingga kuartal 4 tahun 2025, penyelesaian mesin DuckDB, Vector Index, dan rilis open source
• Fitur yang direncanakan setelah 2026
  • Optimasi DDL: instant DDL, pembuatan B+tree paralel, non-blocking lock
  • Optimasi RTO: pemulihan crash cepat, RTO minimum
  • Replication Boost: parallel Binlog Flush, Binlog in Redo, optimasi transaksi berukuran besar

Contoh penggunaan

• Pembuatan dan kueri tabel analitik DuckDB
  • Setelah membuat tabel dengan mesin DuckDB, kueri agregasi penjualan bulanan diproses 200x lebih cepat dibanding InnoDB
• Pencarian vektor untuk aplikasi AI
  • Setelah membuat tabel yang mencakup kolom vektor 768 dimensi, lakukan pencarian kemiripan berbasis jarak cosine melalui indeks HNSW

Open source dan komunitas

• Rilis open source pada Desember 2025, dikembangkan, dikelola, dan dipelihara terutama oleh tim Alibaba Cloud Database
• Didistribusikan dengan lisensi GPL-2.0, sama seperti skema lisensi MySQL
• Laporan bug dan usulan fitur dapat diajukan melalui GitHub Issues
• Tersedia sebagai layanan komersial di Alibaba Cloud RDS dalam bentuk instance analitik berbasis DuckDB

[GN⁺]

Opini Hacker News

• Pendekatan yang menggunakan DuckDB sebagai storage engine cukup menarik
  Kueri analitik bisa diarahkan ke engine berbasis kolom sambil tetap mempertahankan koneksi, tooling, dan struktur replikasi MySQL yang sudah ada
  Secara operasional ini jauh lebih sederhana daripada membangun DB analitik terpisah dan membuat pipeline sinkronisasi
  Namun, poin kuncinya adalah bagaimana menjaga konsistensi data antara InnoDB dan DuckDB

  • Dijelaskan cara mengimplementasikan node Columnar Store (DuckDB) read-only dengan memanfaatkan mekanisme binlog MySQL
    Detailnya dirangkum dalam dokumentasi AliSQL DuckDB
    Berbagai optimasi dilakukan pada pengiriman batch binlog, operasi tulis, dan lainnya
  • Untuk menyelesaikan masalah konsistensi data, digunakan replikasi berbasis GTID
    Saat log_bin dimatikan, transaksi DuckDB di-commit sebelum pencatatan GTID, lalu diterapkan ulang saat pemulihan gangguan dengan cara idempotent
    Saat log_bin dinyalakan, Binlog dipakai secara langsung, dan posisi Binlog yang valid dicatat di DuckDB agar bisa rollback sampai posisi tersebut jika terjadi kegagalan
    Hasilnya, jika gtid_executed pada replica cocok dengan primary, maka data DuckDB juga konsisten

• Evolusi database SQL dalam 10 tahun ke depan dipandang akan melalui tiga tahap

  1. Mengintegrasikan engine OLAP ke engine OLTP yang ada dan meneruskan kueri ke sana
  2. Mendesain ulang agar kedua engine memakai lapisan storage bersama
  3. Pada akhirnya kedua engine akan digabung sepenuhnya, berkembang menjadi struktur yang otomatis mengompresi dan mengarsipkan record lama serta memuatnya dari storage jarak jauh saat diperlukan
     Hanya akses ke data lama yang akan sedikit lebih lambat, sementara sisanya memberi pengalaman kueri yang sepenuhnya terintegrasi

• Penasaran apa perbedaannya dibandingkan pg_duckdb
  Berkat mekanisme ekstensi Postgres, pg_duckdb terlihat cukup rapi

  • (komentar dihapus)

• Penasaran apakah sistem ini, seperti SAP HANA, memasok data workload transaksional ke DuckDB secara real-time
  Jika ya, pekerjaan rumit untuk menyinkronkan data warehouse lewat Kafka atau Debezium akan sangat berkurang
  Ingin juga mendengar pendapat apavlo

• Rasanya era HTAP benar-benar sudah datang
  Menarik melihat database hibrida seperti ini makin banyak diadopsi
  Terutama peningkatan pemrosesan transaksi yang dijelaskan dalam dokumentasi AliSQL DuckDB sangat mengesankan
  Keren bahwa sinkronisasi antara tabel dasar dan tabel analitik dijamin cepat dan per transaksi

  • Namun ini terasa lebih seperti mengikat dua DB dalam satu antarmuka daripada HTAP sejati
    Jaminan konsistensinya tidak jauh berbeda dari sistem seperti Materialize
    Sebenarnya upaya seperti ini sudah ada sejak lama, dan sudah banyak kasus menambahkan storage engine OLAP ke MySQL/Postgres

• Menambahkan engine kolumnar embedded ke DB tradisional memberi keuntungan besar dalam produktivitas dan kesederhanaan operasional
  Saat ini saya memakai kombinasi PG + Tiger Data, tetapi di sisi MySQL belum ada alternatif seperti ini
  Percobaan kali ini tampaknya bisa mengisi kekosongan tersebut

  • MariaDB sudah punya engine ColumnStore
    Belakangan juga ditambahkan vector storage type, jadi menarik membandingkan performanya dengan implementasi Alibaba
    Postgres sering disebut, tetapi MariaDB juga cukup serbaguna
  • ClickHouse mendukung protokol MySQL secara native dan juga bisa membungkus atau mengimpor tabel MySQL
    Memang butuh dua koneksi, tetapi bekerja cukup baik
  • Penasaran apakah Tiger Data bisa dipakai sebagai column store sederhana
    Saya hanya butuh count cepat seperti di ClickHouse, tetapi harus melalui seluruh proses sinkronisasi terasa merepotkan
    TimeSeries dioptimalkan untuk use case tertentu, jadi agak sulit untuk penggunaan umum
  • TiDB juga salah satu opsi
    Mendukung data berbasis row dan column, tetapi hanya kompatibel dengan MySQL dan basis kodenya berbeda
    Jadi ini bukan ekstensi MySQL yang sepenuhnya nyata
  • MariaDB juga sudah mendukung tabel kolumnar

• Penasaran seberapa mudah fitur ini diterapkan jika digabungkan dengan MySQL Operator

  • Belum pernah mencobanya, tetapi ada rencana untuk menguji integrasi dengan mysql-operator nanti

• Sekilas ini terlihat seperti versi FDW milik PSQL yang diintegrasikan lebih erat dengan DuckDB dan Vector Storage
  Nuansanya juga mirip Vespa, jadi menarik kenapa mereka memilih ekstensi MySQL alih-alih pendekatan FDW

  • Mungkin karena mereka sudah menggunakan jutaan baris kode MySQL

• Riwayat commit-nya aneh
  Hanya ada 2 commit pada 2022 dan beberapa commit pada 2024~2026, sementara commit pertama berbunyi “First commit, Support DuckDB Engine”

  • Kemungkinan besar pengembangan dilakukan secara internal tertutup, lalu hanya commit minimum yang dirapikan untuk publikasi
    Versi internalnya mungkin rumit karena referensi Jira, informasi produk, komentar berbahasa Mandarin, dan sebagainya
    Jadi sepertinya mereka membuat ulang riwayat git publik yang lebih rapi

• Penasaran bagaimana jadinya jika TiDB memakai DuckDB alih-alih ClickHouse

  • Jika DuckDB sudah ada sebagai open source yang stabil sekitar tahun 2020, saya yakin TiDB pasti akan memilih DuckDB daripada ClickHouse