Dbtrail

DBTrail keeps your MySQL tables as Parquet files you own, minutes behind the source, with every version of every row. Query them with DuckDB. Production never sees the query.

$ duckdb -init views.sql

D SELECT c.tier, count(*) AS orders, round(sum(o.total), 2) AS revenue FROM demo.orders o JOIN demo.customers c ON c.id = o.customer_id GROUP BY c.tier ORDER BY revenue DESC; ┌──────────┬────────┬───────────────┐ │ tier │ orders │ revenue │ │ varchar │ int64 │ decimal(38,2) │ ├──────────┼────────┼───────────────┤ │ platinum │ 539848 │ 59426197.40 │ │ gold │ 539752 │ 59353658.54 │ │ silver │ 539056 │ 59295443.48 │ │ bronze │ 538385 │ 59242795.95 │ └──────────┴────────┴───────────────┘

That query read Parquet files. The MySQL primary never saw it.

Minutes behind the source. Not high availability, not a backup. Limits

---

Why

Reports, dashboards and ad-hoc analysis compete with your application when they run on the primary: a full scan pushes the working set out of the buffer pool, a long read holds back purge, and a GROUP BY over millions of rows spills temp tables to disk. A reporting replica is one more MySQL to pay for and patch, and it still answers at row-store speed.

DBTrail gives those queries a copy of their own, in a columnar format, outside mysqld.

How it works

1. The first copy reads your tables once (with mydumper).
2. After that, only the binlog. DBTrail connects over the replication protocol, the way a replica does. No plugin, no agent on the database host, no triggers. That is why Amazon RDS and Aurora work.
3. On your schedule, the copy is updated. DBTrail folds the recorded changes into a new Parquet snapshot, from every 5 minutes to once a day. The source is not read again, unless a table changes shape (see Limits).
4. You query it with DuckDB. A generated views.sql gives you one view per table, named like the source table (shop.orders), that follows the newest snapshot.

One Docker Compose stack, and a folder or an S3 bucket. No pipeline to build, no warehouse to run, no Kafka. See Analytics with DuckDB.

The numbers

Source: RDS MySQL 8.4, TPC-C dataset, 73 million rows, about 10 GB, under a sysbench-tpcc load of 180 transactions per second. Measured 18 to 20 September 2026 with DBTrail 0.84 refreshing every 5 minutes. Six report queries, total time:

One of the six, a two-table join grouped by district and month, took 3 min 52 s on MySQL and 0.9 s on the copy.

Freshness, measured separately under about 340 transactions per second with a 5-minute schedule: commit to visible in DuckDB took 2.7 to 13.2 minutes, median 5.9.

Method, cost comparison and ClickBench results: Introducing the MySQL Analytical Replica.

What you get

An analytical copy

• Heavy queries off your MySQL. They run in DuckDB, in its own process, on the copy. Only the binlog leaves mysqld.
• One MySQL connection for both, with Engine Routing. Point a report or a BI tool at DBTrail's MySQL port instead of your MySQL. For each statement it decides who answers: lookups, small reads and anything inside a transaction go to your MySQL, heavy reads go to the copy. No query changes. Off until you turn it on. See Run MySQL and DuckDB on the same connection.
• DuckDB, ready to open. One views.sql, one view per table. Your DuckDB runs it on your machine: a laptop, a notebook, a BI box.
• Open files you own. Plain Parquet on disk or in S3, with a Hive-partitioned change history. Nothing proprietary.
• Other engines too. Export a snapshot to Iceberg for Spark, Trino or Athena with bintrail export iceberg. See Iceberg export.

Open the copy through `views.sql`. An engine that reads the Parquet

files directly sees each table as of its last full write and can miss the

change files stored beside it. The views apply them for you.

Time travel and recovery, from the same stream

DBTrail keeps every change on your MySQL server, before and after, and writes the SQL that undoes the ones you didn't want. It reads them from the same binlog as the copy, from the day you install it:

