Architecture overview

AxialDB adds an analytical engine, columnar snapshot storage, and workload isolation on the server you already run — one coherent stack, no rented warehouse. Materialize analytical queries to Parquet once; repeat reads go through the columnar engine while OLTP stays on row storage. That separation protects production and delivers columnar-class speed (up to 9× on representative workloads).

AxialDB on one host — materialize to columnar Parquet, query through your engine, OLTP protected
SQL clients Your app, BI tools, ad hoc queries
Your database MySQL, SQLite, and more — OLTP tables unchanged
AxialDB extension Registers analytical views; routes heavy reads off OLTP
Optional: embedded engine Same columnar runtime inside the DB process when enabled
axialdb-engine Columnar query engine — separate process on your host by default
Internal data lake Columnar Parquet files on local disk — your private snapshot store, not a rented warehouse

What each layer does

  • Database + extension. You use normal SQL. The AxialDB extension registers analytical views and routes repeat analytical queries off live OLTP rows.
  • Columnar engine (sidecar or embedded). By default, axialdb-engine runs as a sidecar — its own process beside the database. Some deployments can run the same engine inside the database process instead; either way, analytical queries run on frozen columnar snapshots, not row-oriented OLTP on every refresh. That is both the isolation story and the performance story.
  • Internal data lake. When you materialize a view, results land as Parquet files under your configured data directory. Columnar storage co-located with your database — purpose-built for fast repeat analytics on the hardware you already operate.

Two paths for analytical queries

Default Sidecar

Analytics run in a separate process on columnar snapshots — strong isolation for production OLTP and fast repeat analytical queries.

Optional Embedded

The columnar engine can run inside the database process for selected views when your deployment enables it. Same Parquet snapshots; different packaging for hosts that prefer in-process execution.

For the three-step workflow (CREATE → SELECT → protected OLTP), see How it works on the home page.