MySQL, captured from the binlog.
Basalt reads row-based binlog events from MySQL 8 or Aurora. Every change arrives in commit order, keyed by GTID.
How it works.
Basalt connects as a replica and reads the binlog in ROW format. It snapshots tables with a consistent read, then streams changes from the recorded GTID set. Position is saved only after each write is durable.
Set it up in three steps.
Add the source
Create a user with REPLICATION SLAVE and REPLICATION CLIENT. Basalt checks binlog_format and gtid_mode before it starts.
# capture the app database from Aurora MySQL basalt source add app --mysql aurora-prod --databases app ✓ binlog ROW · gtid_mode ON ✓ snapshot 6.2M rows · streaming from GTID 3E11FA47:1-90412
Shape it with a view
Write plain SQL over the source. Basalt keeps the view current with every record and tracks lineage back to the topic, partition and offset.
CREATE MATERIALIZED VIEW revenue_by_min AS SELECT date_trunc('minute', ts) AS minute, currency, sum(amount) AS revenue, count(*) AS payments FROM payments WHERE status = 'captured' GROUP BY 1, 2;
Read it from anywhere
Every view is an endpoint the moment it exists. Call it over REST, connect with any Postgres client, or use the SDK from your app.
curl https://api.basalt.dev/v1/views/revenue_by_min?limit=5 \ -H "Authorization: Bearer $BASALT_TOKEN"
What you get.
GTID tracking
Position is kept as a GTID set, so failovers to a new primary resume cleanly.
Online snapshots
Backfill runs without table locks and joins the stream at a consistent point.
DDL handling
Column adds, drops and type changes are applied to views in order.
Aurora support
Works with Aurora MySQL 3 and RDS, including reader endpoints for snapshots.
Set your data in stone.
Free up to 10M events a month. No card, no sales call. Your first pipeline is live in about four minutes.