AliSQL 8.0 - Alibaba's OSS that integrates DuckDB columnar engine and vector search into MySQL

Alibaba’s cloud database team has open-sourced AliSQL 8.0. As a MySQL branch, it combines InnoDB for OLTP, a DuckDB columnar engine for OLAP, and vector search in a single database.

It is pushing the HTAP + AI direction: one database for transactions, analytics, and AI workloads.

Integrating three engines

The AliSQL 8.0 architecture is made up of three major layers.

OLTP layer: InnoDB

Transactions use MySQL’s standard InnoDB engine. Because MySQL compatibility is preserved, existing MySQL tools and client libraries can be reused as-is. Low migration cost from MySQL is a major practical advantage.

OLAP layer: DuckDB columnar engine

DuckDB’s columnar engine is integrated for analytical queries. According to the official explanation, it provides data analysis that is “200 times faster than InnoDB.”

Columnar compression and high-speed column-oriented query processing are built in. In the past, you would need a separate data warehouse for analytics or export data from MySQL into BigQuery or Redshift. With AliSQL, that can stay inside one database.

DuckDB has recently been gaining momentum as an embedded analytics engine. Integrating that technology into a MySQL-compatible database is an interesting move.

AI layer: HNSW vector search

For vector search, AliSQL uses the HNSW (Hierarchical Navigable Small World) algorithm. It supports vectors up to 16,383 dimensions, which is more than enough for embedding-based similarity search and an RAG backend.

Compared with PostgreSQL and pgvector

In vector-search discussions, the usual comparison point is PostgreSQL’s pgvector.

Item	AliSQL 8.0	PostgreSQL + pgvector
Base DB	MySQL-compatible	PostgreSQL
Vector search	Built-in HNSW	HNSW + IVFFlat (extension)
OLAP	DuckDB integrated	Separate DuckDB linkage or Citus
Maturity	Newly released	pgvector is already widely adopted
Ecosystem	MySQL-compatible tools	PostgreSQL extension ecosystem

pgvector spread explosively around 2023 in AI/LLM circles, and PostgreSQL became widely recognized as a viable vector database too. AliSQL brings native vector search into the MySQL world, but whether it can build an ecosystem as strong as pgvector remains to be seen.

PostgreSQL’s ecosystem keeps moving: pg-typesafe

The PostgreSQL side is also steadily producing tools that improve developer experience. A recently released tool called pg-typesafe adds TypeScript type safety to raw PostgreSQL SQL queries with zero dependencies.

const { rows } = client.query(
  "select id, name, last_modified from tbl where id = $1",
  [42],
);
// rows is inferred as { id: number; name: string; last_modified: Date }[]

It looks like a normal pg query, but the parameter types and response types are inferred automatically. The trick is to extract SQL strings from TypeScript files in the project, connect to a real PostgreSQL instance to retrieve type information, and generate type definition files. The key points are zero runtime dependencies and zero extra application code.

There are similar tools like pgtyped and kysely, but pg-typesafe differentiates itself by not layering anything on top of the pg library. You do not need to rewrite existing code; generating type definition files is enough. It can also customize conversions such as BIGINT to bigint and add schema-aware types to JSONB columns.

With pgvector for AI and pg-typesafe for type-safe development, PostgreSQL’s ecosystem keeps expanding in many directions. Whether the MySQL world can assemble a comparable toolchain will affect AliSQL’s adoption as well.

What AliSQL means amid MySQL stagnation

As I summarized in Will MySQL die? last month, upstream MySQL is in a worrying state, with GitHub commit volume collapsing and 60-70% of the core team laid off. The community has even started debating whether to leave Oracle behind or build a fork.

Against that backdrop, AliSQL matters. It preserves MySQL compatibility while advancing in directions the upstream project is not pursuing.

Here is a quick map of the MySQL branch/fork landscape:

Project	Type	Characteristics
MariaDB	Hard fork	MySQL compatibility is diverging; adopted by 75% of Fortune 500 companies
Percona Server	Tracking fork	Follows upstream while improving performance; high compatibility
PlanetScale	Proprietary fork	Vitess-based; web-scale focused
AliSQL 8.0	Branch	DuckDB + vector search; HTAP + AI direction

AliSQL’s “OLTP + OLAP + AI” direction is essentially trying to do in one step, inside the MySQL-compatible world, what PostgreSQL has achieved through extensions like pgvector and TimescaleDB.

Planned future work

The roadmap includes the following improvements:

Non-blocking DDL optimizations
Shorter recovery time objectives (RTO)
Better replication through parallel flushing of binary logs

Track record

AliSQL 8.0 is already in production in Alibaba Cloud’s “ApsaraDB RDS for MySQL.” It is not just an experimental project that never left the lab; it is already serving as the foundation of a cloud service, which is reassuring.

For a new project, PostgreSQL + pgvector still seems like the safer choice. But if you already have a large MySQL estate and want both analytics and AI, AliSQL is worth considering. With upstream MySQL 8.0 reaching EOL in April 2026, I am curious which version AliSQL will follow next.

References: