Quick start

Build the current AliSQL source, start a local MySQL-compatible server, and then choose the engine path that matches the workload you want to evaluate. The examples below follow the current alibaba/AliSQL README and the 8.0.44-2 feature guides.

Source build, not RDS MySQL

This page is for the open-source repository. Alibaba Cloud RDS MySQL manages binaries, topology, parameters, backup, and monitoring separately; its supported versions and defaults can differ.

1. Prepare the build host

Use a Linux development environment with:

Requirement	Minimum documented by the repository
CMake	3.x or newer
Python	Python 3
Compiler	GCC 7+ or Clang 5+
Source tools	Git and standard C/C++ build tools

The build is substantial. Keep the source tree and installation directory on a filesystem with enough free space, and use a disposable development host for the first run.

2. Build and install

git clone https://github.com/alibaba/AliSQL.git
cd AliSQL

# Configure and compile a release build.
sh build.sh -t release -d ~/alisql

# Install into the directory passed with -d.
make install

build.sh defaults to a debug build when -t is omitted. It also supports ASan, TSan, and coverage builds; inspect the exact options in your checkout:

sh build.sh --help

3. Initialize the data directory

--initialize-insecure creates a root account without a password. Use it only for an isolated local evaluation, then set credentials before exposing the server to any network.

~/alisql/bin/mysqld \
  --initialize-insecure \
  --datadir=~/alisql/data

4. Choose a startup profile

duckdb_mode is selected at startup and is read-only while the server is running. Start with one of these profiles:

Evaluation path	Startup option	What it enables
MySQL / InnoDB baseline	--duckdb_mode=NONE	Transactional InnoDB tables and the standard MySQL-compatible path
DuckDB analytics	--duckdb_mode=ON	DuckDB storage-engine tables in the same AliSQL process

Run the server in one terminal. The repository default is duckdb_mode=NONE; it is written explicitly here so the selected path is visible.

# MySQL / InnoDB baseline
~/alisql/bin/mysqld \
  --datadir=~/alisql/data \
  --duckdb_mode=NONE

For the analytical example later on, stop the development server cleanly and restart it with:

~/alisql/bin/mysqld \
  --datadir=~/alisql/data \
  --duckdb_mode=ON

Connect from a second terminal:

~/alisql/bin/mysql -uroot

Confirm the binary, startup profile, and registered storage engines before testing features:

SELECT VERSION();
SHOW GLOBAL VARIABLES LIKE 'duckdb_mode';
SHOW ENGINES;

5. Verify the InnoDB baseline

This smoke test exercises the transactional path without enabling any optional feature:

CREATE DATABASE demo;
USE demo;

CREATE TABLE accounts (
    id BIGINT PRIMARY KEY,
    balance DECIMAL(18,2) NOT NULL
) ENGINE=InnoDB;

START TRANSACTION;
INSERT INTO accounts VALUES (1, 100.00), (2, 80.00);
UPDATE accounts SET balance = balance - 20.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 20.00 WHERE id = 2;
COMMIT;

SELECT * FROM accounts ORDER BY id;

6. Try DuckDB analytics

This section requires a server started with --duckdb_mode=ON.

USE demo;

CREATE TABLE sales (
    id BIGINT PRIMARY KEY,
    region VARCHAR(32),
    amount DECIMAL(18,2)
) ENGINE=DuckDB;

INSERT INTO sales VALUES
    (1, 'East', 120.50),
    (2, 'West', 98.00),
    (3, 'East', 64.50);

SELECT region, SUM(amount) AS revenue
FROM sales
GROUP BY region
ORDER BY revenue DESC;

For an InnoDB-primary / DuckDB-replica topology, follow the official DuckDB node setup guide. It includes the required directory layout, replication settings, and batch-apply restrictions.

7. Try native vector search

VIDX is an InnoDB capability; it does not require DuckDB mode. Vector features are disabled by default, and indexed vector operations require READ COMMITTED:

SET GLOBAL vidx_disabled = OFF;
SET SESSION transaction_isolation = 'READ-COMMITTED';

USE demo;

CREATE TABLE embeddings (
    id BIGINT PRIMARY KEY,
    content VARCHAR(120),
    embedding VECTOR(3),
    VECTOR INDEX embedding_hnsw (embedding) M=6 DISTANCE=COSINE
) ENGINE=InnoDB;

INSERT INTO embeddings VALUES
    (1, 'first document',  VEC_FROMTEXT('[0.1,0.2,0.3]')),
    (2, 'second document', VEC_FROMTEXT('[0.2,0.1,0.4]'));

SELECT id,
       content,
       VEC_DISTANCE_COSINE(
           embedding,
           VEC_FROMTEXT('[0.1,0.2,0.3]')
       ) AS distance
FROM embeddings
ORDER BY distance
LIMIT 10;

Read Native vector search before changing graph or cache parameters. The current implementation supports vector indexes only on InnoDB and does not support write-write concurrency on the same vector table.

Defaults worth noticing

AliSQL keeps most new execution paths opt-in in the 8.0.44-2 feature release:

Capability	Open-source default	Next document
DuckDB storage engine	duckdb_mode=NONE	DuckDB analytics
Native vector index	vidx_disabled=ON	Native vector search
Native Flashback snapshots	Task OFF; undo retention 0	Native Flashback
Persist Binlog Into Redo V2	persist_binlog_to_redo=OFF	Binlog optimization
Binlog Cache Free Flush	binlog_cache_free_flush=OFF	Binlog optimization

Before production use

1. Pin and record the exact AliSQL commit or release you qualified.
2. Put credentials, file ownership, ports, sockets, logs, and service supervision in an explicit configuration.
3. Validate SQL, data types, collations, DDL, and client behavior with production-shaped traffic.
4. Benchmark on the intended hardware and durability settings.
5. Test replication, crash recovery, backup, restore, and rollback procedures.
6. Keep default-off paths disabled until their feature-specific prerequisites and fallbacks have been exercised.

Authoritative references

• AliSQL repository and build options
• AliSQL 8.0.44-2 feature release notes
• DuckDB node setup
• Vector Index guide