AliSQL technology
Two engine paths share one MySQL-facing server. Explore the transactional foundation and its kernel extensions beside the integrated columnar analytical path.
Transactional path
MySQL / InnoDB
The MySQL/InnoDB transaction path, extended with retrieval, historical reads, and commit engineering.
01FoundationMySQL / InnoDB kernelStart with the transaction, storage, SQL, recovery, and compatibility foundation.02RetrievalNative vector searchTrace VECTOR(N), HNSW persistence, cache lifetimes, and transaction boundaries.03Historical readsNative FlashbackReconstruct retained InnoDB history through snapshots, undo, and AS OF TIMESTAMP.04Commit durabilityBinlog optimizationCompare redo-backed binlog persistence, large-cache promotion, and safe fallback.
Analytical path
DuckDB
An integrated DuckDB columnar path with MySQL-facing SQL, replication, recovery, and resource controls.
01Engine integrationStorage-engine architectureSee where DuckDB joins the MySQL runtime, SQL, binlog, and storage-engine layers.02SQL executionQuery and adaptation pathFollow supported SQL normalization, type mapping, execution, and result conversion.03HTAP topologyAnalytical replicaUnderstand row-binlog replay, idempotent recovery, batching, and workload isolation.04Resource controlOperations and limitsReview memory, threads, temporary space, keys, SQL compatibility, and Direct I/O.
The current open-source feature release, AliSQL 8.0.44-2, pairs a MySQL 8.0.44 base with DuckDB 1.4.4. Each guide records its own defaults, eligibility rules, compatibility boundaries, and primary sources.