Your database shouldn't struggle to draw a simple chart.

AxialDB is an analytical engine that sits beside your operational database and keeps a columnar copy of the data your reports need. Heavy queries run on that copy, and your production tables stay out of it. MySQL 9.7 is the first database we support: mark a copy for CDC and it follows the binlog, usually within seconds.

Free for up to 5 views, 2 of them live from the binlog. If you need more, it's a license file on the same download.

399×

Faster on one GROUP BY over 3.92 million rows: 50.7 s on the live MySQL join, 0.127 s on the AxialDB copy, on Windows. 181× under WSL2.

One query on one machine, before adding a covering index to MySQL. With that index the gap was 160× and 75×. Your data will give its own numbers. See every run.

Sound familiar?

  • A report runs and the app slows down for everyone
  • A dashboard takes a minute because it scans live tables on every refresh
  • You've been told the fix is Kafka, Debezium, and a warehouse, for five reports
  • You want answers in SQL, not a new data platform to look after

Why I built it

I've spent years as a data architect watching the same thing happen. A company's reports outgrow the database, and the usual answer is a pipeline, a warehouse, and a team to run them. For most teams that's too much. They don't need every table copied somewhere else. They need a few reports to be fast without hurting the app. AxialDB is made by IT ART Inc.

  • You define the copy in SQL. CREATE TABLE … ENGINE=AXIALDB AS SELECT … over the tables you already have. AxialDB stores the result as columnar files on your server.
  • It can stay fresh on its own. Add COMMENT='cdc' and AxialDB applies inserts, updates, and deletes from the binlog. No separate CDC service to run.
  • Production is left alone. Reports read the copy through axialdb-engine, a separate process. AxialDB never writes to your production tables.

How it works

1
Create a view

ENGINE=AXIALDB AS SELECT … over the tables your reports use.

2
Query it

Charts and reports read the columnar copy, not your live tables.

3
Keep it current

Recreate it when you want a new snapshot, or add COMMENT='cdc' to follow the binlog.

Live (CDC) views cover one table, or a fact table joined to its dimensions, with a primary key. A plain snapshot accepts any SELECT MySQL can run.

Why MySQL first: it runs a huge share of the world's applications, and it's where I've seen reporting pain most often. The engine, storage, and change log aren't MySQL-specific. Only the plugin and binlog reader are, and other databases will get their own.

Common questions

Why are analytical queries slow on my database?

Operational databases such as MySQL, PostgreSQL, and SQL Server store data by row, which is right for the application. A GROUP BY over millions of rows reads every column of every row it touches, and it competes with your application for CPU, memory, and disk on the same server.

How much faster is it?

On the query we measured, a GROUP BY customer_id over 3.92 million rows took 50.7 s on the live MySQL join and 0.127 s on the AxialDB copy on Windows (399×). Under WSL2 it was 15.8 s versus 0.087 s (181×). After adding a covering index to MySQL the gap narrowed to 160× and 75×. Your queries and hardware will give different numbers. Every run is published.

Do I need a warehouse for a few dashboards?

Often not. A warehouse and a sync pipeline make sense at scale. For a handful of reports, AxialDB keeps columnar copies of just the views you need, beside your database, fresh from its change log.

Is it safe to run next to production?

AxialDB reads the change log the way a replica does and never writes to your production tables. On MySQL that's the binlog. Each release we have published was tested on Windows 11 and on Ubuntu 26.04 under WSL2, including long CDC runs under load. Those are the machines on the measurements page. It still runs on your server, so start on staging and keep your usual backups.

Built for small teams

Start with the few reports that hurt. The free version covers 5 views, 2 of them live, which is enough to see whether it helps on your data. If you need more views, or someone to call, write to us and we'll send a license file.

A snapshot shows data as of when you created it. A live view follows the binlog, usually within a few seconds; heavy write bursts can take longer.