AliSQL 8.0.44-2 — Five core capabilities
AliSQL 8.0.44-2 builds on the DuckDB HTAP debut in 8.0.44-1. It upgrades the DuckDB integration and adds native vector search, Native Flashback, Binlog in Redo V2, and Binlog Cache Free Flush.
Five core capabilities
Each path has a distinct boundary: DuckDB serves analytics, Vector Index and Native Flashback stay on the InnoDB path, and the two binlog mechanisms optimize different eligible transaction shapes.
DuckDB is deeply integrated as AliSQL's analytical storage engine, adding columnar storage and vectorized execution while preserving the MySQL protocol and SQL interface. An InnoDB online transaction processing (OLTP) primary can continuously replicate row-based binlog events to a DuckDB analytical replica. Version 8.0.44-2 upgrades DuckDB to 1.4.4 and improves SQL compatibility, data definition language (DDL), replication reliability, query and replication thread controls, and CPU governance.
02 · Native vector searchVector search, native to MySQLInnoDB gains a native VECTOR(N) type and hierarchical navigable small world (HNSW) approximate nearest-neighbor (ANN) indexes with Euclidean and cosine distance. Vector search composes with ordinary SQL predicates without a separate vector database, supporting semantic search, retrieval-augmented generation (RAG), and recommendations. Vectors can have up to 16,383 dimensions, with execution optimizations including single instruction, multiple data (SIMD).
03 · Native flashbackQuery your data in the pastAS OF TIMESTAMP queries read historical data directly. AliSQL periodically preserves InnoDB snapshots and the required undo, then reconstructs a consistent historical read view through multiversion concurrency control (MVCC). After an accidental delete or update, operators can inspect the earlier version without first restoring a backup and replaying binlogs.
04 · Binlog in Redo V2Faster commit with redo-backed binlogEligible binlog events enter the InnoDB redo durability boundary during commit. Background threads write and synchronize the binlog, reducing binlog input/output (I/O) on the foreground commit path. If the binlog tail falls behind durable redo after a crash, the missing binlog can be reconstructed from redo.
05 · Binlog Cache Free FlushLarge transactions without double writeFor eligible large InnoDB transactions, the traditional path copies a binlog cache that has already spilled to disk into the binlog again. Free Flush reserves the header and converts the temporary file directly into a new binlog file, avoiding the second large data copy and reducing I/O amplification and stalls caused by long-held locks.
Default state
Most new execution paths are disabled by default. The Flashback query gate is enabled, but snapshot generation and undo retention are not.
| Area | Feature | Open-source default |
|---|---|---|
| Analytics | DuckDB storage engine | duckdb_mode=NONE |
| Vector search | Native VECTOR type and HNSW index | vidx_disabled=ON |
| Large transactions | Binlog Cache Free Flush | OFF |
| Binlog durability | Persist Binlog Into Redo V2 | persist_binlog_to_redo=OFF |
| Historical reads | Native flashback history | Snapshot task OFF; undo retention 0 |
Each feature has its own startup rules, transaction eligibility, topology limits, or SQL boundaries. Qualify the exact combination you intend to run; transactions outside an optimized binlog path continue through normal group commit.