AliSQL 8.0 - MySQLにDuckDBカラムナエンジンとベクトルサーチを統合したアリババのOSS

アリババのクラウドデータベースチームが「AliSQL 8.0」をオープンソースで公開した。MySQLのブランチとして、OLTP用のInnoDB、OLAP用のDuckDBカラムナエンジン、そしてベクトルサーチ機能を1つのデータベースに統合したものだ。

「1つのDBでトランザクション処理も分析もAI用途もこなす」という、いわゆるHTAP+AIの方向性を打ち出している。

3つのエンジンを統合

AliSQL 8.0のアーキテクチャは、大きく3つの層で構成されている。

OLTP層: InnoDB

トランザクション処理にはMySQL標準のInnoDBエンジンを使用する。MySQL互換性が維持されているため、既存のMySQL向けツールやクライアントライブラリがそのまま使える。MySQLからの移行コストが低い点は実用上の大きなメリットだ。

OLAP層: DuckDBカラムナエンジン

分析クエリ用にDuckDBのカラムナエンジンが統合されている。公式の説明では「InnoDBより200倍高速なデータ分析機能を提供する」とのことだ。

カラムナー形式によるデータ圧縮と、列指向の高速クエリ処理が組み込まれている。従来であれば分析用に別のデータウェアハウスを立てるか、MySQLからデータをエクスポートしてBigQueryやRedshiftに投入する必要があったが、AliSQLなら同一DB内で完結する。

DuckDBは近年、組み込み分析エンジンとして急速に存在感を増しているプロジェクトだ。その技術をMySQL互換DBに統合したのは面白いアプローチである。

AI層: HNSWベクトルサーチ

ベクトル検索にはHNSW（Hierarchical Navigable Small World）アルゴリズムを採用している。最大16,383次元のベクトルに対応しており、LLMのエンベディングを使った類似検索やRAGのバックエンドとして十分な次元数だ。

PostgreSQLとの比較 - pgvectorとの違い

ベクトルサーチの文脈で比較されるのがPostgreSQLのpgvectorだ。

項目	AliSQL 8.0	PostgreSQL + pgvector
ベースDB	MySQL互換	PostgreSQL
ベクトル検索	HNSW（組み込み）	HNSW + IVFFlat（拡張）
OLAP	DuckDB統合	別途DuckDB連携 or Citus
成熟度	新規公開	pgvectorは広く普及済み
エコシステム	MySQL互換ツール	PostgreSQL拡張エコシステム

pgvectorは2023年頃からAI/LLM文脈で爆発的に普及し、PostgreSQLがベクトルDBとしても使えるという認知が広まった。AliSQLはMySQLの世界にネイティブなベクトルサーチを持ち込んだことになるが、pgvectorほどのエコシステムが構築されるかは未知数だ。

PostgreSQLのエコシステムは止まらない: pg-typesafe

PostgreSQL側では開発体験を改善するツールも着実に出てきている。最近公開された「pg-typesafe」は、PostgreSQLの生SQLクエリにTypeScriptの型安全性を追加するゼロ依存ツールだ。

const { rows } = client.query(
  "select id, name, last_modified from tbl where id = $1",
  [42],
);
// rows は { id: number; name: string; last_modified: Date }[] として型推論される

見た目は通常のpgクエリとまったく同じだが、パラメータの型とレスポンスの型が自動的に付与される。仕組みとしては、プロジェクト内のTypeScriptファイルからSQL文字列を抽出し、実際のPostgreSQLに接続して型情報を取得、型定義ファイルを生成する。ランタイム依存ゼロ、追加の記述量ゼロというのがポイント。

類似ツールとしてpgtypedやkyselyがあるが、pg-typesafeは「pgライブラリの上に何も追加しない」のが差別化ポイントだ。既存コードの書き換え不要で、型定義ファイルを生成するだけで済む。BIGINTをbigintに変換したり、JSONBカラムにスキーマに応じた型を付けるカスタマイズも可能。

pgvectorでAI対応、pg-typesafeで型安全な開発体験と、PostgreSQL側のエコシステムは多方面で充実が進んでいる。MySQLの世界でこれに匹敵するツールチェーンが揃うかどうかが、AliSQLの普及にも影響するだろう。

MySQLの停滞とAliSQLの意味

先月書いたMySQLは死ぬのか？で整理した通り、MySQL本家はGitHubコミットの激減、コア開発チームの60〜70%レイオフなど、不穏な状況が続いている。コミュニティでは「Oracleに任せ続けるかフォークを作るか」という議論まで始まった。

そんな中でAliSQLが出てきた意味は大きい。MySQL互換を維持しながら、本家がやらない方向の進化を外部が進めている形だ。

MySQLのフォーク・ブランチ勢力を整理するとこうなる。

プロジェクト	種別	特徴
MariaDB	ハードフォーク	MySQL互換性は乖離中。Fortune 500の75%が採用
Percona Server	トラッキングフォーク	本家追従＋性能改善。互換性が高い
PlanetScale	独自フォーク	Vitessベース。Webスケール
AliSQL 8.0	ブランチ	DuckDB + ベクトル。HTAP+AI路線

AliSQLの「OLTP + OLAP + AI」という方向性は、PostgreSQLがpgvectorやTimescaleDB等の拡張で実現してきたことを、MySQL互換の世界で一気にやろうとしている。

今後の開発予定

ロードマップとして以下の機能強化が予定されている。

• ノンブロッキングDDL最適化
• 復旧時間（RTO）の短縮
• バイナリログの並列フラッシュによるレプリケーション機能の強化

実績

AliSQL 8.0は、Alibaba Cloudの「ApsaraDB RDS for MySQL」で実運用されている。「ラボから出てきた実験的プロジェクト」ではなく、クラウドサービスの基盤として使われている実績がある点は安心材料だ。

---

新規ならPostgreSQL + pgvectorの方が安牌だと思う。ただ既存のMySQL資産を抱えてて「分析もAIもやりたい」なら検討に値する。本家MySQL 8.0が2026年4月にEOLを迎える中、AliSQLがどのバージョンに追従していくのかは気になるところ。

参照:

• AliSQL 8.0 - Publickey
• pg-typesafe - GitHub