MySQL / InnoDB kernel
AliSQL 8.0.44-2 starts with the MySQL 8.0.44 server and InnoDB transaction stack. It builds on the 8.0.44-1 DuckDB HTAP debut with vector, historical-query, and binlog paths around that foundation rather than replacing it.
One SQL endpoint, two workload paths
Application and MySQL client/driver
│
MySQL protocol + SQL layer
│
authentication · optimizer · binlog
│
┌───────┴────────┐
│ │
InnoDB DuckDB
transactions, columnar scans,
row storage, joins, aggregation
vector indexes
| Path | Primary role | Data organization | Important AliSQL additions |
|---|---|---|---|
| MySQL / InnoDB | OLTP and transactional data | Row storage and B+tree indexes | Native vector index, historical reads, binlog commit optimizations |
| DuckDB | Analytics and archive-oriented queries | Columnar storage and vectorized execution | MySQL-facing SQL adaptation, conversion, replication, recovery, and resource controls |
Applications retain the MySQL protocol and SQL entry point. That does not make every engine behavior identical: storage-engine capabilities, SQL semantics, replication requirements, and recovery paths still need feature-specific qualification.
Current kernel capability map
| Capability | Engineering path | Default in 8.0.44-2 | Main boundary |
|---|---|---|---|
| Native vector search | HNSW graph persisted in an InnoDB auxiliary table | vidx_disabled=ON | InnoDB only; indexed operations require READ COMMITTED |
| Native Flashback | Historical InnoDB read view reconstructed from snapshot history and retained undo | Snapshot task OFF | Historical SELECT on InnoDB base tables; not a backup replacement |
| Persist Binlog Into Redo V2 | Eligible binlog events enter the redo durability boundary, then background threads write the binlog | OFF | Strict transaction and 2PC eligibility checks; normal group commit is the fallback |
| Binlog Cache Free Flush | A finalized large transaction cache can become the next binlog file without a second large copy | OFF | Current open-source DuckDB build uses normal group commit for this path |
| DuckDB storage engine | Columnar engine integrated through the MySQL server and storage-engine interfaces | duckdb_mode=NONE | Analytical use; MySQL compatibility is broad, not absolute |
Keep the boundaries visible
The feature flags are not cosmetic. They separate the mature MySQL/InnoDB baseline from execution paths that have their own topology, isolation, durability, or recovery prerequisites.
- Vector search keeps base rows and graph nodes under InnoDB transactions, but currently requires
READ COMMITTEDand serializes writers on the same vector table. - Flashback depends on snapshot generation plus undo retention. Enabling its query gate alone does not create recoverable history.
- Binlog in Redo optimizes eligible smaller transaction caches and falls back per transaction when a guard fails.
- Free Flush targets spilled large transaction caches and has a different eligibility model.
- DuckDB introduces its own table storage and analytical replication path; keep latency-sensitive transactional writes on InnoDB.
Read the implementation by path
- DuckDB analytics — SQL adaptation, columnar execution, replica topology, and operational limits.
- Native vector search — HNSW persistence, cache layers, SQL, parameters, and concurrency.
- Native Flashback — snapshot generation, undo retention, historical reads, and recovery boundaries.
- Binlog optimization — how Binlog in Redo and Free Flush alter eligible commits and when they fall back.
- Quick start — build the source and verify each path independently.
Alibaba Cloud RDS MySQL provides managed versions of several AliSQL capabilities, but product versions, topology, parameter names, defaults, and support policy can differ. Use this site and the repository wiki for a self-managed source build; use RDS product documentation for an RDS instance.