• Every version of every row. See any row or table as it was at a past moment, from the web interface or the reconstruct CLI. An optional MySQL port (beta) answers the same questions with AS OF SQL from any mysql client. See Time-Travel SQL.
• Undo precisely. Generate the SQL that reverses just the damaged rows. recover-cascade also rebuilds the child rows an ON DELETE CASCADE removed below the binary log. DBTrail writes the SQL. You review it and you run it. See Query & Recovery.
• Prove it holds. bintrail verify checks, from two snapshots and the index and without touching the source, that a recovery would reproduce it. bintrail status flags any gap the capture could not fill. See Verify.
• Web interface and MCP. Add servers, schedule snapshots and browse changes in the browser. Connect Claude Desktop or any MCP client to ask in plain English. Every tool is read-only. See the 5-minute guide.

Try time travel in 30 seconds, with nothing of yours connected:

docker run --rm -p 6033:6033 ghcr.io/dbtrail/bintrail-demo

See the demo image.

Limits

A copy you can trust is one whose edges you know.

• Not high availability. Your application never points at the copy. Nothing fails over to it.
• Not your backup. History starts the day you install it. Keep your physical backups.
• Minutes behind, not seconds, by default. The copy refreshes on the schedule you set, and the SQL port answers from it. Its fresh mode, chosen per server in the web interface, also reads what capture has indexed since, usually seconds behind, for some memory and speed.
• Needs a ROW binlog with full row images. binlog_format=ROW and binlog_row_image=FULL. bintrail doctor checks both and prints the fix (on RDS and Aurora, set them in the parameter group).
• Some changes mean a full read. Adding, dropping, renaming or retyping a column, or a TRUNCATE, DROP or RENAME of a table, pauses the scheduled update until DBTrail reads the database again, at most once a day. That read takes a short lock: a global read lock while it starts, or, on RDS and Aurora, a lock on the tables it reads. A new table joins with a read of its own. Index and other everyday changes do not trigger one.
• History needs a bucket. Without S3, row history keeps 48 hours by default (--rotate-retain changes it). The copy itself stays: the newest 3 snapshots per table on local disk.
• Cascaded deletes before MySQL 9.6, and on MariaDB. Rows deleted by a foreign key never reach the binlog. recover-cascade rebuilds most of them, and the copy keeps them until DBTrail next reads the database in full.
• The MySQL port is beta, read-only, and has no TLS. Use it on a private network. It answers reads (routed to the copy or to your MySQL) and time-travel questions; writes are refused unless the router is started to forward them. It does not tune a slow query: a query that needs an index still needs the index.
• Yours to operate. DBTrail and its small index MySQL run on your machines. Disk and backups are yours.

Full list: Limitations.

What it works with

DBTrail never needs the binlog files on disk, which is why managed cloud databases work.

Install

You need Docker with Compose, and DuckDB on the machine where you query.

curl -fsSL https://raw.githubusercontent.com/dbtrail/dbtrail/main/install.sh | sh

This downloads the Docker Compose stack, starts it, waits until DBTrail answers, and prints the next steps.

1. Sign in. Open http://127.0.0.1:8090, create a username and password, and press Create & sign in.
2. Connect. Click + Add server, enter the host and port of your MySQL and press Find it. The form shows the SQL that creates DBTrail's user. Run it on your MySQL, then press I ran it. DBTrail checks the rest and starts on its own.
3. First change. Change a row on your MySQL. It shows under Recent changes on the Overview within a minute, with an Undo that writes the SQL to reverse it.
4. First copy. On Snapshots, press Read database now. Normally this is the only time DBTrail reads your tables directly.
5. Set a schedule. On the Settings tab of Snapshots, under Update the copy, pick how often (every 5 minutes, for example) and press Turn on. Each run after the first folds the recorded changes instead of reading the source.
6. Query it. On Snapshots, press Download, then Download the data. Unpack the .tar.gz and run duckdb -init views.sql inside the snapshot folder. To read the copy that keeps updating, see Query in DuckDB.

Prefer the command line? See the command-line quickstart.

Who builds it

DBTrail is built by Daniel Guzman-Burgos, former MySQL Technical Lead at Percona.

Documentation

| | [Ma