A discussion has been created for this topic: #79
Pre-flight Checklist
Primary Contact Name
zongzhi chen
Primary Contact Email
baotiao@gmail.com
Company / Organization
Alibaba
Role
Software Engineer
Additional Authors / Contributors
No response
Component
Server
Target Release (Optional)
No response
Roadmap Section
Other
Related Issues / Pull Requests / References (Optional)
Executive Summary
MySQL's pluggable storage engine architecture was designed so that engines targeting different workloads could be integrated behind a common handler interface. InnoDB made MySQL the most widely used open-source OLTP database, but MySQL still lacks a native analytical engine. InnoDB's row-oriented design performs poorly on analytical queries, so users today either accept slow reporting queries on their OLTP data, or ETL the data into an external OLAP system (ClickHouse, Doris, data warehouses). The second option adds operational complexity, data freshness lag, and a second query dialect for applications to learn.
This proposal adds DuckDB as a columnar storage engine for MySQL, giving MySQL native OLAP capability while keeping full compatibility with the MySQL protocol, SQL syntax, replication, and operational tooling. DuckDB is a good fit for this role:
It is an embedded analytical engine, naturally suited to in-process integration behind the handler interface.
Its single-node query performance on analytical workloads is excellent.
Columnar storage with type-aware compression gives high compression ratios.
Its extension mechanism makes it practical to add a MySQL compatibility layer.
The MIT license permits integration and redistribution without restrictions.
This is not a design-on-paper proposal. We have built and productionized this integration in AliSQL (a MySQL branch maintained by Alibaba), running in production since mid-2025 and open-sourced in February 2026. Measured results from that implementation:
On TPC-H SF100 (32 vCPU / 128 GB, cloud SSD), analytical query performance improves by up to ~200x compared to InnoDB.
Columnar compression typically reduces storage to ~20% of the equivalent InnoDB footprint.
An automated compatibility test suite of ~170,000 SQL statements shows ~99% MySQL compatibility.
Batched binlog apply reaches ~300,000 rows/s, with no measurable replication lag under sysbench write pressure (higher apply throughput than InnoDB).
We would like to contribute this work upstream so the MySQL community gains a first-class analytical engine, and to work with the MySQL team on the design review.
User / Developer Stories
- As a MySQL user running reporting and analytical queries on OLTP data, I want a columnar analytical replica of my primary, so that I do not need to ETL data into a separate OLAP system.
- As an application developer, I want to keep using the MySQL protocol and MySQL SQL syntax for analytical queries, so that no application changes or new query dialects are required.
- As a DBA, I want the analytical node to behave like an ordinary MySQL replica (binlog replication, same monitoring, slow log, audit log, and administration workflows), so that there is no new operational system to learn.
- As a user with large historical tables, I want columnar compression, so that storage cost for archival and analytical data is significantly reduced.
Proposed Scope
- Integrate DuckDB behind the MySQL handler / storage engine API as a new engine (ENGINE=DUCKDB). User data lives in DuckDB; InnoDB remains the engine for system tables and metadata (privileges, configuration, etc.).
- A MySQL compatibility layer for DuckDB: an extended parser for MySQL-specific syntax, plus rewritten and newly implemented functions so that common MySQL functions behave identically.
- Result set conversion between DuckDB execution results and the MySQL protocol result format.
- Binlog replication support so a DuckDB node can replicate from an InnoDB primary:
- Idempotent binlog replay to guarantee consistency between GTID position and engine data after a crash, since DuckDB does not support two-phase commit (XA) with the binlog.
- Batched DML apply to amortize DuckDB's per-transaction cost on small-transaction workloads.
- Copy DDL fallback: DDL that DuckDB supports natively runs inplace/instant; unsupported DDL (e.g. reordering columns) is handled by building a replacement table, parallelized across threads.
- An analytical read-only replica deployment mode as the first supported topology.
Out of Scope / Future Work
- Writable DuckDB primary instances with HA (source/replica pairs of DuckDB nodes) — implemented in AliSQL, but proposed as a follow-up stage after the read-only replica path is reviewed.
- Automatic query routing between InnoDB and DuckDB within a single instance (hybrid HTAP routing).
- Distributed / multi-node execution. The goal of this proposal is lightweight single-node analytical capability.
- Cross-engine transactions between InnoDB and DuckDB user tables.
References
Functional Requirements
No response
Non-functional Requirements
No response
Impact Areas
Summary of the Approach
No response
User Interface
No response
Configuration / Knobs
No response
Observability
No response
User Procedure
No response
Security Considerations
No response
Compatibility and Behavior Changes
No response
Block Diagram
No response
Interface Specification
No response
Proposed Implementation Plan
No response
QA Notes
No response
A discussion has been created for this topic: #79
Pre-flight Checklist
Primary Contact Name
zongzhi chen
Primary Contact Email
baotiao@gmail.com
Company / Organization
Alibaba
Role
Software Engineer
Additional Authors / Contributors
No response
Component
Server
Target Release (Optional)
No response
Roadmap Section
Other
Related Issues / Pull Requests / References (Optional)
Executive Summary
MySQL's pluggable storage engine architecture was designed so that engines targeting different workloads could be integrated behind a common handler interface. InnoDB made MySQL the most widely used open-source OLTP database, but MySQL still lacks a native analytical engine. InnoDB's row-oriented design performs poorly on analytical queries, so users today either accept slow reporting queries on their OLTP data, or ETL the data into an external OLAP system (ClickHouse, Doris, data warehouses). The second option adds operational complexity, data freshness lag, and a second query dialect for applications to learn.
This proposal adds DuckDB as a columnar storage engine for MySQL, giving MySQL native OLAP capability while keeping full compatibility with the MySQL protocol, SQL syntax, replication, and operational tooling. DuckDB is a good fit for this role:
It is an embedded analytical engine, naturally suited to in-process integration behind the handler interface.
Its single-node query performance on analytical workloads is excellent.
Columnar storage with type-aware compression gives high compression ratios.
Its extension mechanism makes it practical to add a MySQL compatibility layer.
The MIT license permits integration and redistribution without restrictions.
This is not a design-on-paper proposal. We have built and productionized this integration in AliSQL (a MySQL branch maintained by Alibaba), running in production since mid-2025 and open-sourced in February 2026. Measured results from that implementation:
On TPC-H SF100 (32 vCPU / 128 GB, cloud SSD), analytical query performance improves by up to ~200x compared to InnoDB.
Columnar compression typically reduces storage to ~20% of the equivalent InnoDB footprint.
An automated compatibility test suite of ~170,000 SQL statements shows ~99% MySQL compatibility.
Batched binlog apply reaches ~300,000 rows/s, with no measurable replication lag under sysbench write pressure (higher apply throughput than InnoDB).
We would like to contribute this work upstream so the MySQL community gains a first-class analytical engine, and to work with the MySQL team on the design review.
User / Developer Stories
Proposed Scope
Out of Scope / Future Work
References
Functional Requirements
No response
Non-functional Requirements
No response
Impact Areas
Summary of the Approach
No response
User Interface
No response
Configuration / Knobs
No response
Observability
No response
User Procedure
No response
Security Considerations
No response
Compatibility and Behavior Changes
No response
Block Diagram
No response
Interface Specification
No response
Proposed Implementation Plan
No response
QA Notes
No response