DBTrail: HTAP for MySQL and MariaDB, open source

The queries that keep your MySQL busy.

Send them to DBTrail on the same connection. Your MySQL keeps answering the quick ones.

Reports

Totals and rankings over whole tables, the ones that run for minutes.

SELECT warehouse, sum(amount)
FROM order_lines
GROUP BY warehouse;

Years of history

Trends that read most of a table, without pushing your working set out of memory.

SELECT year(created_at), count(*)
FROM orders
WHERE created_at >= '2023-01-01'
GROUP BY 1;

Deep pages

Page 5,000 of a listing, where MySQL reads and throws away every row before it.

SELECT * FROM events
ORDER BY id
LIMIT 20 OFFSET 100000;

One connection: transactions go to your MySQL, analytics to DBTrail.

Hybrid transactional and analytical processing: live dashboards, reports inside your product, and ad hoc questions on production data, without slowing down the application.

One connectioncopy seconds behind

UPDATE orders SET status = 'paid' WHERE id = 4827your MySQLa write
SELECT warehouse, sum(amount) FROM order_lines GROUP BY 1DBTrailreads the whole table
SELECT * FROM customers WHERE id = 42your MySQLa lookup by key
SELECT year(created_at), count(*) FROM orders GROUP BY 1DBTrailreads most of the table
SELECT qty FROM stock WHERE sku = 'A-17' FOR UPDATEyour MySQLinside a transaction
SELECT * FROM events ORDER BY id LIMIT 20 OFFSET 100000DBTraila deep page

Routing is automatic

DBTrail looks at each statement. Writes, transactions and lookups by key go to your MySQL; reads over large parts of a table go to the columnar copy. You don't mark your queries.

No ETL

DBTrail follows your binlog the way a replica does, so there is no pipeline to build or nightly batch to wait for. In fresh mode the copy is seconds behind your MySQL.

Your drivers and tools

Your application, your BI tools and the mysql client connect to DBTrail as they connect to MySQL, and send the same SQL.

MySQL, MariaDB, RDS, Aurora

Percona Server too, and anything that writes a MySQL binlog. It runs on your machines, on x86 or ARM, and it is open source.

And when a change goes wrong.

DBTrail keeps the before and after of every row it captures. See a row as it was yesterday, or get the SQL that puts back the rows a bad UPDATE or DELETE touched. You review it and run it.

Undo a wrong change

-- the row as it was this morning
SELECT * FROM _flashback.orders
  AS OF '2026-11-07 09:00:00'
WHERE id = 4827;

-- the SQL that puts it back
UPDATE orders SET status = 'paid'
WHERE id = 4827;

Or ask Claude what changed.

Connect Claude, or any MCP client, and ask in plain words: what was deleted and when, how a row looked on Monday, the SQL that puts it back. It sees what the web interface shows you, with the same redactions. Its tools only read, and it never runs SQL on your MySQL.

Connect Claude

What to know before you rely on it.

The copy is behind your MySQL: By a few seconds in fresh mode, by minutes otherwise. A query that must see a write made a second ago belongs on your MySQL.
Lookups stay on your MySQL: A query by key takes 4 ms on MySQL and about 100 ms on the copy, so routing leaves it there.
It is not a failover replica: Writes always go to your MySQL, and nothing fails over to DBTrail. Keep your replicas and your backups.
It runs on your machines: DBTrail and its small index MySQL are yours to operate: disk, backups and upgrades.
Some schema changes re-read a table: Adding or dropping a column, or a TRUNCATE, makes DBTrail read that table again, with a short lock.
Row history needs a bucket to last: Without S3, the history of changes is kept for 48 hours. The copy itself stays.