AliSQL technology
Two engine paths share one MySQL-facing server. Explore the transactional foundation, kernel extensions, and binlog realtime replication (BRR) beside the integrated columnar analytical path.
Transactional path
MySQL / InnoDB
The MySQL/InnoDB transaction path, extended with retrieval, historical reads, commit engineering, and Binlog Realtime Replication.
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.05ReplicationBinlog realtime replication (BRR)Transmit eligible events before commit, with optional early apply and explicit GTID and worker requirements.
Analytical path
DuckDB
DuckDB 1.5.2 with MySQL-facing SQL, columnar execution, replication, and recovery.
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-3, pairs a MySQL 8.0.44 base with DuckDB 1.5.2. It adds Binlog Realtime Replication (BRR), disabled by default, for eligible DDL and large transactions. Each guide records its own defaults, eligibility rules, compatibility boundaries, and primary sources.