Measurements

One query, one computer, MySQL 9.7.0. Not a general speed promise.

Result

Two sets, same query. Server time is the mean of runs 1–6. Run 0 is a warmup and is not in the mean. Ratio is mean MySQL time divided by mean AxialDB time.

Without a covering index on the line table

order_lines has only its primary key.

Host	MySQL view	AxialDB CDC	Ratio
Windows 11	50.719 s	0.127 s	399×
Ubuntu on WSL2	15.781 s	0.087 s	181×

Both sides returned the same answer on that host: 10,000 groups, 3,920,000 source rows. The Windows grand total was 1,080,159,136. The WSL2 grand total was 1,080,156,784. Those are two copies of the demo, not one shared dataset.

WSL2 is not a bare-metal Linux install. It is a virtual machine on this Windows computer, with its own MySQL on port 3307 and a smaller memory view (about 15 GiB of the host’s 32 GB). The Windows number and the WSL2 number are not a Windows-versus-Linux product comparison.

With a covering index on the line table

order_lines.idx_lines_order_customer (order_id, customer_id) on both copies. MySQL scans that index, then reads orders.total from the primary key. The index is not on the AxialDB table.

Host	MySQL view	AxialDB CDC	Ratio
Windows 11	18.819 s	0.118 s	160×
Ubuntu on WSL2	11.811 s	0.158 s	75×

An index on (customer_id, order_id) was slower on WSL2 (about 31 s) because the orders lookups were no longer in primary-key order. It is not in this set.

Query

SELECT customer_id, COUNT(*), SUM(order_total) AS order_total
FROM <table>
GROUP BY customer_id
ORDER BY customer_id;

<table> was demo_perf.order_lines_av or demo_perf.order_lines_v. Nothing else in the statement changed.

order_lines_av is an AxialDB table with CDC, status healthy at the start of each host’s runs. The engine returns the grouped result. It does not scan the live join.
order_lines_v is a normal MySQL view: order_lines LEFT JOIN orders ON order_lines.order_id = orders.id, with orders.total exposed as order_total. MySQL plans that as a live join. performance_schema reported 7,850,000 rows examined and 10,000 rows sent on every view run.

How time was taken

Each run was one mysql client session. Immediately after the query, the same session read performance_schema.events_statements_history.TIMER_WAIT for that statement and divided by 10¹² to get seconds. That is MySQL’s server time for the statement. Ratios use this number, not the client clock.

Client wall clock is also listed. It includes printing 10,000 result rows. On the AxialDB query that print is a large share of the wall clock (about 0.30 s on Windows versus 0.127 s on the server). On the MySQL view the query itself dominates, so wall clock and server time stay within a few tenths of a second. Comparing wall clocks would still favor AxialDB, but it would mix result printing into the AxialDB number. The published ratio uses server time on both sides.

AxialDB pushdown leaves ROWS_SENT and ROWS_EXAMINED at 0 in that history row. Cardinality was checked with a separate checksum of the same grouping (group count, summed counts, summed totals) and matched the view on each host.

Seven runs, AxialDB first, then the view. Run 0 is warmup. The mean is runs 1–6.

Machine

Computer	GIGABYTE AERO 16 XE5
CPU	12th Gen Intel Core i7-12700H, 14 cores, 20 threads, 2.3 GHz base
Memory	32 GB on the host (31.7 GiB reported). WSL2 reported about 15 GiB.
Disk	GIGABYTE AG470S1TB-SI, about 1.0 TB
Windows	Windows 11 Pro, build 10.0.26200, 64-bit. MySQL 9.7.0 on port 3306. AxialDB sidecar on 127.0.0.1:9742.
Linux	Ubuntu 26.04 LTS as a WSL2 guest, kernel 6.6.114.1-microsoft-standard-WSL2. MySQL 9.7.0 on port 3307. Its own AxialDB sidecar on 127.0.0.1:9742. Not bare metal.

Only one sidecar listens on port 9742. Windows runs use the Windows service. WSL2 runs use the WSL service.

Windows runs, no covering index

Seconds. Server time is TIMER_WAIT. Client is mysql wall clock.

Run	AxialDB server	AxialDB client	MySQL view server	MySQL view client
0 warmup	0.136	0.320	49.679	49.837
1	0.134	0.299	49.665	49.962
2	0.133	0.338	50.740	50.934
3	0.135	0.293	50.528	50.716
4	0.126	0.299	51.078	51.269
5	0.115	0.270	51.088	51.340
6	0.120	0.299	51.216	51.476
Mean 1–6	0.127	0.300	50.719	50.950

WSL2 runs, no covering index

Ubuntu 26.04 as a WSL2 guest on the computer above.

Run	AxialDB server	AxialDB client	MySQL view server	MySQL view client
0 warmup	0.131	0.153	11.545	11.566
1	0.086	0.109	12.683	12.708
2	0.091	0.111	18.982	19.009
3	0.082	0.102	15.163	15.189
4	0.086	0.106	17.994	18.022
5	0.089	0.108	14.931	14.964
6	0.087	0.107	14.933	14.956
Mean 1–6	0.087	0.107	15.781	15.808

WSL2 view time in this set ranges from 12.7 s to 19.0 s.

Windows runs, covering index

idx_lines_order_customer (order_id, customer_id).

Run	AxialDB server	AxialDB client	MySQL view server	MySQL view client
0 warmup	0.125	0.293	25.740	25.923
1	0.119	0.287	21.381	22.067
2	0.117	0.334	18.414	18.871
3	0.122	0.270	18.152	18.430
4	0.119	0.298	18.301	18.820
5	0.116	0.279	18.614	18.866
6	0.112	0.318	18.049	18.291
Mean 1–6	0.118	0.298	18.819	19.224

WSL2 runs, covering index

Same index and the same run order.

Run	AxialDB server	AxialDB client	MySQL view server	MySQL view client
0 warmup	0.359	0.398	12.514	12.552
1	0.155	0.189	12.025	12.056
2	0.188	0.227	11.707	11.737
3	0.138	0.174	11.691	11.727
4	0.171	0.219	11.532	11.561
5	0.150	0.203	12.028	12.061
6	0.144	0.176	11.881	11.909
Mean 1–6	0.158	0.198	11.811	11.842

What this does not say

It is not every analytical query, and not a TPC-style suite.
It is not a claim that every AxialDB table is 399× faster than every InnoDB query.
The first set has no extra index on order_lines. The second set adds one covering index. It is still a join view, not a single indexed fact table that already stores order_total.
WSL2 shares the computer with Windows. It is not a dedicated Linux server.
A GUI that waits for all 10,000 rows will look closer to the client column than the server column.