Postgres, replicated from the WAL.
Stream every insert, update and delete from your primary. Basalt takes a consistent snapshot first, then follows the WAL with no gaps.
Overview
How it works.
Basalt creates a publication and a logical replication slot using pgoutput. It snapshots existing rows at a fixed LSN, then applies changes in commit order and confirms the LSN only after each write is durable.
Setup
Set it up in three steps.
01
Add the source
Grant a role with REPLICATION and pick the tables to publish. Basalt creates the slot, checks wal_level, and starts the snapshot.
# replicate orders and customers from the primary basalt source add shop --postgres prod-db --tables orders,customers
✓ slot basalt_shop created · pgoutput
✓ snapshot 18.4M rows · streaming from LSN 2F/9A01C3B8
02
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;
03
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"
✓ 200 OK · 5 rows · served from eu-north-1 in 3.1 ms
Included
What you get.
01
Consistent snapshots
Backfill runs at a fixed LSN, so the snapshot and the stream meet with no gaps or repeats.
02
Schema changes
ALTER TABLE adds and drops flow through. Views pick up new columns without a restart.
03
Slot safety
Basalt alerts before retained WAL grows past your limit and never leaves an orphaned slot.
04
Before images
With REPLICA IDENTITY FULL, updates carry the old row for diffs and audit views.
Related
